Secure Shell (SSH) Key Fingerprint Checker

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

SHA256

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

SSH host-key trust starts before a password, private key, or command ever reaches the server. The client first needs proof that the remote endpoint is presenting the public host key you expected. A fingerprint gives that proof a compact shape: instead of comparing a long public key line character by character, you compare a short digest shown by OpenSSH, a cloud console, a deployment record, a ticket, or a DNS SSHFP record.

The digest belongs to the SSH public-key blob, which is the canonical byte sequence inside the public key. The visible wrapper can change without changing the fingerprint. A key may be copied as an OpenSSH public key line, appear inside known_hosts, include options in an authorized_keys-style line, arrive as an SSH2 public-key block, or be stored as a PEM or DER public key. Comments, filenames, and host labels help humans keep records straight, but they are not the material being hashed.

SSH fingerprint concepts and trust boundaries
Concept	What it identifies	Common mistake
Host key	The public key a server presents during SSH connection setup.	Accepting a changed host key without checking the rotation record.
Public-key blob	The SSH-native bytes used as the hash input.	Assuming a different comment or filename changes the fingerprint.
SHA256 fingerprint	The modern OpenSSH-style digest most people should compare first.	Treating an old MD5 match as enough evidence by itself.
Trusted reference	An independently obtained value from the server owner, inventory, console, or authenticated DNS path.	Comparing the server prompt with another copy from the same untrusted session.

A fingerprint match answers a narrow but important question: do the pasted public key and the reference fingerprint describe the same key material? It does not prove that the server name is correct, that the reference was collected safely, or that the key family is still a good choice. A stale inventory entry can produce the same kind of false confidence as a mistyped value.

Public keys are safer to handle than private keys, but they can still reveal infrastructure details. Key comments often contain usernames, hostnames, build labels, or ticket names. Private keys should never be pasted into a fingerprint checker, and copied output should be treated like host inventory when it includes real host labels.

How to Use This Tool:

Use the checker for one public key item at a time. Add a trusted reference when you have one, then read the match and warning evidence before saving records.

Paste public key text into Public key input, or choose a public .pub, .pem, .txt, or public-key .der file with Browse file. OpenSSH lines, known_hosts entries, option-prefixed authorized_keys lines, SSH2 public-key blocks, PEM public keys, and DER public keys are supported.
Enter Expected fingerprint when you have a value from another trusted channel. The comparison accepts SHA256:..., MD5:aa:bb:..., SHA1:..., raw hex, raw Base64, and full ssh-keygen output lines that contain a fingerprint.
Use Host label when you want known_hosts text or SSHFP records for a specific host. A detected host from a known_hosts line can be used, but a manual label is clearer when the pasted line contains several host patterns.
Open Advanced only for compatibility cases. Include SHA-1 adds legacy SHA-1 outputs, Uppercase MD5 matches older display conventions, and Strict parsing limits input to one plain OpenSSH type base64 [comment] line.
Read the summary before using the tabs. The SHA256 fingerprint, key type, measured size or curve, source label, host badge, reference verdict, and warnings give the first pass answer.
Use Fingerprint Digest Sheet for exact digest values, Reference Match Ledger for each parsed reference candidate, Trust Review for format and acceptance warnings, and Key Strength Gauge for a quick family and size signal.
Use Terminal Checks and Published Key Artifacts after the verdict makes sense. Copy or download CSV, DOCX, JSON, command text, known_hosts entries, or SSHFP rows only after the host label, reference source, and warning state are acceptable.

Interpreting Results:

The SHA256 fingerprint is the main modern value to compare. MD5 exists for old host-key prompts, control panels, and notes. SHA-1 is a legacy compatibility output for environments that still publish or audit older SSHFP data. A match confirms key identity after normalization; it does not decide whether the reference itself should be trusted.

SSH fingerprint result meanings
Result state	Meaning	Next check
Reference matched	At least one supplied reference fingerprint matched the computed key digest.	Confirm that the reference came from an independent trusted channel and that the host label is correct.
Reference mismatch	The reference looked valid, but none of its candidates matched the parsed key.	Stop before accepting the key. Recheck hostname, rotation timing, key type, and source record.
Reference unclear	The expected value did not parse as a supported fingerprint form.	Paste a complete SHA256, MD5, SHA-1, raw digest, or `ssh-keygen` line and compare again.
No reference	The key was parsed and hashed, but no independent comparison was possible.	Copy the SHA256 value and compare it with inventory, a server console, DNS SSHFP evidence, or an administrator-provided record.
Warnings present	The fingerprint can still be correct while the key format, family, or parsed context needs review.	Use Trust Review and Key Strength Gauge before publishing or accepting the key.

Key strength and key identity are separate judgments. A 1024-bit RSA key can match a reference fingerprint and still deserve replacement. An Ed25519 key can look strong and still be the wrong server if the reference was copied from an attacker-controlled prompt. Treat the fingerprint as one piece of a host-verification workflow, not a replacement for a trusted source.

SSHFP records need a concrete hostname and a supported raw host public key. Hashed known_hosts fields, wildcard patterns, negated patterns, and OpenSSH certificate lines do not produce normal SSHFP owner names. When SSHFP is used for trust, DNSSEC validation is the part that makes the DNS answer meaningful.

Technical Details:

An SSH public key carries an SSH-native binary structure. The first string inside that structure names the key family, followed by family-specific public values such as an RSA exponent and modulus, an ECDSA curve point, or a 32-byte Ed25519 public key. Fingerprints are calculated from the complete public-key blob, not from the display text around it.

OpenSSH-style SHA256 fingerprints use the SHA-256 digest of the key blob, Base64 encoded without trailing padding and shown with the SHA256: prefix. Older MD5 fingerprints are shown as colon-separated hexadecimal byte pairs. SHA-1 appears only when a legacy workflow needs it, most commonly for old SSHFP comparison or records that have not been modernized.

Formula Core:

fingerprint = digest algorithm (SSH public-key blob bytes)

The comparison step normalizes common display forms before matching. A pasted SHA256: value, a 64-character SHA-256 hex string, a colon-separated MD5 value, a plain MD5 hex string, a SHA1: value, or a full ssh-keygen output line can all describe the same digest family in different presentation forms.

Input Normalization:

Supported SSH public key input normalization
Input form	How it is reduced	Important boundary
OpenSSH public key line	Decode the Base64 field after the key type and keep the trailing comment as context.	The comment does not change the digest.
`known_hosts` entry	Read the host field or marker when present, then decode the key blob.	Hashed or patterned host fields are not normal SSHFP owner names.
`authorized_keys`-style line	Skip leading options until a supported key type appears.	Login options may affect authentication policy, but not the public-key fingerprint.
SSH2 public-key block	Unwrap the block and optional comment header to recover the public blob.	Incomplete or malformed blocks are rejected.
PEM or DER public key	Read public key material and rebuild an SSH public-key blob for supported families.	Private keys and certificate containers are not accepted as public host keys.

Strength and Warning Rules:

SSH key family strength and warning behavior
Key family	Evidence used	Warning or scoring behavior
Ed25519 and security-key Ed25519	Expected 256-bit public key material.	Normally lands in the strongest band; unexpected 32-byte length mismatch is warned.
ECDSA	Curve family and expected size such as nistp256, nistp384, or nistp521.	Supported larger curves score higher; unsupported PEM curve identifiers are rejected before fingerprinting.
RSA	Bit length measured from the public modulus.	RSA below 2048 bits is warned. RSA 3072 and 4096 score better for new host-key records.
DSA	The `ssh-dss` key family.	Always warned as deprecated and commonly disabled in modern OpenSSH builds.
OpenSSH certificate line	The certificate blob, not the raw underlying host key.	The fingerprint is shown for the certificate object and SSHFP records are not generated.

SSHFP records use numeric algorithm and fingerprint type codes. RSA is algorithm 1, DSA is 2, ECDSA is 3, and Ed25519 is 4. SHA-1 is fingerprint type 1 and SHA-256 is fingerprint type 2. The record value is uppercase hexadecimal text because DNS presentation format stores the digest that way.

Generated terminal commands mirror common OpenSSH checks: print a local public-key fingerprint, scan a remote host key without writing to known_hosts, look up saved known_hosts entries, and build SSHFP records from a local host public key file. Those commands help reproduce the evidence, but the trust decision still depends on the hostname and reference source.

Privacy Notes:

Fingerprint calculation, public-key parsing, reference comparison, charting, table export, JSON generation, and command text generation run in the browser. The checker does not need to send the pasted public key to a server to calculate its digest.

Do not paste private keys. Common private-key markers are blocked, but sensitive key material should never be tested in a browser form.
Public key comments, usernames, hostnames, and environment labels can disclose infrastructure detail when copied into tickets or exported evidence.
SSHFP is useful only when the DNS publication and validation path is trustworthy. A DNS record copied from an unauthenticated source is just another untrusted reference.
A certificate-style SSH key line can be fingerprinted as its own object, but that result is not the raw host key fingerprint most SSHFP workflows expect.

Worked Examples:

First connection to a new Ed25519 host. The administrator records the host fingerprint from the server console as SHA256:.... Paste the server's public host key and the recorded value. A Reference matched result, ssh-ed25519 key type, 256-bit size, and strong gauge result mean the key material lines up with the reference. The connection prompt can still be accepted only after the hostname and reference channel are correct.

Legacy control panel shows MD5 only. Paste the public key and put the colon-separated MD5 value in Expected fingerprint. A match confirms the same key material, while the digest sheet gives the modern SHA256 form you can store in the new inventory record.

Short RSA key before DNS publication. A 1024-bit ssh-rsa host key can produce valid SHA256, MD5, and SSHFP text. The warning and low strength score show that the key should be replaced before new SSHFP records or long-lived known_hosts entries are published.

Rotation ticket mismatch. A ticket lists the old SHA256 value while the pasted known_hosts line contains the new host key. Reference Match Ledger reports a mismatch. Confirm whether the server was rotated, whether the host label changed, and whether users should update saved host keys before replacing records.

FAQ:

Should I compare SHA256 or MD5?

Use SHA256 for normal SSH host-key checks. MD5 is included for older prompts, panels, and records that have not been converted to modern OpenSSH fingerprint format.

Can a matching fingerprint still be unsafe?

Yes. A match confirms the same public-key bytes, but the reference can be stale, copied from the wrong host, or delivered through an untrusted channel. Key-strength warnings can also require replacement.

Why did strict parsing reject my input?

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

Why are SSHFP records unavailable?

SSHFP output needs a concrete hostname and a supported raw host public key. Hashed host fields, wildcard or negated patterns, unsupported families, and OpenSSH certificate blobs do not produce normal SSHFP rows.

Can I paste several public keys at once?

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

Glossary:

Host key: The public key a server presents so an SSH client can recognize the server on first and later connections.
SSH public-key blob: The canonical SSH byte sequence hashed to produce a fingerprint.
SHA256 fingerprint: The modern OpenSSH-style Base64 digest commonly displayed with the SHA256: prefix.
MD5 fingerprint: An older colon-separated hexadecimal digest still found in legacy SSH records.
known_hosts: The client-side file that records accepted hostnames or host patterns with their public keys.
SSHFP: A DNS record type that publishes SSH host-key fingerprints for a hostname.
Strict parsing: A mode that accepts only one plain OpenSSH public-key line and disables 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 7479: Using Ed25519 in SSHFP Resource Records, IETF, March 2015.
ssh-keygen(1) manual page, OpenBSD manual pages.
How to verify SSH host key fingerprints before connecting, simplified.guide.