4

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:

[10.2.3.4]:22 ssh-rsa AAAAAAAAAA/BBBBB/CCCCCC//DDDDDD

Is there a way to convert between the two formats?

OJW
  • 2,117
  • 4
  • 17
  • 22
  • 1
    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 01 '13 at 12:14

2 Answers2

6

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.

u1686_grawity
  • 426,297
  • 64
  • 894
  • 966
  • 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). – u1686_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... – u1686_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 01 '13 at 11:24
  • @OJW: Specify all HostKeyAlgorithms that are *not* ECDSA (i.e. `HostKeyAlgorithms=ssh-rsa,ssh-dss`). – u1686_grawity Feb 01 '13 at 12:10
  • @OJW: Alternatively, you could add *multiple* public keys for the same host to `known_hosts` (for example, by using `ssh-keyscan` or just copying from the server's `/etc/ssh/ssh_host_*_key.pub`) – that way, modern clients would check the ECDSA line, and older ones would use RSA or DSS. (Although I can't really list any advantages to ECDSA here, so do as you wish.) – u1686_grawity Feb 01 '13 at 12:12
4

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.

jjlin
  • 15,462
  • 4
  • 51
  • 51