SSH keys explained
SSH key authentication is the way you log into a server without a password: instead of typing a secret the server can check, your computer proves it holds a private key by signing a challenge the server sends, and the server verifies the signature against the public key it already has on file. The private key never crosses the network, so there is nothing to intercept, nothing to phish, and nothing to guess. This article explains how the two halves of a key pair work, which key type to choose in 2026, how fingerprints stop a middleman on your first connection, how to keep authorized_keys and known_hosts clean, and exactly what to do when a key leaks. To generate, inspect or convert a key in your browser, use the SSH Key Suite, and to check the passwords you still use, the Password Breach Check.
What SSH key authentication is
Every login is a question the server asks — are you who you claim to be? — and a password answers it by handing over the secret itself. That is the weakness of the whole arrangement: the secret travels, it can be overheard, it can be replayed, and it can be guessed, one attempt at a time, until it falls. SSH key authentication changes the answer. Instead of sending the secret, your computer signs a random challenge from the server with a private key that never leaves your machine, and the server checks the signature against the public key stored in your authorized_keys file. The proof is fresh every time, because the challenge is random; the secret never appears on the wire, so a listener learns nothing they can reuse, and there is no password to guess, because no password is involved at all.
The idea is older than the modern internet — public-key cryptography dates to the 1970s — but SSH made it the everyday way to reach a server, and the protocol has carried it ever since. When you run ssh user@server, the client and the server agree on a session, the server presents a challenge tied to your account, and your SSH agent signs it with the private key, usually after you unlock the key once with a passphrase. If the signature verifies, you are in. Nothing about the exchange depends on a shared secret the server also knows, which is why a breach of the server does not expose your credentials: the server holds only public keys, and a public key is useless for logging in. That asymmetry — the server can verify but cannot impersonate — is the whole security argument for keys, and it is also why losing control of the private half is the one failure that matters.
The public key and the private key
A key pair is two halves with opposite rules, and most SSH mistakes come from treating them the same. The public key is meant to be copied everywhere: paste it into authorized_keys on every server you use, into your Git hosting account, into any service that accepts SSH keys. It can be published in a public repository, printed on a slide, or emailed to an administrator, because all it lets anyone do is verify a signature. Knowing your public key gives an attacker nothing to log in with, in the same way that knowing your house number does not give anyone your front-door key. The public half is a lock, not a key, and locks are meant to be visible.
The private key is the key itself, and its rule is the exact opposite: it never leaves your machine, it is readable only by you, and it must never be pasted into a chat, a ticket, an email, a forum post or a shared document — not even to ask whether it is safe. Whoever holds it can log in as you on every server that trusts the matching public key, with no password prompt and no second factor in the way unless you configured one. On disk it lives in ~/.ssh, protected by file permissions — chmod 600, owner read-write only — and ideally by a passphrase, which encrypts the file so that a stolen copy is still useless without the words that unlock it. The passphrase is not part of the key; it is a padlock on the box the key sits in. Lose the box and the padlock is the only thing standing between the thief and your servers, which is why a private key without a passphrase should never leave a machine you fully control.
Ed25519 vs ECDSA vs RSA: which to choose in 2026
In 2026 the default answer is Ed25519, and it is the default this site generates. Ed25519 is a 256-bit elliptic-curve key: it generates in a fraction of a second, signs quickly, and produces a public key that fits on one short line. It has been supported by OpenSSH since 2014 and by every current server and client, and its security rests on a curve designed in the open with no suspicious constants. There is no practical reason to choose anything else for a new key unless something in your environment forces your hand. If you take one recommendation from this article, it is this: generate Ed25519, set a passphrase, and move on.
The other types exist for the exceptions. ECDSA on the NIST P-256 or P-384 curves is the right choice where policy demands NIST curves — some regulated environments and older hardware tokens specify them — and it is a sound fallback if a browser or device cannot generate Ed25519. RSA remains the universal fallback: RSA 2048 is the minimum worth using, RSA 3072 or 4096 the choice when the other side cannot do elliptic curves at all, which today mostly means very old systems and a few embedded devices. Anything below RSA 2048 — RSA 1024, DSA, ssh-dss — is legacy and should be retired: it is flagged as weak by the SSH Key Suite for exactly that reason. Key size is not the whole story, though: a 4096-bit RSA key copied to a laptop you no longer own is worse than a 256-bit Ed25519 key kept properly, because the failure mode of SSH keys is almost never the maths. It is the file.
Fingerprints and the first connection
The first time you connect to a server, SSH shows you something that looks like a random string of characters and asks whether to trust it: 256 SHA256:M8zvXkwyrGfPUmaHSSdA1aFQkH8AVSRycOxaZHru7dQ. That string is the fingerprint of the server’s host key — a hash of the server’s public key — and it is the only thing standing between you and a middleman. If the fingerprint matches the one your administrator published, or the one you verified through a separate channel, then the machine answering really is the server you meant to reach. If it does not match, stop: someone may be intercepting the connection, or the server may have been rebuilt with a new key, and either way the safe move is to check before typing yes. That prompt is SSH doing its most important job, and the people who get into trouble are the ones who train themselves to type yes without reading it.
You can verify a fingerprint before you ever connect, with ssh-keygen -lf, which prints one line per key: the bit size, the fingerprint, the comment, and the key type in brackets, for example 256 SHA256:… [email protected] (ED25519). The SSH Key Suite prints fingerprints in exactly this format, so a value you see in the browser can be compared character for character with what the server shows. Once you accept a host key, SSH saves it in ~/.ssh/known_hosts and warns you loudly — refusing to connect — if it ever changes. That warning is not an annoyance to work around with a flag; it is the alarm going off. The one routine exception is a server that was legitimately rebuilt, in which case the administrator should have published the new fingerprint in advance, and you remove the old entry with ssh-keygen -R hostname before reconnecting.
authorized_keys hygiene and known_hosts
Every line in a server’s authorized_keys file is a door, and doors stay open long after the person who needed them has left. A contractor’s laptop, a continuous-integration job, a key generated on a machine that has since been wiped, a colleague who changed teams two years ago — each one is a line that still works, and each one is a credential you are no longer watching. The audit is simple and worth doing every few months: copy the file, paste it into the Inspect tab of the SSH Key Suite, and look at what comes back. Duplicates — the same public key twice — mean someone pasted a key in again instead of checking, and should be collapsed to one line. Weak entries — RSA below 2048, DSA, ssh-dss — should be removed and replaced. And any line whose comment names a person, a machine or a purpose you no longer recognise should be treated as a door to close until its owner can claim it.
known_hosts deserves the same attention from the other side. It records the host key of every server you have connected to, and SSH checks each new connection against it. Some entries are hashed — |1| followed by base64 — which hides the hostname, a privacy feature for laptops that might be lost or inspected; the SSH Key Suite reports those entries as hashed rather than pretending they are readable, because a hashed entry cannot be verified against a published fingerprint, only trusted as already accepted. The file itself is also evidence: a known_hosts full of servers you no longer use is a map of where your credentials have been, and pruning it costs nothing. Together, the two files are the complete record of your SSH trust in both directions — who may log in as you, and which machines you trust to be themselves — and both of them rot quietly if nobody looks.
When a key leaks — and the passphrase note
A leaked key is not a mystery to investigate first and act on later; it is a key to replace, and the order of operations is short. Generate a fresh key pair. Remove the old public key from authorized_keys on every server and every service — your servers, your Git hosting, your deployment pipelines, anywhere the key was installed. Then check what the old key could reach and look for anything out of place: new authorized_keys lines you did not add, logins at hours you were not working, unfamiliar processes. If you find anything, treat it as a breach, not a scare, and investigate from there. What you must not do is delete the old private key from your laptop and consider the job done: deleting your copy does nothing about the copies that leaked, and the public key still sitting in authorized_keys is still a working door.
A passphrase does not change this checklist, but it changes how urgently you run it. A passphrase-protected key that leaks as a file is still a problem — an attacker can try to guess the passphrase offline, at machine speed — but a strong passphrase buys you the time to rotate before the guessing succeeds. An unencrypted key buys you no time at all, which is why this site is blunt about what its generator produces: version 1 generates unencrypted keys, with no passphrase option, because OpenSSH’s bcrypt KDF for encrypted private keys is version 2 scope. If you generate a key here, protect the file with chmod 600 and add a passphrase on your own machine with ssh-keygen -p — it takes ten seconds, it converts the file in place, and it is the single highest-value habit in this whole article. Generate the key, set the passphrase, install only the public half, audit the files twice a year, and verify every fingerprint before you trust it: that is the entire discipline, and it fits on an index card.