SSH Error: unknown key type '-----BEGIN'
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!
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
debug1: identity file /Users/bfenker/.ssh/id_rsa type 1
indicates ssh was able to understand the key.
Your SSH key is stored in the wrong format. OpenSSH uses keys which are put in a single line. You need ssh-keygen with -i and -m options, see man ssh-keygen. Probably one of these:
ssh-keygen -m RFC4716 -i -f /Users/bfenker/.ssh/id_rsa
Use the output as new key file (ssh-keygen ... >newkeyfile).
Edit 1:
Please mind this: "This option will read an unencrypted private (or public) key file"
So probably the file has to be changed to one without passphrase by a program which understands that format.
I feel like the answers here are not very clear. Mark Wagner's answer does cover it, but doesn't fully explain the situation.
The lines in the output are prefixed with their debug levels, which also gives a hint to their significance: but lower numbers are more significant. The debug3: stuff is a lot less important than debug1:
When the key file is read, ssh is first trying to parse it as the deprecated RSA key (now called "RSA1"), those keys start with SSH PRIVATE KEY FILE FORMAT and a version number. The new RSA keys all start -----BEGIN RSA PRIVATE KEY-----. Here's a login attempt where identity is an old RSA1 style key and id_rsa is a new style.
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type 0
debug1: identity file /home/user/.ssh/identity-cert type -1
debug3: Not a RSA1 key file /home/user/.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 /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
At this point it has identified the key types in the files identity as type 0 and id_rsa as type 1. The other files it checks don't exist and are thus type -1.
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
debug1: Local version string SSH-2.0-OpenSSH_5.3
Since this is protocol 2, the protocol 1 RSA key in identity will be ignored during keyexchange.
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/user/.ssh/id_rsa (0x5622d77426a0)
debug2: key: /home/user/.ssh/id_dsa ((nil))
debug2: key: /home/user/.ssh/id_ecdsa ((nil))
Here it reminds us of the key files it wants to use. Not sure why it hasn't rejected the missing files, only the protocol 1 file, but...
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
[...]
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 372 bytes for a total of 1689
debug1: Server accepts key: pkalg ssh-rsa blen 277
And here it offers up the id_rsa key and it is accepted.
So, in short, the issue in the question title is a red herring that comes from ssh trying multiple ways to parse the keys it finds, not a real problem with a key.
First you should check your sshd logs. i.e.
less /var/log/secure
Depending on unix distribution file with security log may differ. But when you find if, it should tell the reason that you cannot login.