Guide

Stale SSH keys: how forgotten server access builds up

A practical guide to finding, reviewing, and removing SSH keys that should no longer be on your servers.

What is a stale SSH key?

A stale SSH key is a public key still present in authorized_keys on a server when the person, machine, or purpose behind it no longer needs access. The key itself may be valid — the problem is that access was never removed.

Why stale keys happen

SSH keys are easy to add. Removing them is slower, less urgent, and often nobody's explicit job. Contractors finish projects. Developers get new laptops. Emergency access is granted during incidents. Temporary fixes become permanent because cleanup depends on memory, tickets, or calendar reminders.

Why they are risky

Each key in authorized_keys is a door. Stale keys widen your attack surface: lost laptops, former staff, old automation, or keys with weak algorithms may still work. A messy file also makes audits harder — you cannot easily answer who can log in, why, or until when.

How to inspect authorized_keys manually

Start by finding files on a server or across your estate:

sudo find /home /root -path '*/.ssh/authorized_keys' -type f -print

Show keys with line numbers for review:

nl -ba ~/.ssh/authorized_keys

Always back up before editing:

cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys.backup.$(date +%F)

What to look for

  • Unknown comments — labels that do not map to a current person or system
  • Old laptop names — keys tied to machines that were replaced
  • Duplicate keys — the same public key repeated on multiple lines
  • Weak algorithms — legacy DSA or short RSA keys
  • Broad options — forced commands, agent forwarding, or missing restrictions where you expect them

How to clean them up safely

Remove keys you can confidently identify as obsolete. For uncertain entries, ask the team, check deploy docs, or disable access in a staging environment before production. Document what you removed and why.

How to stop the problem coming back

One-off cleanups help, but drift returns if new keys are still added by hand without expiry. Policies help: record who, which server, which account, reason, start, and end time for every grant. Tools help more: keep authorized_keys in sync with active permissions so access can expire automatically.

For a quick browser-based review, you can also use our authorized_keys Analyzer — nothing is uploaded.

Related: contractor SSH access · authorized_keys audit

Stop stale keys building up again

GrantSSH keeps authorized_keys in sync with active, time-bound permissions so access expires automatically.