Server authentication: strategically harden SSH

Authentication is all about proving that you are who you say you are. The reverse is also relevant: how do you know who to trust? When it comes to SSH, authentication immediately follows the key exchange. Much like the key exchange, authentication involves a lot of complicated mathematics. Let’s skip the mathematics and dig into the operational details instead. This article shows you how to properly set up server authentication.

Server authentication

How do you ever know you’re actually connecting your client to the right server? There is room for a lot of mischief between you and a server somewhere out there on the internet. DNS may be poisoned, BGP may have been fudged, your local machine may have even had its hosts-file changed. We need a way to defend against this kind of threats. Server authentication using cryptography is the answer. OpenSSH contains four algorithms you can use to prove your server’s identity. Sadly, only two of them are safe to use (I don’t trust NIST): Ed25519-SHA512 and RSA-SHA1.

Ed25519 uses elliptic curve crypto, which you may or may not trust. I would, mainly because this particular flavor does not use NIST constants. If you choose to skip ECC crypto, you’re left with RSA-SHA1 which uses an essentially broken hash function. In this particular case that’s not an immediate cause for alarm. That’s because the SHA1 function is being used here to sign a pre-existing SHA2 hash. Complicated, I know, but your security in this case hinges on SHA2 which is good.

Put either of the lines below, or both of them, into your sshd_config file, remove any existing keys and regenerate proper host keys.

HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

This is how you regenerate keys:

ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""

Restart your SSH server and it’ll pick up the new keys. Any connecting clients will need to accept the new fingerprint. It’s fairly likely that the script that starts SSH at boot will recreate unused host keys if you removed them. That’s not really a problem. They’ll just sit there unused, taking a tiny bit of disk space.

After this, your server will only attempt to prove its identity to clients using secure algorithms.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.