Secure Shell (SSH) Key Fingerprint Checker

SHA256: {{ sha256_short }}

{{ display.key_type }} {{ display.bits }} bits {{ display.curve }} {{ display.source_label }} {{ comparisonBadgeLabel }} {{ display.host_badge }}

SHA256 fingerprint:

Copy the canonical OpenSSH value without opening the digest table.

Input issue

Ignored {{ multiLineNote.count }} extra key-like item(s). Only the first detected key is processed.

Public key input:

Paste text here or browse one .pub, .pem, .txt, or .der public key file; hashing stays in-browser.

Expected fingerprint:

Examples: SHA256:..., MD5:aa:bb:..., SHA1:hex, raw Base64, or full ssh-keygen output.

Host label:

Use github.com or server.example.net; hashed known_hosts cannot be converted.

Include SHA-1:

Enable only when a reference list or SSHFP workflow still requires SHA-1.

Uppercase MD5:

Enable when an old panel or note shows uppercase MD5 pairs.

Strict parsing:

Enable for exact type base64 comment input only.

Field	Value	Copy
{{ row.label }}	{{ row.value }}
No fingerprint rows are available Paste a public key or load a supported public key file to build the digest sheet.

Fingerprint	Expected	Actual	Result
Reference verdict	Reference material	{{ comparisonSummaryText }}	{{ comparisonBadgeLabel }}
{{ row.label }}	{{ row.expected }}	{{ row.actual }}	{{ row.result }}
{{ comparisonNoteTitle }}	Verification note	{{ comparisonNoteText }}	Note

Check	Status	Evidence	Next action	Copy
{{ row.check }}	{{ row.status }}	{{ row.evidence }}	{{ row.action }}

Check	Command	When to use	Copy
{{ row.label }}	`{{ row.command }}`	{{ row.hint }}

Artifact	Value	Use / note	Copy
{{ row.label }}	`{{ row.value }}`	{{ row.hint }}
SSHFP note	No SSHFP record generated	{{ sshfpUnavailableReason }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

When an SSH client meets a host key, the visible fingerprint is the short value people can compare before they accept trust. It is much easier to read a digest such as SHA256:... than to compare a long public key line by eye, which is why fingerprints appear in host-key prompts, inventory records, support tickets, cloud consoles, and DNS SSHFP records.

The fingerprint is tied to the public-key bytes, not to the filename, comment, host label, or surrounding wrapper. The same key may appear as an OpenSSH public key line, a known_hosts entry, an authorized_keys-style line with options, an SSH2 public-key block, or a PEM public key. Those formats can look different while representing the same SSH public-key blob.

SSH key fingerprint terms
Term	Plain meaning	Why it matters
Host key	The public key a server presents during SSH connection setup.	Accepting the wrong host key can send you to an impostor server.
SSH public-key blob	The canonical byte sequence inside the public key.	Fingerprints are calculated from these bytes after wrappers are removed.
Fingerprint	A digest of the public-key blob, commonly shown as SHA256 or older MD5 text.	It gives a compact value to compare through another trusted source.
SSHFP	A DNS record that publishes an SSH host-key fingerprint for a hostname.	It can support host-key verification when the DNS answer is authenticated.

SSH public key text normalized to an SSH key blob, hashed, then compared with a trusted source

A digest match answers a narrow question: do these two pieces of evidence refer to the same public-key material? It does not prove that the server is legitimate, that the reference was trustworthy, or that an old key family is still a good operational choice. A stale asset inventory can be just as misleading as a mistyped fingerprint.

Only public keys belong in fingerprint workflows. Private keys should stay out of browser forms, tickets, chat logs, and screenshots. Public-key comments and host labels can still reveal internal hostnames or usernames, so treat copied examples and exported evidence with the same care you would use for infrastructure inventory.

How to Use This Tool:

Check one public key item at a time. Start with the key material, add a trusted reference fingerprint when you have one, and review the warnings before using any generated artifact.

Paste a public key into Public key input, or use Browse file for a public .pub, .pem, .txt, or public-key .der file. The input can be an OpenSSH line, known_hosts entry, authorized_keys-style line with options, SSH2 block, PEM public key, or DER public key.
Use Expected fingerprint when you have a value from a trusted source. The comparison accepts SHA256:..., MD5:aa:bb:..., SHA1:..., raw hex, raw Base64, or a full ssh-keygen output line.
Open Advanced only when the context needs it. Add Host label to build useful known_hosts and SSHFP text, enable Include SHA-1 for legacy checks, toggle Uppercase MD5 for old display conventions, or use Strict parsing to accept only one plain OpenSSH public-key line.
Read the summary first. The copied SHA256 fingerprint, key type, size or curve, source label, host badge, and reference verdict give the fastest safety check.
Use Fingerprint Digest Sheet for exact digest values and the canonical OpenSSH line. Use Reference Match Ledger to see which pasted reference values matched or failed.
Review Trust Review and Key Strength Gauge before accepting or publishing the key. Short RSA keys, DSA keys, certificate blobs, and type mismatches deserve separate confirmation even when a digest matches.
Copy or download tables, JSON, terminal commands, known_hosts text, or SSHFP records only after the host context and fingerprint verdict make sense. When several key-like items are pasted, the checker processes the first one and reports how many extra items it ignored.

Interpreting Results:

The SHA256 fingerprint is the primary modern comparison value. MD5 and optional SHA-1 are compatibility outputs for older panels, notes, inventories, or DNS workflows. Treat a reference verdict as evidence about key identity, not as a full approval to trust the host.

SSH fingerprint verdict meanings
Outcome	What it means	Practical response
Reference matched	At least one supplied fingerprint matches the computed digest after normalization.	Confirm the reference source and host label, then save or publish the matching artifact if the key family is acceptable.
Reference mismatch	The pasted reference was readable, but none of its candidates matched the parsed key.	Stop before accepting the key. Recheck the source, rotation record, hostname, and expected algorithm through another channel.
Reference unclear	The expected value did not look like a supported fingerprint format.	Paste a complete SHA256, MD5, SHA1, raw digest, or `ssh-keygen` line and compare again.
No reference	The key parsed and fingerprints were calculated, but no direct trust check was possible.	Copy the SHA256 value and compare it with an inventory, release note, ticket, DNS SSHFP record, or administrator-provided reference.
Warnings present	The digest may still be correct, but the parsed key raised a format or strength concern.	Read Trust Review before saving records or updating infrastructure.

False confidence is the main risk. A matching MD5 value from an old note may identify the same key while still leaving the host unverified if the note was copied from the wrong server. A Strong gauge result does not prove that the key came from the right host. A clean workflow still needs a trusted source outside the pasted key text.

When the result includes Published Key Artifacts, check whether the host label is concrete and whether the SSHFP rows are appropriate for your DNS setup. Hashed known_hosts names, wildcard host patterns, negated host patterns, and OpenSSH certificate lines cannot produce a normal SSHFP owner name.

Technical Details:

An SSH fingerprint is a message digest over the SSH public-key blob. The visible wrapper is parsed only far enough to recover those bytes and useful context such as the comment or host field.

fingerprint = HASH (SSH public-key blob)

For OpenSSH-style SHA256, the SHA-256 digest is Base64 encoded and shown without trailing padding. The digest sheet also includes SHA256 hex, MD5 colon-separated hex, MD5 plain hex, and optional SHA-1 values. The expected fingerprint comparison normalizes common display forms before comparing them with the computed bytes.

Input Normalization:

Supported SSH public key input handling
Input form	Normalization	Fingerprint basis	Boundary
OpenSSH public key line	Decode the Base64 field after the key type and keep the trailing comment as context.	Decoded SSH public-key blob.	Comments do not change the digest.
`known_hosts` entry	Read the host field and marker when present, then decode the key blob.	Decoded SSH public-key blob.	Hashed, wildcard, or negated host fields are not usable SSHFP names.
`authorized_keys`-style line	Skip leading options until a supported key type is found.	Decoded SSH public-key blob.	Options may affect login policy, but they do not change the key fingerprint.
SSH2 public-key block	Unwrap the block and optional comment header.	Recovered SSH public-key blob.	Incomplete SSH2 blocks are rejected.
PEM public key	Read RSA, ECDSA, or Ed25519 public material and rebuild the SSH blob.	Rebuilt SSH public-key blob.	Private keys and X.509 certificate blocks are rejected.
DER public key file	Load public SubjectPublicKeyInfo bytes as a public key before parsing.	Rebuilt SSH public-key blob.	DER support is for public keys, not certificates or private-key containers.

Strength and Warning Rules:

SSH key strength scoring and warnings
Family	Reported evidence	Warning behavior	Gauge treatment
Ed25519 and security-key Ed25519	256-bit public key, with security-key variants recognized separately.	Unexpected public-key length is warned.	Normally Strong; security-key Ed25519 scores highest.
ECDSA	NIST curve name and expected bit size.	Unsupported PEM curve identifiers are rejected.	Larger supported curves score above smaller supported curves.
RSA	Bit length calculated from the modulus.	RSA below 2048 bits is warned.	2048-bit RSA is usable, while 3072-bit and 4096-bit RSA score better.
DSA	`ssh-dss` key type.	Deprecated DSA use is always warned.	Usually lands in Replace.
OpenSSH certificate	Certificate-style key type token.	The digest is flagged as belonging to the certificate blob.	Not treated as the underlying raw host key.

SSHFP records need both a supported raw host key and a concrete hostname. RSA maps to algorithm 1, DSA to 2, ECDSA to 3, and Ed25519 to 4. Fingerprint type 2 is SHA-256, while fingerprint type 1 is the older SHA-1 form. The record text uses uppercase hex because DNS presentation format stores the fingerprint as hexadecimal text.

The generated terminal checks mirror common OpenSSH workflows: print a local public-key fingerprint, scan a remote host key without writing to known_hosts, inspect saved known_hosts entries, and build SSHFP records from a local public key file. Treat those commands as verification aids, not as proof that a remote host is the one you intended to reach.

Privacy Notes:

Fingerprint calculation, file reading, parsing, comparison, charting, table exports, JSON output, and generated command text run in the browser. The checker does not need to send public-key text to a separate analysis service to calculate the result.

Do not paste private keys. The page blocks common private-key markers, but sensitive key material should never be tested in a general browser form.
Public keys are not passwords, but comments, usernames, hostnames, and ticket-specific labels can still disclose infrastructure details.
SSHFP records are useful only when the DNS publication and validation path is trustworthy. DNSSEC validation is normally the part that turns a DNS answer into a useful trust signal.
OpenSSH certificate fingerprints identify the certificate blob being checked, not the raw key that may be inside the certificate relationship.

Worked Examples:

New host key in an inventory review. Paste ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOspqZOlZGHQu40rWHf4hxuIVAr0mEKqbVuUeiOQE/og demo@example.com and compare it with a trusted SHA256:... value from the deployment record. A successful check shows Reference matched, Key type as ssh-ed25519, Bits as 256, and a Strong result in Key Strength Gauge.

Old RSA value from a control panel. A legacy panel may show only a colon-separated MD5 fingerprint. Paste the RSA public key and put the panel value in Expected fingerprint. If Reference Match Ledger matches MD5 but Key Strength Gauge reports a weak or only usable RSA size, the key identity is confirmed but the rotation decision still belongs in the change record.

Short RSA key caught before publishing DNS. A 1024-bit ssh-rsa host key can still produce valid SHA256 and MD5 digests, but Trust Review warns that RSA is shorter than 2048 bits and Key Strength Gauge falls into Replace. Do not publish the generated SSHFP rows as if the key were acceptable for a new deployment.

Mismatch during a key rotation. A server rotation ticket lists an old SHA256:... value while the pasted known_hosts line contains the new host key. Reference Match Ledger reports Different for the supplied reference, and the summary becomes Fingerprint mismatch. Confirm whether the ticket is stale before replacing local known_hosts entries or DNS SSHFP records.

FAQ:

Should I compare SHA256 or MD5?

Use SHA256 fingerprint for normal SSH checks. MD5 is included for older notes and systems that still display colon-separated MD5 values.

Can a matching fingerprint still be unsafe?

Yes. A match confirms the same public-key bytes, but the reference may be stale, copied from the wrong host, or unauthenticated. Key-strength warnings may also require replacement.

Why did only one pasted key get processed?

The checker handles one public key item at a time. If several key-like lines or blocks are pasted, it processes the first detected item and reports how many extra items were ignored.

Why are no SSHFP records shown?

SSHFP output needs a concrete Host label or detected hostname plus a supported raw host key. Hashed hosts, wildcard patterns, negated host patterns, certificates, and unsupported key families do not produce usable SSHFP rows.

Why did strict parsing reject a valid public key file?

Strict parsing accepts only one plain OpenSSH type base64 [comment] line. Turn it off for known_hosts, SSH2, PEM, DER, or option-prefixed public key text.

Can I paste an OpenSSH certificate line?

Certificate-style key lines can be fingerprinted as certificate blobs, but the result is not the raw host key fingerprint and SSHFP records are not generated for that certificate line.

Glossary:

SSH public-key blob: The SSH-native byte sequence that is hashed to produce the fingerprint.
SHA256 fingerprint: The modern OpenSSH-style Base64 digest commonly shown with the SHA256: prefix.
MD5 fingerprint: An older colon-separated hex digest still found in some legacy SSH notes and panels.
known_hosts: The SSH file that stores hostnames or host patterns with the public keys previously accepted for them.
authorized_keys: The SSH file format that lists public keys allowed to authenticate as a user, sometimes with leading options.
SSH2 public-key block: An RFC 4716-style public-key format with begin and end markers and optional headers such as a comment.
SSHFP: A DNS record type that publishes SSH host-key fingerprints for a hostname.
Strict parsing: A mode that accepts one plain OpenSSH public-key line and turns off format guessing.

References:

RFC 4253: The Secure Shell (SSH) Transport Layer Protocol, RFC Editor, January 2006.
RFC 4255: Using DNS to Securely Publish Secure Shell Key Fingerprints, RFC Editor, January 2006.
RFC 4716: The Secure Shell Public Key File Format, RFC Editor, November 2006.
RFC 6594: ECDSA and SHA-256 Algorithms for SSHFP, IETF, April 2012.
RFC 7479: Using Ed25519 in SSHFP Resource Records, IETF, March 2015.
ssh-keygen(1) manual page, OpenBSD manual pages.