The most surprising thing about SSH key algorithms is that the "best" one isn’t always the fastest or the most secure in isolation; it’s the one that balances security, performance, and compatibility with your specific environment.
Let’s see this in action. Imagine you’re setting up SSH access to a new server. You generate a key pair. For RSA, it might look like this:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
This creates id_rsa and id_rsa.pub in your ~/.ssh/ directory. The -b 4096 specifies a 4096-bit key, a common recommendation for RSA to maintain strong security.
Now, let’s try Ed25519, a more modern alternative:
ssh-keygen -t ed25519 -C "your_email@example.com"
This generates id_ed25519 and id_ed25519.pub. Notice there’s no bit size specified. Ed25519 uses a fixed, more efficient curve.
To use these keys, you’d copy the public key to the server’s ~/.ssh/authorized_keys file. On the server, you might then configure sshd_config (usually /etc/ssh/sshd_config) to prioritize certain algorithms or disable weaker ones. For example, to prefer Ed25519 and disable DSA:
PubkeyAcceptedAlgorithms +ssh-ed25519,ssh-rsa
PubkeyAcceptedAlgorithms -ssh-dss
The problem SSH key algorithms solve is secure authentication without passwords. Instead of sending a password over the network, which could be intercepted, you use a pair of mathematically linked keys. The private key stays secret on your machine, and the public key is shared. When you connect, your SSH client uses the private key to "sign" a challenge from the server. The server then uses your public key to verify that signature. If it matches, you’re authenticated.
Internally, these algorithms rely on different mathematical problems. RSA uses the difficulty of factoring large numbers. ECDSA and Ed25519 use the difficulty of the Elliptic Curve Discrete Logarithm Problem (ECDLP). DSA also uses a discrete logarithm problem, but on a different mathematical structure.
The key levers you control are the algorithm choice during key generation (-t), the key size (for RSA, -b), and how your SSH client and server are configured to accept or prefer specific algorithms. The ssh_config and sshd_config files are where you fine-tune this. For instance, to ensure your client always tries Ed25519 first when connecting to a specific host:
Host myserver.example.com
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
The IdentitiesOnly yes is crucial here; it tells the client to only try the specified IdentityFile and not cycle through all your other keys, which can be both a security and performance optimization.
DSA keys, while historically common, are now largely deprecated due to known weaknesses and are generally not recommended for new key generation. Ed25519 offers a strong security guarantee with much smaller key sizes and faster signature generation compared to equivalent-security RSA keys, making it a frequent choice for modern deployments where compatibility isn’t an issue. ECDSA provides a good balance, often performing better than RSA with comparable security levels.
The primary trade-off is often between the raw computational cost of generating and verifying signatures versus the length of the key itself and the underlying mathematical complexity. Faster algorithms like Ed25519 can significantly speed up the authentication handshake, which is noticeable when connecting to many servers or in high-traffic environments.
When you specify PubkeyAcceptedAlgorithms on the server, you’re not just telling sshd which algorithms are allowed, but also the order in which it will attempt to use them for authentication. The first algorithm in the list that matches a key offered by the client will be used.
The next concept you’ll likely grapple with is managing multiple SSH keys and ensuring the correct one is presented to the server, especially when dealing with different accounts or services.