Getting and Verifying SSH Fingerprints

Sometimes you may log into a machine, and find that the SSH key has changed. This can happen in a man-in-the-middle attack, but more likely the host has been rebuilt and new keys generated. (This is a good reason to save and restore the SSH keys during a rebuild.)

So how do you check the fingerprints?

You can do it over the network by pulling down the public keys from the remote server:

ssh-keyscan -p 22 -t rsa,dsa remote_host > /tmp/ssh_host_rsa_dsa_key.pub

(Replace remote_host with the appropriate name or IP address.) Then you generate fingerprints from this file:

ssh-keygen -l -f /tmp/ssh_host_rsa_dsa_key.pub

However, if you are investigating why your keys changed mysteriously, you don’t want to do this over the network. Log into the actual server through other means (such as a management console or a KVM console) and generate fingerprints directly:

ssh-keygen -lf /etc/ssh/ssh_host_dsa_key
ssh-keygen -lf /etc/ssh/ssh_host_rsa_key

Then compare this with what you got over the network. If they match, you should be alright; if not, there are some serious problems.

If the fingerprints don’t match, you should do a network scan for ARP requests and see who is answering the ARP requests for the relevant IP address. Scan for ARP requests as you do a ping. If there are two hosts, then they will “fight” each other for an ARP entry, and you should see both responding.

Once you know the Ethernet address of the mysterious host, then chase it down by tracking where the ARP traffic is going by looking at router (or switch) interfaces.