SSH key types (RSA / ED25519 / ECDSA) — what actually differs, and which one to pick

If you maintain WordPress sites over SSH — running wp-cli remotely, checking logs, transferring files with rsync — you're relying on SSH key authentication as the foundation. What rarely gets explained clearly is what you're actually choosing when ssh-keygen -t asks for an algorithm. This post walks through what RSA, ECDSA, and ED25519 actually rest on mathematically, and which one makes sense to pick today.

Note: SSH key authentication uses public-key cryptography. You keep a private key on your machine (never shared) and place a public key on the server (safe to share). The server issues a challenge that only the matching private key can answer, so you prove who you are without ever sending a password.

What actually differs between the three types

The main options you'll see with ssh-keygen -t <algorithm> are:

All three share the same core property — you can't forge a signature without the private key — but they differ in what mathematical hardness assumption they rely on and how the keys are generated.

Even though ECDSA and ED25519 are both "elliptic-curve" algorithms, they aren't interchangeable. ECDSA uses curve parameters standardized by NIST. ED25519 was published with parameters designed independently of any single government standards body. This distinction matters less as a practical threat and more as a design philosophy — it's part of why ED25519 tends to be preferred in contexts where provenance of the parameters is a concern.

Key size and the speed difference you'll actually notice

To reach a comparable security strength (roughly, how much computation a brute-force attack would require), the required key length varies a lot by algorithm. A commonly recommended 2048-bit RSA key is considered roughly comparable in strength to a 256-bit ED25519 key. Don't assume a longer bit count automatically means "more secure" — different math means different bit counts are needed for the same effective strength.

The difference you'll actually feel day to day is in how fast key generation, signing, and verification run. Because ED25519 keys are shorter, the cryptographic operations behind them are faster — ssh-keygen finishes quicker, and every login carries a lighter computational load. A large RSA key (4096 bits, say) does raise the security margin, but at the cost of heavier computation on every operation. If you connect over SSH frequently as part of routine maintenance, that difference adds up.

Which one should you actually use

Short answer: for a newly generated key today, ED25519 is the reasonable default, for three reasons:

1. Comparable strength at a much shorter key length — as noted, its ~256-bit key is roughly on par with a 2048–3072-bit RSA key
2. Faster in practice — generation, signing, and verification are all lighter
3. Less room for implementation mistakes — RSA implementations have historically had a string of vulnerabilities tied to poor randomness during key generation; ED25519's design leaves much less room for that class of implementation-specific bug

That said, there are real situations where ED25519 isn't the right — or even available — choice:

• Older servers or embedded network devices: environments running an OpenSSH version older than 6.5 (2014), or embedded SSH implementations with limited algorithm support, may not support ED25519 at all. RSA (2048 bits minimum, ideally 3072–4096) is the fallback there
• Compliance or internal policy requirements: if an audit or internal policy mandates a specific algorithm, follow that requirement
• ECDSA: given the NIST-parameter provenance question mentioned above, it's rarely the algorithm you'd actively choose for a brand-new key. There's no urgent need to replace ECDSA keys already in use, but it's a weak default for new ones

Generating a key (general steps)

# ED25519 (recommended) — the comment helps you identify the key later
ssh-keygen -t ed25519 -C "example-comment"

# RSA, when you need broader compatibility (3072 bits or higher recommended)
ssh-keygen -t rsa -b 4096 -C "example-comment"

Key generation prompts for a passphrase. That passphrase encrypts the private key file itself, so even if the file is stolen, it can't be used immediately. Leaving it blank means the security of your account rests entirely on the private key file never leaking — setting a passphrase is worth doing whenever practical.

The public key (the .pub file) gets appended to ~/.ssh/authorized_keys on the server side. The private key should never leave the machine it was generated on. When multiple people share access to a server, the right pattern is for each person to generate their own key pair and register only their public key — not to hand around a shared private key file.

Summary

Choosing an SSH key type isn't something you revisit often once decided, but understanding the reasoning behind it makes it easier to separate "older documentation defaulted to RSA because that's what was standard at the time" from "ED25519 is now the sensible default." For managing SSH access across multiple WordPress environments safely, see also using WP-CLI aliases to switch between multiple environments. Once your key is set up, organizing where you connect is covered in organizing per-host settings with ~/.ssh/config. For the layer beneath this one — why use a key instead of a password in the first place — see why SSH key authentication beats password authentication.