Developer SSH Offboarding Checklist

Why SSH offboarding is easy to miss

HR and app access get process. SSH keys on individual servers often do not — especially when keys were added manually over years, under multiple Linux accounts, or during rushed departures.

Before the developer leaves

Confirm which servers the developer can access
Confirm which Linux accounts they use (deploy, personal, shared)
List active temporary access windows tied to them
Identify deploy keys and automation they own or created

On final day

Revoke application and VPN access per your normal process
Remove or disable personal server accounts where appropriate
Remove their public keys from authorized_keys on each server
Review shared accounts for their keys
Rotate shared credentials where they had knowledge

After departure

Review deploy keys and CI/CD keys they may have added
Confirm no temporary access windows remain active
Spot-check authorized_keys with fingerprints if comments are unclear
Document the access removal in your audit notes

Server accounts to review

Personal Unix accounts, deploy / ubuntu / ec2-user shared login users, root if keys were ever added there, and any break-glass or emergency accounts.

authorized_keys files to inspect

sudo find /home /root -path '*/.ssh/authorized_keys' -type f -exec grep -l 'COMMENT_OR_EMAIL' {} \;

Replace COMMENT_OR_EMAIL with a known comment or email fragment from their keys.

Deploy keys and CI/CD keys

Check Git hosting deploy keys, build pipelines, and configuration management repos. SSH access for automation is still SSH access.

How to reduce next-time cleanup

Centralise permissions so offboarding is revoking access in one place rather than hunting every file. Pair that with time-bound grants for contractors and incident access so keys expire by default.

Developer SSH offboarding checklist