Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Connect to a server using OpenSSH_5.9p1 OpenSSL 1.0.1, and it stores a .ssh/known_hosts that's of the format:

|1|wwwwwwwwwwwwwww=|wwwwwwwwww= ecdsa-sha2-nistp256 AAAAAAAAAA+AAAAA=

Then copy that known_hosts file to another PC running OpenSSH_4.5p1 OpenSSL 0.9.8d, and it gives the "authenticity can't be established, are you sure you want to continue connecting" message, as if the known_hosts file was't right.

When that second PC stores the known_hosts for the same server, it writes it in the format:


Is there a way to convert between the two formats?

share|improve this question
Why don't you just update OpenSSL on the other machine. openssl-1.0.1c is the current version. Its a bad idea to be using vulerable versions of OpenSSL. I should point out that 0.9.8d is vulerable to a Invalid TLS/DTLS record attack. – Ramhound Jan 31 '13 at 19:14
I understand that using the same version of OpenSSL on both machines will allow sharing config files. While that is an excellent idea, this question is about how to make a known_hosts that can be shared between these two versions that we happen to have installed. – OJW Jan 31 '13 at 22:33
Since I didn't know the answer to your question, I suggested a logical solution, use the same version on both machines. Besides you really should address the vulerability against the version you are using. – Ramhound Feb 1 '13 at 12:14
up vote 4 down vote accepted

Your first example contains an ECDSA key (ecdsa-sha2-nistp256), which were introduced in OpenSSH 5.7.

OpenSSH 4.5 only supports RSA and DSA keys (ssh-rsa and ssh-dss), and ignores your known_hosts entry.

share|improve this answer
what's the lowest common denominator of those two versions? i.e. what command-line option tells v5.7 to use the best cipher that v4.5 will understand? – OJW Jan 31 '13 at 21:55
@OJW: -o HostKeyAlgorithms – see ssh_config(5). – grawity Jan 31 '13 at 22:04
thanks. What's the best HostKeyAlgorithm that both versions will understand? – OJW Jan 31 '13 at 22:29
@OJW: That's already in the answer... – grawity Jan 31 '13 at 23:23
ah yes thankyou. I commented out ecdsa on the server's /etc/ssh/sshd_config (and disabled HashKnownHosts on the client) and the client then generated a compatible known_hosts with rsa key in it, so that worked fine. I couldn't see a way for the client to specify non-ecdsa though? – OJW Feb 1 '13 at 11:24

The first key format you have is a hashed format, designed to prevent someone who's broken into your account from knowing which other hosts he/she might be able to connect to using your password and/or SSH keys.

It's possible to convert the plaintext format to the hashed format, but not vice versa. There are various scripts out there on the net for this purpose.

If you're not that worried about this issue, then you can always add

HashKnownHosts no

to ~/.ssh/config to disable the known_hosts hashing. Refer to ssh_config(5) for further details.

share|improve this answer
+1, but this is not the actual problem. – grawity Jan 31 '13 at 20:03
still, useful to know :) – OJW Feb 2 '13 at 13:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .