8
$\begingroup$

I have read somewhere that Servers which have SSH access for users in the public can have their public key posted publicly (e.g., on a website), so that people who access such a server using SSH can use this key to verify the server's fingerprint.

My question: If the public key is accessible to the public, cant a malicious user get it and exploit it to 'man-in-the-middle' people who try to connect to this server?

What exactly is in this SSH fingerprint. Is it just a public key that has been hashed? Or is it server-specfic information that has been encrypted (or signed) by the server's private key?

Improve this question
$\endgroup$
3
  • $\begingroup$ Chances are very high that this is indeed a plain hash of the server's public key. However I can't find any standard atm to confirm this, so I won't give a formal answer (for now). $\endgroup$
    – SEJPM
    Jun 12, 2016 at 13:41
  • $\begingroup$ Crossposted with slight change as security.stackexchange.com/questions/126779/… which has a much earlier answer, but after putting the work into mine I'm leaving it. Wasting people's time like that is considered rude. $\endgroup$
    – dave_thompson_085
    Jun 12, 2016 at 20:51
  • $\begingroup$ My apologies. I was not so sure which of the two forums would be most appropriate for it. Please advise if I should delete it here. $\endgroup$
    – Minaj
    Jun 12, 2016 at 22:10

1 Answer 1

Reset to default
6
$\begingroup$

Yes OpenSSH's fingerprint is a hash of the publickey, and (except SSHv1 keys aka -t RSA1 which is long broken and should never be used) specifically of the publickey format stored in base64 in (usually) /etc/ssh/ssh_host_${alg}_key.pub which is the wire encoding in the relevant KEX-reply message depending on key type (currently RSA, DSA, ECDSA, ED25519). See https://superuser.com/questions/421997/what-is-a-ssh-key-fingerprint-and-how-is-it-generated

Traditionally this hash has been MD5, and displayed in hex with colons between each byte. OpenSSH recently (6.8 in March 2015) switched to SHA256, displayed in base64, by default; you can get the old one with FingerprintHash option on client, or -E option on ssh-keygen -l; see the man pages for ssh_config and ssh-keygen if you have a recent version, or see online http://www.openssh.com/manual.html for the latest version.

OpenSSH also supports displaying this hash (now either SHA256 or MD5) in an ASCII-art form that is supposedly easier to compare visually. IME this is rarely used. But then IME users rarely verify the fingerprint at all.

Yes, if a MitM can intercept your first connection to an SSH server AND feed you a wrong fingerprint you are pwned. The most conservative advice is you should get the fingerprint from an admin or other 'reliable' person face-to-face, or over the phone if you know their voice well enough to distinguish from an imposter, or other out-of-band secure means like registered mail. But in today's world, especially when dealing with lots of systems and many of them far away or in the cloud, this is often impractical. If the fingerprint is on an HTTPS website (with certificate, ciphersuites and protocol version up to current standards) -- and the website itself isn't hacked (which has been known to happen) -- that's usually good enough.

But SSH clients are supposed to, and OpenSSH in particular does, remember the previously seen publickey (the whole key, not just the fingerprint) for each server, so if you get the first connection securely and MitM intercepts a subsequent connection it detects the discrepancy and gives you a big ugly error message with lots of uppercase and atsigns about 'WARNING! REMOTE HOST IDENTIFICATION HAS CHANGED! Someone could be eavesdropping on you!'.

However, if the server legitimately replaces its key(s), as they sometimes must or otherwise do, you get this same alarm, so as with all alarms that are often false, most people soon ignore them, or set the option (StrictHostKeyChecking no) to suppress them -- and advise others to do the same. Also, if the client 'loses' its memory (for OpenSSH in the file ~/.ssh/known_hosts), you are back to the vulnerable initial connection state. For example your PC became obsolete or just unfashionable and was replaced and you didn't copy this file, or it was lost or destroyed (or stolen) and replaced, or the filesystem or disk was accidentally overwritten or corrupted and your data lost, or you just decided to delete it.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Just an example command to display fingerprint in md5 form for a site from known hosts list:ssh-keygen -l -E md5 -f ~/.ssh/known_hosts | grep -F example.com $\endgroup$
    – ruvim
    Aug 15, 2017 at 10:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.