Switching to SSH Keys Without Locking Yourself Out

Moving an SSH server to key-based authentication can improve account security, but changing the server before testing the key creates an avoidable lockout risk. Keep the current session open and make the transition in stages.

Prepare the key and account

Create a key on the client machine using a supported cryptographic type and protect its private half with a passphrase where appropriate. Install only the public key in the intended account's ~/.ssh/authorized_keys. Check ownership and permissions against the distribution's SSH guidance; overly permissive files can cause the server to reject a key.

Do not email or paste the private key into a ticket. If a key has been exposed, treat it as compromised and replace it.

Test before changing authentication policy

Open a second terminal and connect using the new key while the original session remains available. Confirm that you reached the intended host, account and privilege level. Test any jump host or automation path that depends on the old method.

Inspect the effective SSH configuration and validate syntax with the server's supported configuration-test command before reloading the daemon. Keep a provider console or another recovery route available. The exact setting names and service unit can differ by distribution and OpenSSH version.

Reduce fallback access deliberately

Only after testing, decide whether password authentication should be disabled or restricted. Confirm that another authorized administrator can still connect. Reload rather than abruptly killing the service, then establish a fresh connection from a separate client.

Record where authorized keys are managed and how staff access is revoked. A key migration is complete when access works for the right people and can be removed for the wrong ones, not merely when one command succeeds.