How do I replace an SSH key without losing access?
Key rotation should overlap the old and new authorised identities long enough to verify the replacement. Generate a new key under a different filename, enrol it, test a new session, and then remove only the retired public-key entry.
Instructions
1. Generate a distinct replacement locally
Do not overwrite the current key file.
ssh-keygen -t ed25519 -f "$env:USERPROFILE\.ssh\server_ed25519_next" -C "server-access-next"Use an interactive passphrase. A distinct filename keeps the current working identity available during verification.
2. Enrol and test the replacement
Use the approved public-key enrolment process for the exact account. Keep the old authenticated session open while you test a separate connection.
ssh -o IdentitiesOnly=yes -i "$env:USERPROFILE\.ssh\server_ed25519_next" adminuser@203.0.113.10A successful fresh login demonstrates that the new private key is accepted. Confirm the remote username.
3. Retire the old key deliberately
Update this server’s client alias, identify the old public entry by fingerprint and remove that entry through the account’s authorised-key management process. Recheck both normal login and any automation that used the old key. Revocation must be repeated wherever the old identity was authorised.
Check the result
- A fresh session authenticates with the new key before old-key removal.
- The new client configuration works and the retired key is rejected for the intended account.
Troubleshooting
- Automation stops after rotation
- Its identity path or managed credential may still point to the old key. Update only that authorised workflow.
- The old key still logs in
- Look for duplicate entries, another authorised-key source or certificate-based access.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.