SSHCheck — SSH Public Key Validator & Fingerprint Extractor

SSH Key Format Check 100% CLIENT-SIDE

This page splits the line into algorithm, data and comment. To decode the key and get its size and fingerprint use the key inspector.

SSH Public Key (OpenSSH format)

Key Metadata

More from SSHCheck

SSH Public Key Inspector and Fingerprint Decode an OpenSSH public key in your browser: key type, RSA or curve size, the SHA256 fingerprint that… Tool authorized_keys Checker Paste an authorized_keys file and see each line decoded or rejected, weak keys marked, and duplicate keys… Tool

Guides

SSH Key Types and Sizes authorized_keys Format

All tools →All 2 guides →

Frequently Asked Questions

Is my data safe on sshcheck.dev?

Yes. Public keys are parsed in your browser. Nothing is uploaded, and private keys are never required — this tool only reads public key material.

What does a SHA-256 fingerprint tell me?

It identifies a key independently of its comment or length, so you can confirm a key you are being handed is the one you expect. Paste the key into the key inspector page and compare its SHA256: fingerprint with ssh-keygen -lf output; they match.

Should I still generate RSA keys?

Prefer ED25519. It gives equivalent security at a much shorter key length and faster signing. RSA is still widely supported, but below 2048 bits it should be considered inadequate.

🧭 Pro Tips & Gotchas

What it inspects

Splits the key line on whitespace and reports the parts: algorithm name, base64 body length, and the trailing comment — which is enough to catch a truncated paste or a wrapped line.
It does not parse the key material. No fingerprint, no signature verification, so "looks structurally fine" is the ceiling of what it can tell you.

Public-key gotchas

ssh-ed25519, ssh-rsa, ecdsa-sha2-nistp256, sk-ssh-ed25519 are different formats with different field counts. An ssh-ed25519 line has no exponent field, so anything expecting RSA's three-part layout mis-parses it.
RSA keys must be one line. The -----BEGIN----- PEM block is the private format; pasting PEM into authorized_keys yields a key that is silently ignored, and your next login falls back to password.
Line wrapping is the classic corruption source. Terminal-width wrap inserts a newline inside the base64 body; the resulting line still "looks like a key" and the server rejects it without explaining.
authorized_keys needs mode 600 (or 644 at most) and ~/.ssh at 700, owned by the user. Wrong ownership makes sshd skip the file entirely — StrictModes means a group-writable file is a no-op, not a warning.
Legacy ssh-rsa signatures were disabled server-side (OpenSSH 8.8+) because of SHA-1 collision weakness. A key that "stopped working" is usually this, not a key change; regenerate rather than re-enable.
For GitHub/ GitLab: the comment field is a label only — it never grants access, and duplicate keys across repos are how you lose an audit trail. Add Fingerprint verification (ssh-keygen -lf) when pasting a key someone sent you.

Key management defaults

Generate ed25519 (ssh-keygen -t ed25519 -a 100), set a passphrase plus ssh-add/ssh-agent (or a hardware key with -w for a FIDO2 resident key), and configure add_identity_agent no so your agent socket is not forwarded into places you do not control.