I'm having problems using authorized keys to SSH login to a remote server. The error messages I receive look like this:
OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.xx.xx [xxx.xx.xx.xx] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /Users/bfenker/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
...
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /Users/bfenker/.ssh/id_rsa type 1
ssh_exchange_identification: Connection closed by remote host
Other questions on this site have posted similar questions, and the solution was usually to double check all the permissions on the client side, which I have done:
drwxr-xr-x+ 23 bfenker staff 782 May 8 11:02 bfenker
drwx------ 8 bfenker staff 272 May 8 10:05 .ssh
-rw------- 1 bfenker staff 1675 May 8 09:51 id_rsa
-rw-r--r-- 1 bfenker staff 418 May 8 09:51 id_rsa.pub
-rw------- 1 bfenker staff 999 May 8 09:46 identity
-rw-r--r-- 1 bfenker staff 663 May 8 09:46 identity.pub
-rw-r--r-- 1 bfenker staff 416 May 8 09:06 known_hosts
I am able to use the authorized key to SSH into another sever and from this server SSH into the server that I want. This is a passable workaround that I am trying to fix, but I think it also shows that both my client and the server are set up okay.
Note that when I SSH succesfully into a different server, I get the same error messages, but it seems to recover starting with the lines:
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
Does anyone know why this works in some cases but not in the case I want? Any other suggestions would be much appreciated!
Best Answer
Necroquestion! Based on the fact that you can use this key to log into another server @michael-hampton is on the correct trail: there is something (firewall / tcp wrappers / sshd config) on the destination server that is denying access. All this talk about incorrect key formats is a red herring based on incorrect interpretation of the debug info. The line
indicates ssh was able to understand the key.