authorized_keys Analyzer

What is the authorized_keys file?

~/.ssh/authorized_keys is the list of public keys that may log in to one account over SSH: anyone holding the private half of a key on that list gets in, with no password. Each line is one key, written as optional options, the key type, the key in base64 and a comment, as defined under AUTHORIZED_KEYS FILE FORMAT in the sshd(8) man page.

Because adding a line is so easy, the file tends to collect keys nobody can account for: old laptops, people who left, a CI job from two years ago. This analyzer reads it the way sshd does and tells you what each line is.

How sshd reads each line

restrict,command="/usr/local/bin/backup.sh",from="203.0.113.0/24" ssh-ed25519 AAAAC3Nz… backup@nas

• Options come first, separated by commas with no spaces. A value goes in double quotes and may contain spaces and commas. The options end at the first space outside quotes.
• The key type must match the type inside the key: ssh-ed25519, ssh-rsa, ecdsa-sha2-nistp256, sk-ssh-ed25519@openssh.com and so on.
• The key is base64 on the same line. A key wrapped onto two lines is two broken lines.
• The comment is everything after the key. sshd ignores it, so it is the only record of whose key it is.

Blank lines and lines starting with # are skipped. An unknown option, a duplicated command= or an unreadable expiry-time= makes sshd reject the whole line, so that key silently stops working.

What the analyzer checks

Each key also gets its SHA256 fingerprint, the same value ssh-keygen -lf ~/.ssh/authorized_keys prints, so you can match lines against the keys people hold.

A worked example: locking down an automation key

A backup server logs in to run one script. Unrestricted, its key can open a shell, forward ports into your private network and forward an agent. Restricted, it can only run the script, only from the backup server's network:

restrict,from="203.0.113.0/24",command="/usr/local/bin/backup.sh" ssh-ed25519 AAAAC3Nz… backup@nas 2026-10

restrict turns off port, agent and X11 forwarding, the pty and ~/.ssh/rc, including any added in future OpenSSH releases. Add back only what the job needs, for example restrict,pty. The original command the client asked for is in SSH_ORIGINAL_COMMAND, which the script can check.

To match a line to a person, ask them for ssh-keygen -lf ~/.ssh/id_ed25519.pub and compare it with the fingerprint in the table.

Common errors and how to fix them

• A key that should work is refused. Check the line is not wrapped, the options have no spaces outside quotes, and the file is chmod 600 and ~/.ssh is chmod 700, both owned by the user. With StrictModes yes, the default, sshd ignores the file if it, ~/.ssh or the home directory can be written by other users.
• "Permission denied (publickey)" right after editing. The edit broke a line. Keep a session open while you change the file and test from a second terminal.
• A PuTTY key that never works. Lines starting ---- BEGIN SSH2 PUBLIC KEY ---- are the RFC 4716 format; convert with ssh-keygen -i -f key.pub and paste the one-line result.
• Removing someone's access. Delete their line and also check /etc/ssh/sshd_config for an AuthorizedKeysFile that points somewhere else.

Managing keys with Shipown

Shipown's deploy users feature creates non-root accounts on a server, assigns people's public keys to them, sets scoped sudo rules and revokes an account when it is no longer needed, over SSH from your desktop. For the SSH daemon's own settings, use the sshd_config analyzer; for a new key, the SSH key generator.