b2KIT

Authorized Keys Manager

Parse, validate, and manage SSH authorized_keys file entries with command restrictions and options.

Tested tool guide Tested browser tools Checked August 15, 2026

What Authorized Keys Manager does, with a checked example

Authorized Keys Manager parses one or more lines from an SSH authorized_keys file entirely in the browser, splitting each into its optional comma-separated options block, key type, base64-encoded key data, and trailing comment per the format sshd expects. It flags entries missing a required field, using an unrecognized option keyword, or mixing option syntax with the key data itself. The detail people miss most: the options block only applies to the single line it precedes, so copying a key onto a new line without re-adding its command= restriction removes that restriction from the new line - though whether that actually opens an interactive shell also depends on the account's login shell and server-side controls like sshd_config's ForceCommand or Match directives, which this tool never sees.

Worked example

A concrete input and expected output from the current implementation.

Input

no-agent-forwarding,no-X11-forwarding ssh-rsa

Expected output

Invalid entry: key type 'ssh-rsa' is not followed by base64-encoded key data - the line ends after the key type field.

authorized_keys requires whitespace-separated key type, base64 key data, and an optional comment after any options block; this line stops right after the key type, so no complete key record can be built.

How the result is produced

1

Per-line option/key split

Each line is split at the sshd-defined boundary: an optional leading run of comma-separated option tokens, then whitespace, then the key type (ssh-rsa, ssh-ed25519, ecdsa-sha2-*, sk-ecdsa-*, etc.), the base64 key blob, and an optional trailing comment. Quoted option values like command="..." are parsed with quote-aware splitting so commas embedded inside a command string aren't mistaken for option separators.

2

Option keyword validation

Each option token is checked against sshd's recognized keywords, including command=, from=, environment=, permitopen=, permitlisten=, principals=, restrict, cert-authority, no-touch-required, verify-required, no-pty, no-agent-forwarding, no-port-forwarding, no-user-rc, no-X11-forwarding, expiry-time=, tunnel= - and flagged if unknown, duplicated, or combined redundantly, such as restrict alongside an explicit no-pty that it already implies.

Good uses

  • Auditing a server's authorized_keys file before granting access, to confirm a new entry actually carries the intended forced-command and no-pty restrictions before it's pasted in
  • Debugging why a key meant to be locked to one command still opens an interactive shell, by inspecting exactly which options the line was parsed as having
  • Cleaning up and reformatting deploy-key entries collected from several sources before committing them to a provisioning script or config-management template

Limits and checks

  • This reflects the authorized_keys line format from sshd's own documentation, but whether a key is actually honored also depends on sshd_config settings (AuthorizedKeysFile path, PubkeyAuthentication, PubkeyAcceptedAlgorithms) that this tool never sees
  • Validating syntax is not the same as validating the key pair - a structurally correct base64 blob that doesn't correspond to a key you hold will still fail to authenticate
  • Which options sshd accepts has changed across OpenSSH releases (restrict arrived in 7.2, no-touch-required and verify-required are FIDO-key-specific and newer) - an option flagged as unrecognized here may simply be older or newer than what this tool's option list covers, so check it against your server's actual OpenSSH version

Common questions

Does this confirm the key will actually let a specific user log in?

No. It parses and validates the syntax of the options, key type, base64 data, and comment in a line, entirely client-side. It cannot check ~/.ssh or authorized_keys file permissions and ownership, or the server's sshd_config, all of which also determine whether a key is honored.

Does it flag redundant or conflicting option combinations, not just unknown ones?

Yes. Beyond checking each option against the recognized keyword list, it flags duplicated tokens on the same line and redundant combinations - for example an explicit no-pty alongside restrict, which already implies no-pty along with no-port-forwarding, no-X11-forwarding, no-agent-forwarding, and no-user-rc.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools