SSH Fingerprint Generator
Compute a real SHA256 fingerprint for SSH public keys.
SSH Fingerprint Generator
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The SSH Fingerprint Generator computes a cryptographic fingerprint of an SSH public key — a short, fixed-length hash that uniquely identifies the key without requiring you to compare the full key material character by character. Fingerprints exist specifically because SSH public keys are long, opaque base64 strings that are impractical to compare visually or read aloud, but a host's identity still needs to be verifiable the very first time you connect to it, before any trust relationship exists.
- This is the exact mechanism behind the 'authenticity of host can't be established, are you sure you want to continue connecting?' prompt every SSH client shows on first connection: the client has received the server's public key but has no prior record of it, so it presents the key's fingerprint and asks you to verify it out-of-band — by comparing it against a fingerprint the server administrator published somewhere you already trust — before adding it to your known_hosts file for future automatic verification.
- Modern SSH implementations default to SHA256 fingerprints, base64-encoded without padding; older tooling and documentation often reference the legacy MD5 format, displayed as colon-separated hex pairs. Both represent the same underlying operation — hashing the public key — but produce visually distinct output, which is a common source of confusion when comparing a fingerprint from one tool against a value published somewhere using the other format.
How It Works
- The SSH public key is decoded from its stored format (typically base64-encoded, prefixed with the key type such as ssh-rsa or ssh-ed25519).
- The tool computes a real SHA-256 digest of the decoded key data via the browser's crypto.subtle.digest — the modern OpenSSH default since version 6.8.
- The resulting hash is base64-encoded (without trailing padding) and prefixed with SHA256:. Legacy MD5 fingerprints aren't offered, since MD5 isn't available via the browser's Web Crypto API — showing a fabricated one would be worse than not showing one.
- The resulting fingerprint uniquely identifies that specific public key — any change to the key, even a single bit, produces a completely different fingerprint.
Usage
- Paste the SSH public key you want to fingerprint into the input field.
- Generate the fingerprint — this tool computes the modern SHA256 format only (see Limitations for why MD5 isn't offered).
- Compare the result against a fingerprint you already trust from an out-of-band source before accepting an unfamiliar host key, or use it to confirm two key copies match.
Examples
- Fingerprinting a newly-provisioned server's host public key and comparing it against the value the hosting provider published in their console, before accepting the connection prompt.
- Fingerprinting your own SSH key pair's public key to publish an official reference value for teammates who need to verify it independently.
- Confirming that a public key stored in your known_hosts file matches the key a server is currently presenting, as a sanity check if a host-key-changed warning appears unexpectedly.
Real-World Use Cases
- Verifying a server's host key fingerprint against a value published by the server administrator through a trusted out-of-band channel, before accepting it on first SSH connection.
- Confirming that two copies of what should be the same public key (e.g. one in your local known_hosts file, one just displayed by a server) are actually identical without comparing the full key strings character by character.
- Publishing a server's or service's official host key fingerprint somewhere trustworthy (internal documentation, a signed announcement) so users have a reliable value to check against on first connection.
Best Practices
- Always verify a new host's fingerprint against a value obtained through a channel independent of the SSH connection itself — a value the server sends you over the same connection you're trying to verify proves nothing.
- Prefer SHA256 fingerprints for anything you publish or compare going forward — it's the current default for a reason: MD5 is a cryptographically broken hash for collision-resistance purposes, even though its use here as a fingerprint (not a security boundary against a targeted forgery) is a lower-stakes application than password hashing.
- If an SSH client ever warns that a host key has changed unexpectedly, treat it as a real signal to investigate before overriding the warning — it can indicate a legitimate key rotation, but it's also the exact warning that would appear during a man-in-the-middle attempt.
- Keep an authoritative, documented record of your own servers' host key fingerprints, generated once at provisioning time, so you have a trusted reference value to check against later rather than trusting whatever the server presents at that moment.
Common Mistakes
- Accepting an unfamiliar host key fingerprint without actually verifying it against an independent source, defeating the entire purpose of the first-connection trust prompt.
- Comparing a SHA256 fingerprint against a documented MD5 value (or vice versa) and concluding they don't match, without realizing the formats are simply different representations that can't be compared directly.
- Assuming an SSH key's fingerprint and its underlying key security are the same property — a fingerprint identifies a key, but the key's own strength (algorithm, length) is a separate consideration entirely.
- Overriding a 'host key has changed' warning out of habit or convenience without investigating why, treating a genuine security prompt as routine friction.
Limitations
- This tool fingerprints a public key you provide; it cannot verify that the key you're fingerprinting actually belongs to the server or person you think it does — that verification requires an independent, trusted source for the comparison value.
- MD5 fingerprints are not offered by this tool — MD5 isn't available via the browser's Web Crypto API, and MD5 is a cryptographically broken hash function for collision-resistance purposes regardless. If you need to cross-reference an MD5 fingerprint from older documentation, a dedicated MD5 tool is required.
- This tool operates on the public key only; it has no access to and performs no operations on the corresponding private key.
Technical Reference Guide
- SSH protocol architecture, including host key verification on first connection, is defined by RFC 4251.
- The SHA256-based fingerprint format (the current default in OpenSSH and most modern clients) and its base64 rendering follow the convention established in OpenSSH's own documentation, building on the general public-key fingerprinting concept rather than a single dedicated IETF RFC.
- SSH public key file formats (the ssh-rsa, ssh-ed25519, and similar prefixed base64 formats this tool parses) are specified by RFC 4253.
FAQ
Why do I need to verify a fingerprint on my very first SSH connection to a server?
Because at that point your client has no prior record of the server's key — the fingerprint prompt is your one opportunity to verify the server's identity out-of-band before trusting it for every future connection. Skipping this check means blindly trusting whatever key is presented.
What's the difference between the SHA256 and MD5 fingerprint formats?
They're two different hash functions applied to the same public key, producing differently-formatted but equally valid fingerprints. SHA256 (base64, prefixed SHA256:) is the modern default; MD5 (colon-separated hex) is the legacy format still referenced in older documentation.
Is MD5 unsafe to use for SSH fingerprints?
MD5 is cryptographically broken for collision-resistance purposes in general, but its use here — identifying a specific key you already have, not defending against a targeted forgery — is a lower-stakes application. Still, prefer SHA256 wherever the value you're comparing against supports it.
What should I do if a server's host key fingerprint suddenly changes?
Investigate before proceeding — it can be a legitimate server rebuild or key rotation, but it's also exactly what would happen during a man-in-the-middle attempt. Verify the new fingerprint through an independent channel before accepting it.
Can two different keys produce the same fingerprint?
In principle any hash function has a theoretical collision possibility, but for SHA256 specifically this is computationally infeasible with current technology — for practical purposes, a fingerprint uniquely identifies its key.
Does fingerprinting a key reveal anything about the corresponding private key?
No — the fingerprint is derived entirely from the public key, which is safe to share. It provides no information about the private key, which should never be shared or entered into any tool.
Part of this Developer Hub
This utility is part of our comprehensive Hashing & Integrity topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Certificate & PKI Lab workshop for complementary engineering workflows.
View all Certificate & PKI Lab tools