When you connect to a host that you have not connected to before via ssh, ssh prints a message like
lava:~$ ssh lava The authenticity of host 'lava (188.8.131.52)' can't be established. RSA key fingerprint is 9e:1a:5e:27:16:4d:2a:13:90:2c:64:41:bd:25:fd:35. Are you sure you want to continue connecting (yes/no)?
Usually, you say
yes and enter your password. With this, you accept the encryption key the server sent you as the actual encryption key of the server (as opposed to an encryption key some eavesdropper might have sent you who sits between you and the server you connect to). You are supposed to accept the encryption key only if you compared the received encryption key with the actual encryption key of the server by comparing their fingerprints. However, how do you get the fingerprint of the actual encryption key?
ssh-keygen -lf <keyfile> tells you the fingerprint of an encryption key. So where are the keyfiles of the server? Usually they are in the directory
/etc/ssh/ or a similarly named directory, where you can find several keys:
lava:~$ ls /etc/ssh/*key* /etc/ssh/ssh_host_dsa_key /etc/ssh/ssh_host_key.pub /etc/ssh/ssh_host_dsa_key.pub /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_key /etc/ssh/ssh_host_rsa_key.pub
This server has three keys, each of which comes as a pair of a private key (no extension) and a public key (extension
.pub). Only root can read the private keys (after all, they are private), but everybody can read the public keys. In the message above,
ssh shows you the RSA key ("
RSA key fingerprint is ..."), so you will check the fingerprint of the server's public RSA key:
lava:~$ ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub 2048 9e:1a:5e:27:16:4d:2a:13:90:2c:64:41:bd:25:fd:35 /etc/ssh/ssh_host_rsa_key.pub
The answer are three words: the first (
2048) is the bit length of the key, the second (
9e:1a:...:fd:35) is the fingerprint of the key and the last (
/etc/....pub) is the file name of the key file.
Thus, an unsecure and easy method to check the fingerprint of the server is to connect to the server and then check the fingerprint of its keyfile using
ssh-keygen. This method is unsecure because an eavesdropper who can sent you a malicious server key (so he can eavesdrop your communication with the server) can also easily replace the fingerprint response of
ssh-keygen with the fingerprint of the malicious key, for example by doing simple string replacement in the communication stream ("replace fingerprint of actual encryption key with fingerprint of malicious encryption key"). The secure method is to get the fingerprint from your administrator who wrote it down when she generated the key or to get the fingerprint when you logged in to the server directly (as opposed to via a network).
Update: Comments are closed due to excessive spam. You can contact me at blog@