SSH Error: unknown key type '-----BEGIN'

Question

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!

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

I also faced this issue recently. In my case all the permissions were correct including .ssh, the rsa file, home directory and everything related to the user. The issue was that I had a previously generated public key in .ssh which was not corresponding to the private key I was using for login. Removing the public key from .ssh fixed the issue.

I was using ssh-keygen to create .ssh directory which resulted in this pub key and hence the issue.

Answer 6

I had the same problem on my MacBook Pro with MacOS 10.7.5. There was nothing wrong with my keys, it's just that they're encrypted (with a passphrase, like you're supposed to do) and weren't being unencrypted by ssh correctly. It seems that ssh-agent is having problems.

According to this article, try this:

1. Put /usr/bin/ssh-agent in your Login Items (System Preferences --> Users and Groups --> select user --> Login Items). It is awfully difficult to navigate to /usr/bin in the dialog box, so the article suggests making a link in your home directory (ln -s /usr/bin/ssh-agent) which you can remove once you've put it in Login Items.

2. Quit Terminal.app

3. Restart the machine.

4. Open Terminal and retry your ssh command.

Worked for me (at least, it has once).