Why Does SSH Key Authentication Fail After a Server Change?

After a server rebuild or administrator change, an SSH key that worked before may be rejected. The cause can be an incorrect username, missing public key, strict home-directory permissions, a changed SSH configuration, or a host key that no longer matches the client record. A host-key warning deserves particular care: confirm the server's identity through a trusted channel before replacing the saved fingerprint.

Check the client and server sides

On the client, confirm the intended key, username, hostname, and port. On the server, review authentication logs and verify that the account's authorized key file is present and readable only by the owner. Check ownership and permissions on the home directory and .ssh path, plus any restrictions such as allowed users or key algorithms.

• Use verbose client output to see which key is offered and where authentication stops.
• Keep an existing working session open while correcting access.
• Do not disable host-key checking as a general fix.
• Test a second approved administrative account before ending the maintenance window.

Informatix Systems lists Linux server administration. A review can help diagnose SSH policy, account permissions, and secure access recovery. Contact Informatix Systems if authorized server access fails after a change.