Find SSH Key Owners Before the Next Leaver

An authorized_keys file containing several old public keys can be difficult to interpret. A comment may name a laptop that no longer exists, a former supplier or simply admin. Removing an uncertain entry risks breaking a backup job; keeping every uncertain entry leaves access nobody can explain.

Build the ownership record before the next employee or supplier leaves. Start with the servers that protect customer data, backups and deployment systems, then extend the review to the remaining estate.

Inventory the effective source of trust

Do not assume that every server reads a single file in a user's home directory. OpenSSH can use configured key files, an external authorised-key command or trusted certificate authorities. The active sshd_config settings determine which mechanisms apply.

Inspect the effective configuration and the relevant account population. Include service accounts, administrative accounts and keys delivered by configuration management. If a management system recreates a removed key on its next run, editing the server alone will not complete offboarding.

Record a fingerprint rather than copying private material. For a public key file, this read-only command displays its fingerprint:

ssh-keygen -lf /path/to/operator-key.pub

The ssh-keygen manual documents fingerprints and certificate inspection. Keep the register restricted because it describes access routes, but never collect users' private keys to establish ownership.

For each fingerprint, record the person or service, business owner, target accounts, servers, purpose, approval date and review date. Include the configuration source that installs it. Treat the comment as a hint to investigate, not as proof of identity.

Separate people from automation

A deployment job and a human administrator need different operating arrangements. Give each automated process a distinct key and a named owner who can explain its required actions. A shared private key makes one person's departure difficult to handle without disrupting everyone else using it.

For a narrowly defined job, consider supported authorised-key restrictions and a forced command. OpenSSH's sshd manual describes restrictions on forwarding, terminals and commands. Test the complete restriction set; a forced command alone does not automatically remove every forwarding capability.

Document the job's replacement process. Who creates the replacement credential, where is it stored, which servers receive the public key and how is the old key withdrawn? A successful run with the new key should be observed before a planned retirement of the old one.

For people, keep a route for lost-device recovery that does not depend on sharing a colleague's key. Decide how approval works outside normal hours, and make temporary access expire or enter an explicit removal queue.

Resolve unknown keys deliberately

Compare fingerprints with authentication logs, approved access requests and the configuration repository. Ask the responsible service owner to identify unexplained entries. Recent use can help establish a dependency, but absence from a short log window does not prove a key is redundant.

For a planned cleanup, choose a maintenance period and preserve the relevant configuration. Confirm a separate authorised access route before making the change. Remove a key from its authoritative management source and then from the deployed configuration through the normal process.

Where ownership remains unclear, record the unresolved risk and a deadline to resolve it. Avoid a permanent exception named “possibly needed”. If the key belongs to a critical unattended process, arrange a controlled replacement rather than waiting for a failure to reveal the dependency.

Verify offboarding across all access layers

At departure, identify every key and certificate identity associated with the person, including supplier-managed accounts. Remove future authentication rights from all relevant sources. For certificate-based access, use the organisation's documented certificate expiry and revocation process; removing an unrelated public-key entry will not revoke trust in a certificate authority.

Check active sessions and other credentials separately. Changing the list accepted for a new SSH authentication does not establish that an already active administrator has lost every route to the system. Follow the incident procedure if access may be compromised, including reviewing changes made while the account was usable.

Validate with a controlled authentication attempt from the retired credential where authorised, or with equivalent configuration and log evidence if the credential is unavailable. Confirm that replacement automation and remaining administrators still work.

Keep the completion record small: identities removed, systems checked, time, operator and any remaining exception. Review it against the next configuration deployment so an old key cannot silently return from a forgotten template.

References

• OpenSSH, sshd_config manual. Accessed 17 October 2026.
• OpenSSH, ssh-keygen manual. Accessed 17 October 2026.
• OpenSSH, sshd manual and authorised-key options. Accessed 17 October 2026.