| Field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} | |
| No data | ||
| Fingerprint | Expected | Actual | Result |
|---|---|---|---|
| {{ row.label }} | {{ row.expected }} | {{ row.actual }} | {{ row.result }} |
| Purpose | Command |
|---|---|
| {{ row.label }} | {{ row.command }} |
{{ row.value }}
SSH key fingerprints are short hashes of an SSH public key. They are used when you want to confirm that the key in front of you is the same key a server, service, ticket, or inventory record is supposed to have. That matters most during first-time host verification, after a host key rotation, and whenever you need to compare keys that are shown in different text formats.
This checker accepts one public key at a time and works with the formats administrators see most often: a standard OpenSSH public key line, a known_hosts entry, an authorized_keys-style line with options before the key type, an RFC 4716 SSH2 public-key block, a PEM public key block, or a DER public key file loaded from disk. It calculates the canonical OpenSSH-style SHA256 fingerprint, the familiar colon-separated MD5 digest, and an optional SHA-1 digest for older workflows.
If you already have a reference fingerprint, you can paste that too. The checker understands normal prefixed values such as SHA256:... and MD5:aa:bb:..., raw digest text, and full ssh-keygen output lines. A match means the supplied reference and the pasted key normalize to the same public-key bytes. A mismatch means you should stop and confirm the expected fingerprint through a separate trusted source before accepting the key.
The result is broader than one digest string. You also get the detected input source, key family, bit length or curve, a normalized OpenSSH public key line, a ready-to-copy known_hosts line, suggested terminal commands, and SSHFP DNS records, which publish SSH host key fingerprints in DNS, when the hostname and key family make that possible. That makes the page useful for both quick side-by-side checks and the follow-up work of documenting or publishing a verified key.
Only public-key material belongs here. Private keys are rejected, X.509 certificates are rejected, and when several key-like items are pasted together the checker processes only the first one and ignores the rest. Public keys are not secret in the way private keys are, but hostnames, comments, and internal naming can still be sensitive, so it is worth treating the surrounding context with care.
The important identity here is the SSH public-key blob. In a normal OpenSSH line that blob is already present as Base64 after the key type. In a known_hosts entry it appears after the host field and any marker, and in an authorized_keys entry it appears after any leading key options. SSH2, PEM, and DER inputs first need to be unwrapped, but once the checker has the canonical public-key bytes it hashes those bytes directly. Comments, line wrapping, and outer text containers do not change the fingerprint if the underlying key bytes stay the same.
| Input form | What the checker reads | What stays identity-stable | Notes |
|---|---|---|---|
OpenSSH, known_hosts, or authorized_keys text |
Key type token, Base64 key blob, optional host field, optional trailing comment | The decoded public-key blob | Host markers and leading options affect context, not the fingerprint itself. |
| RFC 4716 SSH2 public-key block | Block markers, optional quoted Comment: header, Base64 body |
The same SSH public-key blob after unwrapping | Useful when a network device or older SSH tool exports wrapped public-key text. |
| PEM public key | PUBLIC KEY or RSA PUBLIC KEY public material |
A normalized SSH public-key blob rebuilt from the public key | Generic PEM support covers RSA, ECDSA on the named NIST curves, and Ed25519 public keys. |
| DER public key file | Binary SubjectPublicKeyInfo loaded from disk | The rebuilt SSH public-key blob | Binary DER loading is for public keys, not certificates or private keys. |
The supported SSH families reflect what the parser can decode from real key material. RSA fingerprints are derived from the modulus and the page warns when the modulus is shorter than 2048 bits. DSA keys still produce a fingerprint, but the checker flags them as deprecated because many current OpenSSH builds disable them. ECDSA support is limited to the named curves nistp256, nistp384, and nistp521. Ed25519 public keys are supported, and the tool also recognizes OpenSSH security-key variants such as sk-ssh-ed25519@openssh.com and sk-ecdsa-sha2-nistp256@openssh.com when they already appear in SSH-native text.
| Family | How it is reported | What the checker can warn about | Verification consequence |
|---|---|---|---|
| RSA | Key type plus modulus-derived bit length | Warns below 2048 bits | Fingerprint comparison still works, but a short key deserves extra scrutiny. |
| DSA | ssh-dss |
Warns that DSA is deprecated | A digest match confirms identity, not current deployment suitability. |
| ECDSA | Key type plus curve and expected curve size | Unsupported curves are rejected on the PEM path | SSHFP export is available when a real hostname is present. |
| Ed25519 | Key type with 256-bit size | Warns if the public key length is unexpected | Usually the clearest day-to-day host-key comparison target. |
| Security-key variants | SK-ECDSA or SK-ED25519 |
Checked for internal structure | Fingerprint comparison works, but the current SSHFP export set does not emit rows for these types. |
| OpenSSH certificates | Certificate-style key type token | Warns that the fingerprint belongs to the certificate blob | A certificate fingerprint is not the same thing as the underlying raw host key. |
The reference matcher is deliberately flexible because administrators copy digests in different forms. A prefixed SHA256, SHA1, or MD5 value works. Raw SHA256 hex, raw SHA1 hex, plain MD5 hex, colon-separated MD5, and unpadded Base64 digests also work. A full ssh-keygen output line works too because the checker extracts the digest from the surrounding text. If several candidate digests are found in the reference field, the page compares all of them and shows a match as soon as one normalized candidate equals the computed fingerprint.
Processing stays in your browser. Local file reads are handled with browser file APIs, SHA256 and SHA-1 use the browser crypto interface, and the page assembles the comparison ledger, terminal commands, and export payloads without a server round trip. The main privacy caveat is elsewhere: current form values are mirrored into the page URL for shareable state, so host labels, comments, and pasted public-key text can end up in browser history, copied links, or screenshots unless you clear them afterward.
Most people use SSH fingerprints in one of four situations: verifying a host during the first connection, checking whether a stored key has changed, comparing a key file against a published fingerprint, or preparing a key for DNS publication through SSHFP records. The page is strongest when you already have one public key and need a clear answer about whether it matches something trusted.
| Task | What to paste | What to look at first | Best next step |
|---|---|---|---|
| Verify a host before accepting it | The host public key or a known_hosts line, plus a published fingerprint if you have one |
Reference matched and the canonical SHA256 line |
Save or compare the generated known_hosts entry only after the match is confirmed. |
| Check an inventory record | A .pub, .pem, .txt, or DER public key file |
Input source, key type, bits or curve, and SHA256 | Use the CSV, DOCX, or JSON export if you need a clean evidence package. |
| Investigate an unexpected host-key change | The old stored key and the new advertised fingerprint or key | Mismatch status and any type or size warning | Pause and verify through a separate channel before replacing a trusted entry. |
| Prepare SSHFP records | The host public key plus a concrete hostname | The verification artifacts panel | Prefer the SHA-256 SSHFP row and publish it only in a zone validated with Domain Name System Security Extensions (DNSSEC). |
The Advanced section matters when the surrounding context is incomplete. Add a host label when the key came from PEM, from a bare OpenSSH line without a hostname, or from a hashed or wildcarded known_hosts field. Turn on strict parsing when you want the input to be exactly one type base64 [comment] line and you do not want the page guessing at SSH2 or PEM wrappers. Turn on SHA-1 output only when you need it for a legacy comparison or a legacy SSHFP publication path. Uppercase MD5 changes only the display style, not the digest value.
For normal host verification, treat the SHA256 line as the main trust checkpoint. MD5 is mainly there because some panels and old administration notes still use it, and SHA-1 is mostly useful when you are dealing with historical SSHFP data or legacy documentation. The checker helps you bridge those formats, but it should not tempt you into treating every digest type as equally strong or equally current.
ssh-keygen line is fine as long as it contains the digest you want to compare.Reference matched means at least one normalized reference digest equals the computed key digest. Reference mismatch means the key does not match the supplied reference. Reference unclear means the reference text did not parse cleanly as a digest.known_hosts entry, SSHFP rows when possible, and terminal commands that reproduce the same kind of check with ssh-keygen and ssh-keyscan.| Field | What it means | How to use it |
|---|---|---|
| Input source | Which parsing path succeeded | Confirms whether the page read a plain OpenSSH line, a known_hosts entry, a PEM key, or another supported form. |
| Key type, bits, and curve | The family and approximate size of the parsed key | Use it to catch surprises such as a shorter-than-expected RSA key, the wrong curve, or a certificate blob where you expected a raw key. |
| SHA256 (OpenSSH) | The canonical OpenSSH-style fingerprint | This is usually the best line to compare with published host-key fingerprints and modern terminal output. |
| MD5 and optional SHA-1 | Compatibility digests in older display styles | Use them only when another system or document still presents the fingerprint that way. |
| Reference check | The normalized verdict for the expected fingerprint field | A match confirms the same public-key bytes. A mismatch means do not trust the key yet. An unclear result usually means the pasted reference needs cleanup. |
| Detected host field and marker | Host context extracted from a known_hosts style line |
Useful for generating a replacement known_hosts entry and for deciding whether SSHFP export is possible. |
Warnings are meant to slow you down when the fingerprint alone could be misleading. A short RSA key still has a valid digest, but the warning tells you the key is below current expectations. A DSA warning means the key may still identify correctly while remaining unsuitable for many modern SSH deployments. An outer-versus-inner type mismatch means the visible key label and the decoded blob disagree, which is a strong sign that the text was altered or malformed. An OpenSSH certificate warning means the fingerprint belongs to the certificate wrapper, not the underlying host key that might also exist elsewhere.
The SSHFP rows also need interpretation. They are generated only when the page has a concrete hostname and a supported SSH key family for SSHFP export. Hashed known_hosts host fields, wildcard patterns, and certificate inputs do not produce usable SSHFP owner names. Even when the text record looks correct, publishing SSHFP data only improves trust when your DNS answers are protected and validated with DNSSEC. The checker can build the record text, but it cannot prove the DNS publication path is trustworthy on its own.
If a service publishes a host-key fingerprint, paste the host public key or a scanned known_hosts line into the main field and paste the published SHA256 fingerprint into the expected field. A clean result shows Reference matched, the right key family, and a normalized known_hosts line you can compare or save. If the page reports a mismatch, do not accept the key prompt until you confirm the new value through another trusted channel.
Sometimes a teammate sends a generic PUBLIC KEY block instead of an SSH-native line. Paste the PEM block or upload the file, then read the detected family and the SHA256 fingerprint. The checker rebuilds a canonical OpenSSH public key line from the same public key, which is useful when you need to compare what an API exported with what an SSH server or inventory expects.
Paste the host public key, add a concrete hostname such as bastion.example.org, and open the verification artifacts. The page will generate SSHFP rows for SHA-256 and SHA-1 when the key type supports them. In practice you would normally publish the SHA-256 row and keep SHA-1 only when an older environment still expects it. If the original source was a hashed known_hosts line, supply the real hostname manually because the hashed token cannot be turned back into an SSHFP owner name.
Does a matching fingerprint prove the host is trustworthy?
A match proves that the pasted key and the supplied reference describe the same public-key bytes. It does not prove who controls that key or whether the source of the reference was trustworthy.
Why is SHA256 treated as the main value?
Modern OpenSSH displays SHA256 fingerprints by default, and SSHFP records also have a defined SHA-256 fingerprint type. MD5 and SHA-1 remain useful mainly for compatibility with older documentation and older interfaces.
Why are no SSHFP rows shown for some inputs?
You need a concrete hostname and a supported SSH key family. Hashed or wildcarded host patterns, certificate blobs, and key types outside the current SSHFP export map do not produce usable SSHFP rows here.
Can I paste a full known_hosts or authorized_keys line?
Yes. The checker can read both forms when a supported SSH key type is present, but it still processes only the first key-like item it finds.
Does a comment change the fingerprint?
No. Comments help people label keys, but the fingerprint is derived from the public-key bytes, not from the comment text.
Does the page send my key anywhere?
The public-key parsing and hashing stay in the browser, but the current form state is reflected in the URL for shareable state. Clear the page before sharing links or screenshots if the key text, comment, or hostname should not travel with them.
known_hosts entrySHA256:... style used by modern ssh-keygen output.-l, -F, and -r.