SSH Public Key Parser — Inspect type, bits, comment, and fingerprints

What an SSH public key reveals beyond the cryptographic material

SSH public keys cannot be used to reconstruct the private key, but the metadata they carry is richer than it looks. The comment field typically encodes an email address, hostname, creation date, or purpose — not just ‘user@laptop’ but identifiers that map to real accounts and systems. The authorized_keys format extends this with per-key options: command="/usr/local/bin/deploy-prod" names a real script; from="10.0.0.0/8" names an internal network range; permitopen="db.internal:5432" identifies an internal host and port.

Pasting an authorized_keys file into an online tool therefore shares the full access-control design: who can log in, from where, with what restrictions. For organizations using OpenSSH certificates, pasting a cert line exposes the CA principals, validity window, and extension set. The public/private asymmetry holds for the key material itself, but not for the surrounding metadata.

The gap between ‘public key’ and ‘safe to upload’

The label ‘public key’ lowers the perceived risk of pasting into a third-party tool. But the risk is less about the key material and more about the operational intelligence it carries in context. A list of keys with comments like user@company.internal reveals account naming conventions. A key with a deploy-bot comment reveals CI/CD architecture. Weak algorithm flags reveal that certain servers have not been maintained.

Additionally, computing a fingerprint requires the full key string. If an online fingerprint calculator sends the input to a server, the key’s entire body travels with it — even though only the hash was wanted. Doing fingerprint computation locally avoids this mismatch between intent and transmission.

Parsing SSH wire format and computing fingerprints in the browser

This tool implements its own SSH wire format parser in TypeScript. After Base64-decoding the key’s binary section, the parser follows the length-prefixed string and mpint (multi-precision integer) encoding: for RSA it reads the key type, public exponent e, and modulus n; for ECDSA it reads the curve name and the compressed or uncompressed point Q; for Ed25519 it reads the 32-byte public key. No external SSH library is used.

Fingerprints are computed with Web Crypto API: crypto.subtle.digest('SHA-256', keyBytes) for the modern SHA256: fingerprint and crypto.subtle.digest('SHA-1', keyBytes) for the legacy colon-hex format. No network requests are issued. An entire authorized_keys file can be parsed and audited without any data leaving the browser.

Periodic key audits and weak-algorithm detection

SSH key hygiene requires periodically checking that registered keys still meet current strength standards. This tool lets you paste an authorized_keys file and scan for Weak / Legacy chips (RSA < 2048-bit, DSA) in one pass. Keys that show those flags should be regenerated with ssh-keygen -t ed25519. The comment column is equally useful for identifying keys belonging to departed team members that should be removed from authorized_keys.

SSH wire format (RFC 4253 §6.6) and per-algorithm binary layout

An OpenSSH public key line is <algorithm-name> <base64> <optional comment> in text, but the base64 payload follows the RFC 4253 §6.6 SSH wire format. The basic encoded types are: (1) string — a 4-byte big-endian length prefix followed by raw bytes; (2) mpint — a length-prefixed signed big-endian integer with a leading 0x00 inserted when the most significant bit would otherwise indicate negative; (3) name-list — a comma-separated list serialised as a string.

Per-algorithm layouts: RSA (ssh-rsa) is string("ssh-rsa") + mpint(e) + mpint(n) where e is usually 65537 (0x010001) and the bit length is the bit-length of n. ECDSA (ecdsa-sha2-nistp256 and similar) is string("ecdsa-sha2-…") + string("nistp256") + string(Q), where Q is the SEC1 uncompressed point 0x04 || X || Y. Ed25519 (ssh-ed25519) is the simplest: string("ssh-ed25519") + string(32-byte public key). OpenSSH certificates (*-cert-v01@openssh.com) extend this with a nonce, principals list, validity window, critical options, extensions, CA key, and signature appended in order. This parser walks the wire format directly without depending on node-forge or sshpk.

Fingerprint formats, current strength guidance, and post-quantum context

There are two fingerprint formats. The modern one is SHA256:base64 (unpadded), defaulted in OpenSSH 6.8 (2015): take the SHA-256 of the wire-format binary and base64 the digest. The legacy MD5:xx:xx:... colon-hex format pre-dates that; it should not be used for new comparisons. This tool shows both SHA-256 and SHA-1 digests; the SHA-256 output matches ssh-keygen -l -E sha256 -f.

Practical strength guidance: (1) RSA keys should be at least 3072-bit (NIST SP 800-57); new keys should be Ed25519 by default; (2) DSA was disabled in OpenSSH 7.0 (2015) for both generation and acceptance and should be removed from any active authorized_keys; (3) ECDSA on nistp256 is cryptographically fine (~128-bit security) but some projects prefer Ed25519 for not depending on the NIST-chosen curves; (4) FIDO2 hardware keys via sk-ssh-ed25519@openssh.com (OpenSSH 8.2+) require a physical touch and resist remote theft. For post-quantum security, RSA, ECDSA, and Ed25519 all fall to Shor’s algorithm on a sufficient quantum computer; NIST has standardised ML-KEM and ML-DSA, but SSH-side post-quantum profiles are still draft. In the near term, Ed25519 plus periodic rotation is the practical baseline. To inspect related artifacts in the same audit pass, use pem-parse for X.509 certificates and raw RSA / ECDSA PEM files, and use hash-generate when you need to compare the wire-format fingerprint against another digest algorithm (SHA-512, BLAKE2) outside the SSH defaults.