SSH Keys Explained Ed25519 vs ECDSA vs RSA (Hentikan Tekan Enter)

Every developer has done it. You type ssh-keygen, a wizard appears asking about key type, bit length, passphrase, output path — and you just hammer Enter until the randomart fingerprint shows up. Congrats, you now have an RSA-2048 key and no idea why that number.

Short answer: use Ed25519. Run ssh-keygen -t ed25519 -C "you@example.com" and stop reading StackOverflow answers from 2012. The rest of this guide explains why — and covers the legitimate cases where RSA is actually required.

The Three Algorithms

RSA

RSA (Rivest–Shamir–Adleman, 1977) has been the internet’s default public-key algorithm for decades. Its security relies on the difficulty of factoring large integers, which means you need large keys to stay safe — at minimum 2048 bits, preferably 4096. A 4096-bit RSA public key is roughly 800 bytes. Every connection involves arithmetic on those large numbers, which is slower than modern alternatives.

The only real argument for RSA is compatibility. Older SSH servers, legacy hardware, proprietary network appliances from the early 2010s — they all speak RSA. If you’re connecting to something that was provisioned during the Obama administration and never touched since, RSA might be your only option.

ECDSA

ECDSA (Elliptic Curve Digital Signature Algorithm) arrived as a faster, smaller alternative to RSA. A 256-bit ECDSA key gives roughly equivalent security to a 3072-bit RSA key. Better math, smaller key, faster operations — sounds like a win.

The issue is which curves OpenSSH uses by default: the NIST curves (P-256, P-384, P-521). These curves carry a legitimate concern. NIST’s involvement in elliptic curve standards is historically tainted — the agency helped standardize Dual_EC_DRBG, an NSA-influenced random number generator later found to contain a backdoor. ECDSA itself is not broken, but the NIST curve constants have opaque design criteria. Nobody can prove they weren’t chosen to give someone an asymmetric advantage. Most developers are not NSA targets, but there’s no reason to accept “probably fine” when a provably better option exists.

Ed25519

Ed25519 (EdDSA on Curve25519) is the one you should be using. It was designed by Daniel J. Bernstein with fully public design criteria — the curve parameters are derived from nothing-up-my-sleeve numbers, not from an opaque committee process.

The practical numbers: an Ed25519 public key is 68 bytes. Signing and verification are faster than both RSA and ECDSA. The algorithm is immune to timing side-channel attacks by construction — no secret-dependent branches, no variable-time operations. Support landed in OpenSSH 6.5 in 2014. GitHub, GitLab, and Bitbucket have all supported it for years. There is no downside compared to ECDSA and every upside compared to RSA.

Perbandingan Berdampingan

How to Generate Each Type

The default choice — use this:

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

Legacy system requires RSA? Use 4096 bits minimum:

ssh-keygen -t rsa -b 4096 -C "you@example.com"

ECDSA, if you have a specific reason to avoid Ed25519 (you probably don’t):

ssh-keygen -t ecdsa -b 521 -C "you@example.com"

If you want a UI instead of memorizing flags, the SSH Key Generator on IO Tools lets you pick algorithm, bit length, and passphrase options without touching a terminal.

When RSA Is Actually Required

There are legitimate cases where Ed25519 is not an option:

• Pre-2014 SSH daemons — anything running OpenSSH older than 6.5 won’t accept Ed25519. Uncommon, but real: embedded systems, network appliances, old RHEL 6 boxes that never had OpenSSH updated.
• FIPS-140-2 environments — federal and some regulated enterprise environments mandate FIPS-validated algorithms. Ed25519 is not FIPS-approved. Use RSA-3072+ or ECDSA with P-384 in those environments.
• Organizational SSH CA policy — some companies run their own SSH Certificate Authorities with enforced key type requirements. Check before generating a key that’ll get rejected at enrollment.

Outside these three cases, the argument for RSA is inertia, not merit.

The Passphrase You Skipped

Kapan ssh-keygen asks for a passphrase and you hit Enter to skip it, your private key sits on disk in plaintext. If someone gets your laptop, they get everything that key can access — every server, every Git host, every production environment. Add a passphrase. Use ssh-agent so you only type it once per session:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

On macOS, add --apple-use-keychain ke ssh-add so the passphrase survives reboots. On Linux, most desktop environments start ssh-agent automatically — check with echo $SSH_AUTH_SOCK.

You pressed Enter four times without reading. The passphrase prompt is the one worth going back for.

Anda mungkin juga menyukai

Baru

Open Graph Tags: Stop Your Links Looking Terrible on Slack

Baca selengkapnya "

Diperbarui pada Mei 15, 2026

Baru

HTTP Status Codes: When to Return 404 vs 410 vs 301 (and Stop Guessing)

Baca selengkapnya "

Diperbarui pada Mei 15, 2026

.gitignore — File yang Mencegah Anda Menyimpan node_modules

Baca selengkapnya "

Diterbitkan pada 30 Apr 2026

CRLF vs LF: Kesalahan Penghentian Baris yang Menghancurkan CI

Baca selengkapnya "

Diterbitkan pada 28 Apr 2026