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!
cat example.pub
ssh-ed25519 AAAAC3NzaC1lZ/I1NTE5AAAAIKoYvrDVn8aALb/eiqtZ3tmU7ILnwbA0EIeGHkGurk1m
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 /etc/ssh/sshd_config
:
/etc/ssh/sshd_config
HostKey /etc/ssh/ssh_host_ed25519_key HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519 KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
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.∎