Technical notes › Use Ed25519 SSH keys
There are two reasons to prefer using Ed25519, instead of the default choice of RSA, as your SSH host key algorithm. These reasons are, ordered from least to most important:
- The United States National Security Agency may have engineered a backdoor in the cryptography of RSA,
- The keys come out, like, way shorter.
I’m not remotely qualified to discuss the cryptographic specifics of what the problem is with RSA. CloudFlare have a good write-up about it. I only found out about it when using Rebex SSH Check, which marked several of the key exchange algorithms I was allowing with “Possible NSA backdoor”. But while I’m certainly not a juicy enough target to warrant surveillance by any large three-letter organisations, changing to another key type was simple enough.
Who cares about all that stuff, though? Look at how short the keys are!
Generating Ed25519 keys
To generate a new set of private and public keys using this algorithm, pass the
-t ed25519 parameters to
ssh-keygen, like so:
ssh-keygen -t ed25519 -f example -C "I am a comment!"
Then, just copy the key to the machine with
ssh-copy-id, get the new fingerprint with
ssh-keyscan and add it to your
known_hosts — stopping briefly to see how beautifully short it now is — and connect.
Limiting OpenSSH algorithms
If you’re the only person who’s generating all the keys to your server, or if you can get everyone who needs access on board, you can limit the algorithms used during authentication to only the ones used by your set of keys.
On my servers, I have the following in
HostKey /etc/ssh/ssh_host_ed25519_key HostKeyAlgorithms email@example.com,ssh-ed25519 KexAlgorithms firstname.lastname@example.org,diffie-hellman-group-exchange-sha256 Ciphers email@example.com,firstname.lastname@example.org,email@example.com MACs firstname.lastname@example.org,email@example.com,firstname.lastname@example.org
This is not really “locking down SSH”, and calling it a security best practice is a bit of a stretch. But I do it anyway.