How to Audit and Rotate SSH Keys Across Your Home Lab

Regular SSH key rotation and auditing brings that back under control, ensuring only keys you actually recognize and still need retain access.

ssh

After following this series — setting up key-based SSH authentication, Ansible with its own key, Gitea deploy keys, a reverse SSH tunnel — it’s easy to accumulate SSH keys across your homelab without a clear picture of what’s actually authorized where. Regular SSH key rotation and auditing brings that back under control, ensuring only keys you actually recognize and still need retain access.

Why SSH Keys Accumulate Unnoticed

Every guide in this series involving SSH — Ansible’s control node access, Gitea’s deployment keys, the reverse SSH tunnel to a VPS, key-based authentication itself — potentially adds another entry to some server’s authorized_keys file. Without periodic review, it becomes genuinely difficult to remember which keys are still actively needed versus leftover from an old laptop, a discontinued service, or testing you did months ago and forgot about.

Auditing Existing Authorized Keys

On each server, review what’s currently authorized:

cat ~/.ssh/authorized_keys

For each entry, the trailing comment (if present) typically identifies what generated the key — but many keys lack meaningful comments, making real identification difficult without your own separate records.

Adding Meaningful Comments to New Keys

Going forward, always generate keys with a clear, identifying comment:

ssh-keygen -t ed25519 -C "laptop-yourname-2026"

This small habit change makes future audits considerably easier, since authorized_keys entries retain this comment, letting you immediately recognize which specific device or purpose each key was created for.

Checking Key Usage Across Multiple Servers

If you’re using Ansible (), you can efficiently audit authorized_keys across your entire homelab inventory in one pass:

ansible homelab -i inventory.ini -m shell -a "cat ~/.ssh/authorized_keys"

This surfaces every server’s current key configuration simultaneously, rather than manually checking each machine individually.

Removing Unrecognized or Unused Keys

Once you’ve identified keys that no longer correspond to a device or purpose you recognize, remove them directly from authorized_keys:

nano ~/.ssh/authorized_keys

Delete the specific line corresponding to the key you’re revoking, then save. That key immediately loses access, with no further action required on the client side.

Rotating Keys Periodically

Beyond just removing unrecognized keys, consider periodically generating entirely new key pairs for your primary access methods, even for keys still actively in use — reducing the window of exposure if a key was ever compromised without your knowledge, similar in spirit to periodic password rotation but for key-based authentication instead.

A Practical Rotation Process

  1. Generate a new key pair on your client device.
  2. Add the new public key to relevant servers’ authorized_keys alongside the existing key (not yet removing the old one).
  3. Test that the new key successfully authenticates.
  4. Once confirmed working, remove the old key from authorized_keys.
  5. Securely delete the old private key from your client device.

This overlap period ensures you don’t accidentally lock yourself out mid-rotation before confirming the new key truly works.

Auditing Deploy Keys and Service-Specific Keys

Beyond personal login keys, review service-specific keys separately — Gitea deploy keys , Ansible’s control node key, and any automation scripts using their own dedicated keys. Each of these deserves the same periodic scrutiny as personal access keys, since a forgotten, overly-permissioned deploy key is just as much a potential gap as an old personal key nobody remembers adding.

Using Lynis to Catch Related Issues

The Lynis security audit () includes checks specifically related to SSH configuration and key permissions, catching related issues like overly permissive private key file permissions alongside your manual authorized_keys review.

Setting a Recurring Reminder

Since key accumulation happens gradually and easily goes unnoticed, treat this as a recurring task — quarterly or semi-annually — rather than a one-time cleanup, similar to the recurring cadence recommended for the Lynis audits and log reviews covered elsewhere in this series.

Final Thoughts

Regular SSH key rotation and auditing prevents the slow, easy-to-miss accumulation of forgotten or unrecognized access across a growing homelab, especially after implementing the numerous SSH-dependent tools and services covered throughout this series. A clear, periodic review — helped considerably by meaningful key comments and Ansible-assisted auditing across multiple servers at once — keeps your actual access list matching what you really intend to allow.

Related Posts

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *