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