Benjamin Sago / ogham / cairnrefinery / etc…

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:

  1. The United States National Security Agency may have engineered a backdoor in the cryptography of RSA,
  2. 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!

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:

HostKey /etc/ssh/ssh_host_ed25519_key

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.