What this does
Audits an entire ~/.ssh/authorized_keys file at once — every key on every line, entirely in your browser. For each key it reports the algorithm, bit length, and SHA256 fingerprint (matching ssh-keygen -l exactly), any OpenSSH restriction options attached to it (from=, command=, restrict, and the individual no-* flags), and flags the issues that tend to accumulate in a file nobody has cleaned up in a while: duplicate keys, missing comments, deprecated ssh-dss entries, and RSA keys under the 2048-bit minimum.
Why a file-level audit, not just a key-level one
SSH Key Inspector answers "what is this one key" in depth. This tool answers a different, file-scoped question: across every key an account currently trusts, are any of them duplicated, unidentifiable, or weaker than the rest? Those are exactly the questions that only make sense once a file has accumulated more than one or two entries — the kind of file a shared server, a CI runner, or a long-lived account tends to end up with over time.
FAQ
How is this different from SSH Key Inspector?
SSH Key Inspector examines one public key in depth — full algorithm details, curve information, everything. This tool audits an entire authorized_keys file at once, looking for the operational issues that only show up across multiple keys: duplicates, missing comments, unrestricted entries, and weak or deprecated algorithms — the questions you'd actually ask about a file with a dozen keys in it.
What does "no restrictions" actually mean, and is it always bad?
It means the key line has none of OpenSSH's optional restriction fields — from= (source address), command= (force a specific command), restrict, or the individual no-* flags. It isn't automatically wrong; plenty of legitimate personal keys are unrestricted on purpose. It's worth a second look specifically on service or automation accounts, where a restriction limiting the key to one source IP or one command meaningfully reduces what a stolen key could do.
Why does a missing comment matter?
The comment is the only thing that tells a human which key belongs to whom once a file has more than one or two entries. It carries no cryptographic weight, but its absence makes an authorized_keys file much harder to safely clean up later, since nobody can tell which line is safe to remove.
Does this tool check whether the keys are actually authorized to be there?
No — it can only tell you what's syntactically and cryptographically present in the file, not whether each key belongs to someone who should still have access. That's a judgment call for whoever manages the account, informed by this tool's breakdown of what's actually in the file.
Is it safe to paste a real authorized_keys file into this tool?
Yes — authorized_keys only ever contains public keys, which are meant to be shared freely; nothing in this file is a secret. Processing also happens entirely in your browser, so nothing is sent anywhere regardless.
Try it yourself
For the full picture of how authorized_keys restrictions work and why they matter, see authorized_keys Explained. Need to generate a new key instead? SSH Key Generator produces one formatted exactly as OpenSSH expects.