SSH Key Rotation: Replace an Old Key Without Locking Yourself Out

Security

Old SSH keys pile up: on laptops you no longer own, in CI systems, on servers of people who left. Rotating means adding a new key, testing it, then removing the old one everywhere. Done in this order, you never lose access.

Full guide: Full SSH keys guide

1. Create the new key

Use a new file name so the old key keeps working for now.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_2026 -C "you@example.com 2026"

2. Add it to each server

ssh-copy-id -i ~/.ssh/id_ed25519_2026.pub user@server

3. Test the new key alone

IdentitiesOnly makes SSH use only that key. It must log in without a password.

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_2026 user@server

4. Find and remove the old key on the server

Compare fingerprints, then delete the old key's line from authorized_keys.

ssh-keygen -lf ~/.ssh/id_ed25519.pub         # old key fingerprint
ssh-keygen -lf ~/.ssh/authorized_keys        # run on the server
nano ~/.ssh/authorized_keys                  # delete the old line

5. Update everything else

Git hosts (GitHub, GitLab), CI secrets, backup jobs and ~/.ssh/config IdentityFile lines that pointed at the old key.

grep -R IdentityFile ~/.ssh/config

6. Verify

The old key must now be refused.

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@server   # should fail

7. Troubleshooting

Locked out: use the provider's web console to fix authorized_keys. Permission denied with the new key: check ~/.ssh is 700 and authorized_keys is 600, and that you edited the right user's file.

FAQ

How often should I rotate SSH keys?

At least yearly, and right away when a device is lost or someone with access leaves.

Should I delete the old private key?

Yes, once nothing uses it. Delete ~/.ssh/id_ed25519 and its .pub after rotation is complete.

Further reading: ssh-keygen manual