How to audit authorized_keys files

Why authorized_keys audits matter

authorized_keys is the local allowlist for public-key SSH login. Over time it drifts away from reality: old keys stay, duplicates appear, and nobody can explain every line. Regular audits reduce forgotten access and make offboarding less fragile.

Where authorized_keys files live

Typically ~/.ssh/authorized_keys for each user account that accepts key-based login — including root and service accounts. On multi-user servers you may have many files.

sudo find / -path '*/.ssh/authorized_keys' -type f 2>/dev/null

What each line contains

Each non-comment line is usually: optional options, key type, base64 key material, and an optional comment. Options can restrict what the key is allowed to do.

What to look for

Duplicates

The same key repeated wastes space and hints at manual edits without review.

Weak or legacy key types

DSA and short RSA keys should be flagged for rotation or removal.

awk '{print $1}' ~/.ssh/authorized_keys | sort | uniq -c

Unknown comments

Comments like laptop-2019 or temp without an owner are review candidates.

Risky options

Review command=, unrestricted agent forwarding, or keys with no options where you expect restrictions.

Keys for former users or old machines

Cross-check against your team list, asset inventory, and recent offboarding.

How to document findings

Record line number, comment, fingerprint, decision (keep / remove / investigate), and owner. A spreadsheet or ticket per server is enough for small teams.

How often to review access

Quarterly for production servers is a reasonable starting point. Review after incidents, contractor projects, and any offboarding. Ad-hoc audits before compliance reviews catch drift early.

Our authorized_keys Analyzer can speed up a first pass in the browser if you want a quick hygiene check.

Related: stale SSH keys · agency client server access