Time to time the SSH server identity changes as the certificated was recreated. To prevent a man-in-the-middle attack, it’s necessary to verify the source server identity…
Since the SSH server and client are generally capable of multiple assymmetric cryptography methods (e.g. DSA, ECDSA, RSA), it is important to identify, which one is being utilized between the server and the client. If not sure, the easiest (“brute-force”) way is to check all available server keys and compare them with the announced one on the client side.
The public keys are located in
/etc/ssh/. After finding all files containing
pub in their names, it is handy to execute a tiny bash script as follows:
for i in $(ls /etc/ssh | grep pub); do ssh-keygen -l -f /etc/ssh/$i; done
The command produces results similar to the following:
1024 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f root@servername (DSA) 256 01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f:00 root@servername (ECDSA) 256 02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f:00:01 root@servername (ED25519) 2048 03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f:00:01:02 root@servername (RSA1) 2048 04:05:06:07:08:09:0a:0b:0c:0d:0e:0f:00:01:02:03 root@servername (RSA)
The client software stores all keys in the
~/.ssh/known_hosts file. During the first login attempt the following query will occur:
The authenticity of host 'SERVER.TLD (IP.ADDRESS)' can't be established. ECDSA key fingerprint is 01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f:00. Are you sure you want to continue connecting (yes/no)?
If the fingerprints reported by the client and the one calculated on the server differ, then there is a man-in-the-middle to eavesdrop the communication.