SSH Key Suite
SSH key authentication replaces a password with a pair of mathematically linked keys: a private key that never leaves your machine and a public key you install on every server you log into. The server challenges your machine to prove it holds the private key, and the proof works without the secret ever crossing the network. This page generates Ed25519, ECDSA and RSA keys in OpenSSH format, audits your authorized_keys and known_hosts files for weak, duplicate and stale keys, and converts keys between PEM, OpenSSH and JWK formats — all in your browser, with nothing uploaded. The companion guide, SSH keys explained, covers choosing a key type and what to do when a key leaks. Pair it with the Password Breach Check for the passwords you still use, and the Certificate Key Matcher and PGP Suite for the rest of your key material.
Last updated:
Your private key never leaves this page
Every key is generated, parsed and converted in your browser. The private key is never uploaded, never stored and never logged, and it never appears in a URL. Download it once, protect it with chmod 600, and add a passphrase with ssh-keygen -p if you need one. Read the full guide at SSH keys explained.
Generate a new SSH key pair
Results
Inspect and audit keys
Paste the contents of <code>~/.ssh/authorized_keys</code> or <code>~/.ssh/known_hosts</code>, or a single public-key line. Hashed <code>known_hosts</code> entries are reported as hashed, never silently skipped. Passphrase-protected private keys cannot be parsed here — that is a clear error, not a fake result.
A text file with keys, one per line. Lines that cannot be parsed are listed as unparsed, never silently dropped. The file is read on this device only and is never uploaded.
Or drop the file anywhere in this box. Limit: 2 MB.
Results
Convert a key
Convert a public key between OpenSSH, PEM and JWK, or an unencrypted private key between OpenSSH and PKCS#8 PEM. Every conversion shows the fingerprint before and after, so you can verify it is the same key. Passphrase-protected keys are not supported in version 1.
Results
The honest limits
Version 1 generates unencrypted keys: there is no passphrase option here, because OpenSSH’s bcrypt KDF for encrypted private keys is version 2 scope. Protect the downloaded file with chmod 600 and add a passphrase with ssh-keygen -p if you need one.
Ed25519 generation needs a current browser. If yours does not support it, this page says so plainly and offers ECDSA P-256 instead — it never fakes an Ed25519 key or silently downgrades you.
Never paste a private key into a chat, a ticket, a forum post or a shared document — not even to ask whether it is safe. A private key that has been pasted anywhere must be treated as leaked: replace it and remove the old public key from every authorized_keys file.
What SSH key authentication is — and why it beats a password
SSH key authentication replaces a typed secret with a mathematical proof. When you log into a server with a key, the server sends your machine a random challenge; your machine signs it with the private key, and the server verifies the signature against the public key in authorized_keys. The private key never crosses the network, so there is nothing for a keylogger to steal, nothing to phish, and nothing to guess — an attacker cannot brute-force a 256-bit Ed25519 key the way they can brute-force a password, because there is no password to try.
The two halves have opposite rules. The public key is meant to be copied everywhere: paste it into authorized_keys on every server, into your Git hosting account, into any service that accepts it. It only lets the other side verify a proof, so publishing it costs nothing. The private key is the opposite: whoever holds it can log in as you, on every server that trusts the matching public key. That is why it lives in ~/.ssh, readable only by you, and why it must never be pasted into a chat, a ticket, an email or a shared document — the moment it appears in any of those places, it is leaked, and the only fix is to replace it everywhere.
Choosing a key, checking fingerprints, and keeping the files clean
In 2026 the default choice is Ed25519: a 256-bit key that is faster to generate and sign than RSA, with a public key that fits on one short line. ECDSA P-256 is the fallback when a policy or an old system insists on NIST curves, and RSA 3072 or 4096 is the answer only when the other side cannot do elliptic curves at all — RSA 2048 is the floor, and anything smaller is flagged weak by this page. The key type matters less than the hygiene around it: a strong key left in a world-readable file, or copied to a laptop you no longer own, is worse than a modest key kept properly.
Fingerprints are how you know you are talking to the right machine. The first time you connect to a server, SSH shows you the server’s host key fingerprint and asks you to trust it; that fingerprint is a hash of the server’s public key, and if it matches the one your administrator published, no one is sitting in the middle. Save it, and SSH will warn you loudly if it ever changes. The same fingerprints identify your own keys: ssh-keygen -lf prints one line per key, and this page prints fingerprints in exactly the same format, so the values you see here can be compared character for character with the server.
The files deserve a regular audit, because keys accumulate. Every authorized_keys line is a door into a server, and the doors stay open long after the person who needed them has left: a contractor’s laptop, a CI job, a key generated on a machine that has since been wiped. Paste the file into the Inspect tab and this page counts the keys, flags duplicates, marks weak and legacy types, and lists lines it could not parse instead of dropping them quietly. Do the same for known_hosts, where hashed entries hide the hostname — this page reports them as hashed rather than pretending they are readable. A ten-minute audit every few months is the cheapest security work a server owner ever does.
The suite, in plain terms
| Ed25519 | A modern elliptic-curve key: 256 bits, fast, and small. The recommended default for new keys in 2026, supported by every current SSH server and client. |
| ECDSA P-256 / P-384 | Elliptic-curve keys on the NIST P-256 and P-384 curves. A good fallback when Ed25519 is unavailable, and the standard choice where policy demands NIST curves. |
| RSA 2048 / 3072 / 4096 | The classic key type. RSA 2048 is the minimum worth using; 3072 and 4096 buy margin at the cost of slower signing. Anything below 2048 is flagged weak. |
| Public key | The half you install on servers, in authorized_keys. It can be shared freely — it only lets someone verify a proof, never make one. |
| Private key | The half that never leaves your machine. Whoever holds it can log in as you. Protect it with chmod 600, a passphrase, and never paste it anywhere. |
| Fingerprint | A short hash of the public key, printed as SHA256:… or MD5:… Exactly what ssh-keygen -lf prints, so you can compare it with what the server shows. |
| authorized_keys | The file on a server (~/.ssh/authorized_keys) listing the public keys allowed to log in. Every line is a door; stale lines are doors you forgot you opened. |
| known_hosts | The file on your machine (~/.ssh/known_hosts) recording each server’s host key. It is what lets SSH warn you when a server’s key suddenly changes. |
| PEM / JWK | Two other key encodings: PEM is the base64 text format used by TLS tools and OpenSSL; JWK is the JSON format used by web APIs. Converting never changes the key itself. |
Frequently asked questions
Which key type should I choose?
Ed25519 for almost everything: it is fast, small, and secure at 256 bits, and every current server supports it. Choose ECDSA P-256 only if a policy or an old system demands NIST curves, and RSA 3072 or 4096 only if the other side cannot do elliptic curves at all.
Is the generated private key encrypted?
No. Version 1 generates unencrypted keys with cipher none, exactly like ssh-keygen without a passphrase. Download it, set chmod 600, and if you want a passphrase, run ssh-keygen -p -f your-key — that adds OpenSSH’s bcrypt protection on your own machine.
Why does Ed25519 fail in my browser?
Ed25519 key generation needs WebCrypto Ed25519 support, which older browsers lack. This page detects that and tells you, instead of faking the key. Use ECDSA P-256 as the fallback, or update your browser and try again.
Can I paste my private key here to check it?
You can paste an unencrypted OpenSSH private key and this page will parse its public part locally — but think twice. The safer habit is to paste only public keys and authorized_keys files. A passphrase-protected private key is rejected with a clear error, never parsed.
What do I do if a key leaks?
Generate a fresh key pair, remove the old public key from authorized_keys on every server and service, and treat anything the old key could reach as exposed until you have checked it. The full checklist is in the guide SSH keys explained.