Ed25519 keys are significantly faster to generate and use than RSA keys, offering equivalent or better security for most practical purposes.
Let’s see how this plays out in practice.
First, generate an Ed25519 key pair:
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "your_email@example.com"
This command creates two files in your ~/.ssh/ directory: id_ed25519 (your private key) and id_ed25519.pub (your public key). The -t ed25519 flag specifies the algorithm, -f sets the output filename, and -C adds a comment, often used for identification.
Now, let’s generate an RSA key pair of a commonly recommended size:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -C "your_email@example.com"
This does the same but uses the RSA algorithm (-t rsa) and a key length of 4096 bits (-b 4096).
You can then add these public keys to your ~/.ssh/authorized_keys file on a remote server. For example, to add the Ed25519 public key:
cat ~/.ssh/id_ed25519.pub | ssh user@your_server_ip 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'
The core problem these keys solve is secure authentication without passwords. When you try to SSH into a server, your client uses your private key to sign a challenge sent by the server. The server then uses your public key (which it has stored) to verify the signature. If it matches, you’re authenticated.
Internally, Ed25519 uses a different mathematical approach based on elliptic-curve cryptography (ECC), specifically the Curve25519 curve. RSA relies on the difficulty of factoring large numbers. ECC algorithms like Ed25519 are generally more efficient for the same level of security. This translates to faster key generation, quicker authentication handshakes, and less CPU usage during the connection.
The exact levers you control are the algorithm type (-t) and, for RSA, the bit length (-b). For Ed25519, the bit length is fixed at 256 bits, which is considered strong. For RSA, 2048 bits is often considered the minimum, with 4096 bits providing a higher security margin.
When you configure your SSH client or server to prefer one type over another, you’re influencing the initial negotiation. A common way to prioritize Ed25519 is by editing your SSH client configuration file, ~/.ssh/config. Add these lines:
Host *
IdentityFile ~/.ssh/id_ed25519
IdentityFile ~/.ssh/id_rsa
HostKeyAlgorithms +ssh-ed25519-cert-v01@openssh.com,ssh-ed25519
PubkeyAcceptedAlgorithms +ssh-ed25519-cert-v01@openssh.com,ssh-ed25519
This tells your SSH client to try using the id_ed25519 key first and to prefer Ed25519 algorithms for authentication. The HostKeyAlgorithms and PubkeyAcceptedAlgorithms directives ensure that the server also agrees to use these modern algorithms.
The most surprising thing about Ed25519 compared to RSA, especially when thinking about security, is how much smaller and faster it is for comparable security levels. A 256-bit Ed25519 key is roughly equivalent in security to a 3072-bit or even a 4096-bit RSA key, but the underlying mathematical operations are dramatically less computationally intensive. This efficiency isn’t just a theoretical advantage; it translates directly into snappier SSH sessions, especially on resource-constrained devices like Raspberry Pis or older servers.
The next thing you’ll likely want to configure is how to manage multiple SSH keys for different hosts, often using ~/.ssh/config.