Conchshell
ENRU
Download

SSH key fingerprints, as ssh-keygen prints them

Paste a .pub file, an authorized_keys file or a known_hosts file — or open one. Every key in it gets its type, size and comment, and both fingerprints: SHA256 in base64, the way ssh-keygen -lf prints it today, and MD5 in hex, the way older tools and some hosting panels still show it.

A known_hosts with hashed names (|1|…) is read too. The names in such a file cannot be recovered, but you can ask whether a host you name has an entry — the same HMAC-SHA1 test ssh itself runs.

Paste or open the file

Nothing is uploaded: the script on this page has no fetch, no XMLHttpRequest and no form submission in it. SHA-256 and HMAC-SHA1 are computed by the browser’s own WebCrypto, MD5 by the page’s own script, and the page carries no analytics.

Is this host in the file?

Paste a known_hosts above, then name a host. The check builds the name the way ssh does — lowercase, and [name]:port for any port other than 22 — and tests every line: hashed entries with HMAC-SHA1 under the salt from the line, plain ones by name and by pattern. It answers the question ssh-keygen -F host answers.

Checking a fingerprint the right way

A fingerprint proves something only if it reached you by a channel you already trust. Read the server’s key where only its owner can — the provider’s web console, or a session you verified earlier — with ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub, and compare it with what your client shows on the first connection. A fingerprint fetched over the same connection you are checking proves nothing: whoever can intercept it can show you any fingerprint you expect.

Two different strings for one key are not a contradiction. OpenSSH printed MD5 in hex until version 6.8 (March 2015) and SHA256 in base64 since; ssh-keygen -E md5 -lf still gives the old form, and some panels and older clients show only that. Both are hashes of the same bytes, which is why this page shows both.

Hashed known_hosts, explained

With HashKnownHosts yes — Debian and Ubuntu ship it in /etc/ssh/ssh_config — ssh writes |1|salt|hash instead of the host name: a random 20-byte salt and an HMAC-SHA1 of the name keyed with it, both in base64. Reading the file tells nobody where you connect. It tells you nothing either, which is what the check above is for.

The port is part of the name. A server on port 2222 is stored as [git.example.org]:2222, so an entry for the plain name does not cover it, and an entry written as [10.0.0.5]:22 is never used, because ssh looks port 22 up without brackets. ssh-keygen -H hashes an existing file and keeps the original as known_hosts.old; lines with a wildcard or a marker stay as they are.

Why some keys are missing from the ssh-keygen block

The list shows every key this page can read, but the block copies ssh-keygen -lf exactly, and ssh-keygen skips some lines that ssh itself uses: a known_hosts line that starts with @cert-authority or @revoked, a line with two spaces between the host names or options and the key type, DSA keys (OpenSSH 10.0 removed DSA), and SSH2 blocks in the RFC 4716 format, which need ssh-keygen -i first. Each such key is marked in the list with the reason.

The comment has a quirk worth knowing too. When a key has no comment of its own, ssh-keygen prints whatever came before it on the line — the host names from known_hosts, or the options from authorized_keys. That is ssh-keygen’s behaviour, and the block matches it.

How it was tested

Against ssh-keygen from OpenSSH 10.2p1, on 24 September 2026: 50 key files — RSA from 1024 to 4096 bits, ECDSA on all three curves, Ed25519, security-key (FIDO) keys, user and host certificates — plus an authorized_keys file with options and quirks, and a 68-line known_hosts, plain and hashed. The SHA256 block, the MD5 block and the randomart were compared with ssh-keygen -lf, -E md5 -lf and -lv, and every host lookup with ssh-keygen -F. All of it matched.

Questions people actually ask

Is my key sent anywhere?

No. The file is read in this tab: the script on this page has no fetch, no XMLHttpRequest and no form submission in it, and the page carries no analytics. SHA-256 and HMAC-SHA1 come from the browser’s own WebCrypto; MD5, which WebCrypto does not offer, is computed by the page’s own script. Open the network tab and paste a file: nothing leaves.

What is the difference between the SHA256 and the MD5 fingerprint?

Only the hash and the way it is written. Both are computed over the same key bytes. OpenSSH switched from MD5 in hex to SHA256 in base64 in version 6.8, in March 2015; ssh-keygen -E md5 -lf still prints the old form for the panels and older clients that show only that.

How do I get the fingerprint of my server’s host key?

On the server itself, or through the hosting provider’s console: ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub, and the same for the rsa and ecdsa files if the server has them. From outside, ssh-keyscan host | ssh-keygen -lf - shows what the server presents — but that travels over the network you are trying to check, so on its own it proves nothing.

Can the host names in a hashed known_hosts be recovered?

Not from the file alone. Each name is an HMAC-SHA1 under its own random salt, so there is nothing to reverse; the only way in is to guess a name and test it, which is exactly what the check on this page and ssh-keygen -F do. It also means a short list of likely names is tested in moments: hashing hides names, it does not make them unguessable.

Does an SSH certificate have its own fingerprint?

ssh-keygen prints the fingerprint of the key inside the certificate, so a certificate and the key it was issued for show the same one. This page does the same, and also lists the certificate’s key ID, serial, principals, validity and the fingerprint of the authority that signed it.

What happens if I paste a private key by mistake?

It is not processed. The text is checked for private-key markers before anything is parsed: the field is emptied at once and a warning appears. The field and the results are also cleared when you leave the page.

Where this comes from

Conchshell shows a new server’s key the same way: a SHA256 fingerprint, in the string ssh-keygen -lf prints, inside a dialog drawn by the operating system rather than by the application. On a first install, when its own trust store does not exist yet, it reads your ~/.ssh/known_hosts once and pins what it can, so servers your own ssh has already verified do not ask again. Hashed entries cannot be pinned — the names are not in the file — so those hosts get the first-use dialog once. On Windows and Linux, answer that dialog with one of its buttons: in version 2.16.0, closing it counts as trust.

Worth knowing before you decide: it signs in with a password, keyboard-interactive, or a private key file, with or without a passphrase, PuTTY .ppk included. It does not talk to ssh-agent, and it cannot use security-key (sk-) keys.

Download Conchshell free

Read next