Problem statement
What is the most common reason a CentOS server becomes unreachable right after disabling SSH password login?
In most cases, the server is not truly rejecting SSH entirely. It is rejecting the only remaining authentication method because the target account does not have a usable public key path. That can mean authorized_keys is missing, the key was added for the wrong user, file ownership or permissions are wrong, or the client is trying a different identity than expected.
The operational fix is to treat password disablement as the final step, not the first one. Keep an existing session open, verify a fresh key-based login from another terminal, then disable PasswordAuthentication only after that test passes.
A controlled helper script reduces this risk by checking authorized_keys first, validating sshd_config with sshd -t, and reloading only after the configuration is known-good. That does not remove every possible key mismatch, but it eliminates the most common self-inflicted lockout pattern.
What to check
- Verify which account owns the usable authorized_keys file.
- Check .ssh directory and authorized_keys permissions.
- Test a fresh key-based login before closing the old session.
- Use TARGET_USER when the key belongs to a non-root account.
Parent topic
Keep legacy CentOS 7 hosts installable and maintainable when yum repositories fail, mirrors expire, or Docker data needs to be moved off a crowded disk.