authorized_keys Analyzer: See Who Can Actually Log In

1. On the server, print the file: cat ~/.ssh/authorized_keys. Check the other accounts too, including root, since each has its own.
2. Paste it above. The review runs as you type, in your browser, and nothing is uploaded.
3. Open the Access list tab. Every fingerprint there matches ssh-keygen -lf ~/.ssh/authorized_keys, so you can copy one and ask your team whose it is.
4. Delete every key you cannot attribute to a person or a system that still exists. That is the whole job, and it is the step people skip.
5. Use the Reviewed file tab to add restrict and from= to what remains, edit the placeholder addresses, then back up the original and replace it.

An authorized_keys file is an access control list, but it does not look like one. It has no owner column, no expiry column and no audit trail. It is a list of base64 blobs, and it only ever grows.

Keys accumulate the way permissions always accumulate: a contractor in 2023, a CI runner that was decommissioned, a laptop that was replaced, a colleague who left. None of those events removed a key, because removing a key is a separate task that nobody was assigned. Meanwhile the file grants permanent, password-less, unlogged-by-default access.

MITRE tracks the offensive side of this as T1098.004, Account Manipulation: SSH Authorized Keys. Appending one line to this file is among the first things an automated attack does after compromising a Unix host, precisely because the file is rarely read and changes to it are rarely alerted on. A key with no comment is indistinguishable from one your colleague added last year.

A line in this file can carry options before the key type, and they decide what the key is actually allowed to do. Compare these two lines, which look almost identical:

ssh-ed25519 AAAA... backup is a full interactive shell, with port forwarding and agent forwarding, usable from any address on the internet, forever.

restrict,from="10.0.0.5",expiry-time="20271231",command="/usr/local/bin/backup" ssh-ed25519 AAAA... backup can run one command, from one address, until one date.

Same key, same access in principle, completely different blast radius if the private half leaks. Every other authorized_keys parser on the web stops at the key type, the size and the fingerprint. This one reads the options, because that is where the security is.

One trap worth knowing: command= on its own is not a sandbox. The holder can still request a pty and still open port forwards to reach anything the server can reach. It needs restrict alongside it.

The SHA256: value in the access list is the same one ssh-keygen -lf prints, byte for byte. That matters because it is the only practical way to resolve an unattributed key.

You cannot tell who a key belongs to by looking at it. You can post its fingerprint in a channel and ask people to run ssh-keygen -lf ~/.ssh/id_ed25519.pub and check. Whoever matches it owns it. Whoever does not answer, you delete.

The legacy MD5: form is shown too, because some consoles, AWS included, still display imported key fingerprints in that format.

This tool reads one file, and it is honest about that. It cannot tell you whether the person behind a key still works for you, which is the actual question. It cannot check the permissions on ~/.ssh/authorized_keys, find the files belonging to other accounts, or know whether a private key has leaked.

Those need the running server. The SSH and Access fix guide covers the server-side checks, and the SSH and Access checklist lists all eleven as commands you can paste into a terminal. CtrlOps scans a whole fleet for who can log in where and offboards someone from every server at once, which is the part that does not fit in a text file.

Reviewing how the server authenticates rather than who it lets in? The sshd_config Analyzer is the other half. Need to issue a replacement key? The SSH Key Generator makes one in the browser.