ecdsa.com

SSH Key Inspector

Paste one authorized_keys line or a whole file. Each entry is decoded locally: key type, curve or modulus size, comment, forced options, and the SHA-256 and MD5 fingerprints exactly as ssh-keygen prints them — plus a plain-English note on how healthy the key type still is.

100% local — everything runs in your browser, nothing is sent to any server

How it works

The authorized_keys line

Every entry in ~/.ssh/authorized_keys (and every .pub file) is a single line with the same shape: [options] key-type base64-body [comment]. The comment is free text — it is whatever ssh-keygen -C was given, often an email or hostname, and it carries no meaning for authentication. The optional leading field restricts what the key may do once it authenticates: no-port-forwarding, from="10.0.0.0/8", command="…" and friends. Options are worth reading carefully: a key with none is a full interactive login.

Inside the base64

The base64 body decodes to the SSH wire format from RFC 4253: a run of length-prefixed fields, each a 4-byte big-endian length followed by that many bytes. The first field repeats the key type, which is why the type appears twice on the line — the prefix is a convenience, the copy inside the blob is the one OpenSSH trusts. What follows depends on the algorithm: 32 raw bytes for Ed25519, a curve name plus an uncompressed SEC1 point for ECDSA, the exponent and modulus for RSA. The RSA key size shown here is the bit length of that modulus, ignoring the leading zero byte the wire format adds to keep the integer positive.

Fingerprints, and why you compare them

A fingerprint is just a hash of the key blob, short enough to read aloud or paste into a ticket. The modern form is SHA256: followed by the base64 of SHA-256 over the blob with the = padding stripped; the legacy form is the MD5 of the same bytes as colon-separated hex pairs, still printed by old servers and by ssh-keygen -E md5. Both are computed here in your browser and match ssh-keygen -lf character for character. Comparing them is the practical point: it is how you check that the key a server is about to trust is the key you meant to send, and how you find a specific entry among a hundred lines of authorized_keys. MD5 is for recognising a key against an old system's output, not for deciding whether to trust one — MD5 collisions are cheap, so use the SHA-256 form whenever both sides support it.

Nothing leaves the page

Parsing and both hash functions run in JavaScript in your browser; no key text is uploaded anywhere. Public keys are not secret, but authorized_keys files describe who can reach which host, which is not something to paste into a random server. (Private keys — anything starting with -----BEGIN OPENSSH PRIVATE KEY----- — are a different matter and have no business in this box, or in any other.)