Skip to content
AZ Tools

SSH Public Key Inspector

Takes the lines you already have in authorized_keys or known_hosts and tells you what is actually in them. For each key it reports the algorithm, the real key size read out of the key material rather than guessed from the line, the SHA256 fingerprint in the form modern OpenSSH prints, the legacy colon-separated MD5 fingerprint that older servers and cloud consoles still show, and whatever comment and options are attached. That is usually enough to answer the question you opened the file for: which of these six keys is the laptop I lost, and does this host key match the fingerprint the documentation published. It also catches things that are invisible when you skim a key line. The algorithm name is written twice — once as the first word of the line and once inside the base64 blob — and only the second one is what a server matches against, so a key relabelled by a copy-paste looks perfectly normal and silently never authenticates. The same goes for an ECDSA curve name that disagrees with the algorithm it is filed under, a truncated blob that still base64-decodes, an RSA key below the 2048-bit floor, and ssh-dss, which OpenSSH disabled by default in 7.0 and removed entirely in 9.8. If you paste a private key by mistake it refuses to touch it and says so. Everything runs in the browser; no key is uploaded.

How to use

  1. Paste one or more public key lines — a whole authorized_keys or known_hosts file works, and comment lines beginning with # are skipped.
  2. Read the SHA256 fingerprint to compare against a published host key fingerprint, or the MD5 one if the system you are checking against still prints that form.
  3. Use the key size and algorithm to find the entries worth rotating: anything ssh-dss, and any RSA key under 2048 bits.
  4. Check the comment and options columns to work out which machine each key belongs to before you delete a line.
  5. Anything flagged in amber is a key that will not behave the way the line makes it look — read the warning before trusting the entry.

Frequently asked questions

Why does my fingerprint not match the one ssh-keygen printed?
The most likely reason is that you are comparing different hash forms. Since OpenSSH 6.8 the default is SHA256 shown as unpadded base64, like SHA256:uNiVzt…; before that it was MD5 shown as colon-separated hex. They are fingerprints of exactly the same bytes, so neither is more correct, but they never look alike. This tool prints both so you can match whichever the other side is showing. If both forms differ, the keys genuinely differ — the fingerprint covers the base64 blob only, so a changed comment or changed options cannot affect it.
What is the difference between the algorithm on the line and the one inside the key?
An OpenSSH public key line writes the algorithm name twice: once as the first word, and once as the first length-prefixed field inside the base64 blob. Only the copy inside the blob is part of the key; the first word is a label, and nothing in the usual workflow checks that the two agree. So a line edited by hand, or assembled from two keys by a bad copy-paste, can read ssh-rsa while carrying an Ed25519 key. It looks completely ordinary in a file, and it simply never authenticates. This tool compares the two and tells you when they disagree.
Is it safe to paste a key here?
A public key, yes — it is public by design, and this page never sends it anywhere. All the parsing and both hashes run in your browser, and you can confirm that by loading the page and then disconnecting from the network; it keeps working. A private key is a different matter: never paste one into any web page, including this one. If the input starts with a PRIVATE KEY header the tool refuses to process it and says so, rather than quietly parsing it.
How big should an SSH key be?
For new keys, Ed25519 is the usual recommendation: it is fixed at 256 bits, small, fast, and has no parameters to get wrong. If you need RSA for an old server, 2048 bits is the current floor and 4096 is the common choice; below 2048 both OpenSSH and most certificate authorities now refuse the key. Note that RSA key sizes are not comparable to Ed25519 key sizes — a 256-bit Ed25519 key is roughly as strong as a 3072-bit RSA key, because the numbers measure different things. ECDSA on nistp256 is fine where Ed25519 is unavailable.
Why is ssh-dss flagged even though my key works?
Because it works only where something old is still accepting it. DSA keys in OpenSSH are fixed at 1024 bits, which is below every current recommendation, and the implementation is unusually sensitive to bad randomness — a repeated nonce leaks the private key outright. OpenSSH disabled ssh-dss by default in version 7.0, and 9.8 removed the code entirely, so any server you upgrade will stop accepting the key without warning. If a key of this type is still in an authorized_keys file, it is worth replacing before the upgrade rather than after.
Can it read known_hosts lines and certificates?
known_hosts lines are handled: the leading host patterns are separated from the key rather than being mistaken for part of it, and that includes hashed entries beginning with |1| and markers such as @cert-authority and @revoked. authorized_keys option strings — command="…", no-pty, from="…" — are separated the same way. OpenSSH certificates (the *-cert-v01@openssh.com types) are recognised and fingerprinted, but their body is not decoded, so you will not see the principals or the validity window here.

Related tools