SSH Keys Explained

Every guide to setting up a server eventually says the same thing: "generate an SSH key and add it to authorized_keys." Most people do it once, copy-paste a command, and never think about it again — which is fine, until something goes wrong: a connection is refused with a cryptic fingerprint warning, a CI pipeline can't authenticate, or someone asks whether RSA or Ed25519 is the right choice for a new key. This post covers what an SSH key actually is, how the three algorithms you'll encounter differ, and what a fingerprint is really checking.

How SSH key authentication actually works

SSH key authentication is asymmetric, the same category of cryptography behind TLS (see TLS Explained): two mathematically linked keys, one public and one private, where the private key can prove possession of itself without ever being revealed. You generate a pair once, leave the private key on your machine, and copy only the public key to every server you want to log into.

Logging in doesn't transmit the key at all — it's a challenge-response exchange. The server already has your public key on file from setup; when you connect, it sends a random challenge, your client signs it with the private key, and the server verifies that signature against the public key it already has. A valid signature proves you hold the matching private key without that key ever crossing the network, even in encrypted form.

This is also why a leaked authorized_keys file or a leaked .pub file isn't a security incident by itself — the public key was always meant to be shared. A leaked private key is the actual emergency, because it's the only half that can produce a valid signature.

RSA, Ed25519, and ECDSA — the three algorithms in the wild

Run ssh-keygen -t with tab completion and you'll see several algorithm choices, but almost everything you'll actually encounter falls into three families:

• RSA is the oldest and most universally supported, based on the difficulty of factoring the product of two large primes. Its security scales with key size, which is why RSA keys come in a choice of bit lengths (2048, 3072, 4096) rather than a fixed size — see AES vs RSA for how that size relates to actual security strength. The tradeoff is speed: RSA signing is slower than the alternatives, and its keys are physically larger for equivalent security.
• Ed25519, based on elliptic curve cryptography over Curve25519, is what OpenSSH itself has recommended as the default since it landed in OpenSSH 6.5 (2014). It has one fixed size — 256-bit — so there's no size decision to make, it signs and verifies faster than RSA, and its keys are dramatically smaller (a public key fits in a few dozen characters). Unless you have a specific reason not to, this is the right default for a new key in 2026.
• ECDSA is also elliptic-curve-based, using one of three NIST curves (P-256, P-384, or P-521) rather than Curve25519. It's faster than RSA and roughly comparable to Ed25519 in performance, but it depends on high-quality randomness at signing time in a way Ed25519's design specifically avoids — a weak random number generator can leak an ECDSA private key through its signatures, a real failure mode that has happened in the wild. This is the main reason security guidance generally prefers Ed25519 over ECDSA for new keys, even though both are elliptic-curve algorithms.

All three remain valid choices for connecting to existing infrastructure — the difference mostly matters when you're generating a brand new key and get to pick.

What an SSH key actually looks like

A public key is a single line: an algorithm identifier, a base64-encoded blob of the actual key data, and an optional comment (often user@host, purely a label with no cryptographic meaning):

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH4SFEQVz/ZOxi52tDrc0Xrz5d25HF6I4S+EvW2AX3hz alex@laptop

That base64 blob isn't arbitrary — it's OpenSSH's own binary wire format: the algorithm name and key material, each framed as a 4-byte length followed by that many bytes. RSA's blob holds its public exponent and modulus; Ed25519's holds a raw 32-byte public key; ECDSA's holds a curve identifier and an elliptic curve point. Decoding that structure is exactly what a fingerprint viewer or key inspector does under the hood.

Private keys have a more tangled history. Older keys use a PEM-wrapped format — -----BEGIN RSA PRIVATE KEY----- or a generic -----BEGIN PRIVATE KEY----- (PKCS8). Since OpenSSH 7.8 (2018), though, ssh-keygen generates every key type — RSA and ECDSA included, not just Ed25519 — in OpenSSH's own custom container by default, recognizable by its -----BEGIN OPENSSH PRIVATE KEY----- header. Functionally it doesn't change how you use the key; it's worth knowing mainly so an unfamiliar header on an otherwise normal-looking key file doesn't look suspicious.

What a fingerprint is checking

A fingerprint is a cryptographic hash — SHA256 by default in current OpenSSH — of a public key's raw data, shown as a short base64 string prefixed SHA256:. It exists because comparing two multi-hundred-character base64 blobs by eye is unreliable, but comparing a 43-character hash is fast and exact.

The most common place you'll see one is the "authenticity of host … can't be established" prompt the very first time you connect to a new server. That fingerprint identifies the server's key, not yours — SSH uses the same asymmetric scheme in both directions, so the server proves its identity to you the same way you prove yours to it. Confirming that fingerprint against one you already trust (from the server's documentation, or a value you saved the first time) is what actually prevents a machine-in-the-middle from silently swapping in a different server. Older tooling sometimes shows an MD5 fingerprint instead — the same idea, just a weaker and now-deprecated hash function.

Host keys and user keys are the same mechanism, used in both directions

Everything above describes a user key — the pair you generate to prove your own identity to a server. A host key is the exact same kind of key pair, generated once by the server itself (usually during OS installation) to prove its identity to anyone connecting. That's the key behind the "the authenticity of host … can't be established" prompt: your client is being shown the server's public key for the first time and asking whether to trust it.

Accepting that prompt without checking anything is trust-on-first-use — fine for a personal VPS you just provisioned yourself, considerably riskier on a network where a machine-in-the-middle could present its own key instead of the real server's. Whatever you accept gets cached in ~/.ssh/known_hosts; if the server's key ever changes unexpectedly afterward, SSH refuses to connect and warns loudly, which is exactly the behavior that catches a substituted server on a later connection even if the very first one was accepted blind.

Choosing a key size

This only applies to RSA, since it's the one algorithm here where size is a choice rather than a fixed property. 2048-bit is the floor most systems still accept; 3072-bit is a reasonable default for a key expected to stay in service for years; 4096-bit is the most conservative common choice, at the cost of slower key generation and slightly slower handshakes. Ed25519 has no equivalent decision — it's always 256-bit — and each ECDSA curve is likewise a fixed size (256, 384, or 521-bit) determined entirely by which curve you pick.

Common mistakes and good practice

• Treating the private key like any other file. It should never be copied to another machine casually, emailed, committed to a repository, or pasted into a web tool — including this site's own tools, none of which accept a private key as input for exactly this reason.
• Loose file permissions. OpenSSH refuses to use a private key file that's readable by anyone but its owner — chmod 600 after saving one.
• Skipping a passphrase on a key with broad access. A passphrase encrypts the private key file at rest, so a stolen laptop or backup doesn't hand over usable credentials on its own — worth the extra prompt on login for any key that can reach production systems.
• Reusing one key pair everywhere. A single compromised key that's authorized on every server you touch is a much larger blast radius than one scoped to a specific purpose or host.

FAQ

Try it yourself

SSH Key Generator generates a real Ed25519 or RSA pair entirely in your browser, formatted exactly as OpenSSH expects. If you already have a key and want to check its type, fingerprint, or bit length instead — an SSH key checker rather than a generator — SSH Key Inspector works as an SSH fingerprint viewer for any standard RSA, Ed25519, or ECDSA public key, matching ssh-keygen -l exactly. Once a key exists, SSH Config Generator builds the ~/.ssh/config block that ties a host alias to it — covered in full in SSH Config File Guide.