SSH Key Rotation and Revocation Strategies for Production Systems

SSH keys are not meant to live forever.

In real production systems, keys get:

• leaked
• shared accidentally
• forgotten
• compromised

This blog explains how to rotate and revoke SSH keys safely, without breaking access or deployments.

Why SSH key rotation matters

If a private key leaks:

• Anyone can authenticate as that user
• Access persists until the key is removed
• There is no password to reset

Key rotation limits damage.

Mental model: SSH keys are permissions

Think of each SSH key as:

“One permission token with no expiration.”

Your job is to:

• limit its scope
• rotate it periodically
• revoke it instantly when needed

Safe SSH key rotation (zero downtime)

Step 1: Add the new key (do NOT remove old yet)

cat new_key.pub >> ~/.ssh/authorized_keys

Now both keys work.

Step 2: Test with the new key

ssh -i new_key user@server

Confirm access.

Step 3: Update automation (CI/CD)

• Replace private key in GitHub Secrets
• Redeploy once

Step 4: Remove the old key

nano ~/.ssh/authorized_keys

Delete the old line.

Rotation complete.

Emergency revocation (key compromised)

1. Remove the key from authorized_keys
2. Kill active sessions (optional)
3. Rotate any related credentials

pkill -u compromised-user

Best practices

• One key per purpose
• Comment keys clearly
• Rotate CI keys every 3–6 months
• Revoke immediately on suspicion

Final thought

SSH has no reset button.

Rotation is your reset button.