authorized_keys Format: Options, Comments and Why Lines Get Skipped
Each non-blank, non-# line is [options] keytype base64 [comment]. The checker parses every line this way and reports what it finds.
Options
Options come first, comma separated, with no spaces outside double quotes: command="/usr/bin/backup",no-pty ssh-ed25519 AAAA... backup. The checker finds the key type after the options and notes that options are present. Common ones are command=, from=, no-port-forwarding, no-pty and restrict. A stray space between two options turns the second into the key type and the line is skipped.
Why a line is skipped without an error
| Cause | What the checker reports |
|---|---|
| Key wrapped across lines by a terminal or email client | The key is read joined, with a warning that it must be one line |
| Truncated paste | A length field runs past the end of the key data |
| Type word does not match the key data | Names both |
| Smart quotes or stray characters in the base64 | Not valid base64 |
| A private key pasted by mistake | Refused |
Duplicates
The checker compares fingerprints, so the same key under two different comments is flagged. A duplicate is harmless to sshd but makes it harder to see who has access.
Permissions (not checkable here)
With StrictModes yes (the default) sshd ignores authorized_keys if the file, ~/.ssh, or the home directory is writable by anyone but the owner. Typical safe modes are 700 for ~/.ssh and 600 (or 644) for the file, both owned by the user. A browser cannot see your filesystem, so check with ls -ld ~ ~/.ssh ~/.ssh/authorized_keys.