RSA vs Ed25519: which SSH key should you use in 2026?

Ayan Hussain

Jul 26, 2026 · 7 min read

If you search for how to generate an SSH key, many tutorials still tell you to run ssh-keygen -t rsa. You should ignore them.

The industry has moved on. If you are setting up a new server today, you should be using Ed25519 keys. RSA still works, but it is the older, slower, larger option — and a specific deprecation in OpenSSH 8.8 means old RSA configurations will actively break on modern servers.

Here is what the difference actually is, why it matters, and how to migrate if you are still using RSA.

What is RSA and why is it still around?

RSA (Rivest-Shamir-Adleman) was published in 1977. It became the standard public-key cryptographic algorithm for decades because it was robust, well-understood, and supported everywhere.

RSA security is based on a simple but computationally hard problem: given a very large number that is the product of two prime numbers, find those primes. As computers have gotten faster, the size of the numbers required to make this problem hard has grown significantly.

In 2010, a 1024-bit RSA key was considered adequate. By 2016, NIST recommended phasing out 1024-bit and moving to 2048-bit. Today, 4096-bit is the accepted standard for RSA keys used in SSH. That is a 256-byte key just for the private half.

Larger keys mean slower operations. Generating a 4096-bit RSA key takes noticeably longer than generating an Ed25519 key. The handshake is slower. The authorized_keys file is much larger. None of this is catastrophic, but it adds up at scale.

The SHA-1 deprecation problem

Here is the specific issue that actively breaks things: OpenSSH 8.8, released in September 2021, disabled RSA signatures that use SHA-1 hashing by default.

Many older RSA key deployments relied on ssh-rsa (RSA + SHA-1). When those users tried to connect to a server running OpenSSH 8.8+, they got:

Unable to negotiate with x.x.x.x port 22: no matching host key type found.
Their offer: ssh-rsa

Ubuntu 22.04 and later ship with OpenSSH 8.9+, so this is not a hypothetical. If you have old RSA keys lying around and you are connecting to recently provisioned servers, you may run into this.

The fix is either to upgrade to Ed25519 keys (the right solution) or to add PubkeyAcceptedKeyTypes +ssh-rsa to your SSH config file (the workaround that postpones the problem).

What is Ed25519?

Ed25519 is a digital signature algorithm based on elliptic curve cryptography. It was designed by cryptographers Daniel J. Bernstein and Tanja Lange and introduced in 2011. OpenSSH added support for it in version 6.5, released in 2014. Every modern SSH client and server supports it.

Instead of relying on prime factorization (RSA's approach), Ed25519 relies on the mathematical properties of the Curve25519 elliptic curve. The security model is fundamentally different.

The practical results:

Key size. An Ed25519 public key is 68 characters long. A 4096-bit RSA public key is over 700 characters. The private keys are similarly smaller. This matters when you have many authorized_keys files to manage.

Speed. Ed25519 key operations are significantly faster than RSA 4096 operations. On a modern laptop, Ed25519 key generation takes milliseconds. RSA 4096 takes a few seconds. SSH handshakes with Ed25519 keys establish faster.

Security level. A standard Ed25519 key provides approximately 128 bits of security, comparable to a 3000-bit RSA key. Ed25519 at 128 bits is considered strong well beyond any foreseeable computing advances, including anticipated improvements in classical (non-quantum) computing.

Generating an Ed25519 key

Generating a new Ed25519 key pair is one command:

ssh-keygen -t ed25519 -C "your_email@example.com"

When prompted:

Accept the default location (~/.ssh/id_ed25519) unless you have a reason to change it.
Set a strong passphrase. This encrypts the private key file itself, so if the file is stolen, it cannot be used without the passphrase.

This produces two files:

~/.ssh/id_ed25519 — your private key. Never share this or copy it to remote servers.
~/.ssh/id_ed25519.pub — your public key. This goes on servers you want to access.

To add the public key to a server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server

Or manually append it:

cat ~/.ssh/id_ed25519.pub | ssh user@your-server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Migrating from RSA to Ed25519

If you have an existing RSA key pair, here is how to migrate without losing access to any servers.

Step 1: Generate the new Ed25519 key pair (as above).

Step 2: Add the new public key to every server you care about. Use ssh-copy-id with your existing RSA key for authentication:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server

Do this for all your servers while you still have access via the RSA key.

Step 3: Verify the new key works. Explicitly tell SSH to use the new key:

ssh -i ~/.ssh/id_ed25519 user@your-server

If you get a successful login, the new key is installed correctly.

Step 4: Update services that use your public key. GitHub, GitLab, Bitbucket, and other services store your public key separately. Log into each service and add your new Ed25519 public key under SSH Keys settings. You can keep both keys active during the transition, then remove the old RSA key once everything is updated.

Step 5: Update your ~/.ssh/config to prefer the new key:

Host *
  IdentityFile ~/.ssh/id_ed25519
  IdentityFile ~/.ssh/id_rsa

Listing Ed25519 first tells SSH to try it before falling back to RSA.

Step 6: Remove the old RSA public key from ~/.ssh/authorized_keys on each server once you are confident everything is working.

Compatibility: where does Ed25519 not work?

Ed25519 has been supported in OpenSSH since 6.5 (2014). For modern Linux servers, there is no compatibility concern.

The cases where you might still need RSA:

Very old servers. Systems running OpenSSH older than 6.5, or ancient embedded Linux systems. This is rare outside of legacy enterprise environments.
Windows SSH implementations. Older versions of WinSCP, PuTTY (before 0.68), and some Windows SSH libraries did not support Ed25519. Modern versions of all of these now support it.
Some network devices. Cisco IOS and some other network operating systems were slow to add Ed25519 support. Check your vendor's documentation if you manage network hardware.

For cloud providers: AWS, Google Cloud, Azure, and DigitalOcean all support Ed25519 keys natively. When you import a key pair into AWS EC2, you can paste an Ed25519 public key and it works the same way as RSA.

What about ECDSA?

ECDSA (Elliptic Curve Digital Signature Algorithm) is another elliptic curve algorithm supported by OpenSSH. It is faster than RSA and smaller, but it has two disadvantages compared to Ed25519:

ECDSA implementations have historically been vulnerable to bad random number generation. A weak random number generator can leak the private key. Ed25519 uses a deterministic algorithm that avoids this class of vulnerability entirely.
ECDSA key generation uses NIST curves (P-256, P-384, P-521). There is a community skepticism about NIST curves because their design included input from the NSA. Ed25519 uses Curve25519, which was independently designed with published, audited parameters.

In practice, ECDSA is fine. But given that Ed25519 is equally fast and avoids both concerns, there is no good reason to choose ECDSA over Ed25519 for new deployments.

Summary

| | RSA 4096 | ECDSA P-256 | Ed25519 | |---|---|---|---| | Key size (public) | ~700 chars | ~200 chars | 68 chars | | Speed | Slower | Fast | Fast | | Security level | ~140 bits | ~128 bits | ~128 bits | | SHA-1 deprecation issue | Yes (old keys) | No | No | | OpenSSH support since | Always | OpenSSH 5.7 (2011) | OpenSSH 6.5 (2014) | | Recommended for new keys | No | Acceptable | Yes |

Generate Ed25519. Use a passphrase. Copy the public key to your servers. That is the entire recommendation.

If you manage your servers through SSHDock, both RSA and Ed25519 keys work. Just paste your private key into the connection form and it handles the rest.