SSH key authentication gets much easier once it is separated into two questions. Authentication proves control of a key. Authorization determines what the account using that key is allowed to do.
Your device keeps a private key. The server receives only the matching public key. During login, the device proves it controls the private half without sending that private key across the network.
Use one key per device
Do not copy the same private key between every laptop, desktop, VM, and automation process. A separate labeled key for each device makes the access list understandable and makes revocation simple when a device is retired or lost.
ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519_work -C 'owner@device-work'; ssh-keygen -lf ~/.ssh/id_ed25519_work.pubThe private file stays on the device. The .pub file is the part installed on the server. Keep the private key owner-readable and protect it with a passphrase when the device supports that workflow.
Add access before changing server policy
The safe order matters. Add a public key. Test it in a second terminal. Keep the existing working session open. Only then consider changing the server policy.
ssh-copy-id -i ~/.ssh/id_ed25519_work.pub user@host; ssh -i ~/.ssh/id_ed25519_work -o IdentitiesOnly=yes -o BatchMode=yes user@hostThe second command refuses to fall back to an interactive password prompt. If the key does not work, find out while the original session is still available.
Verify the server before trusting it
A changed host-key warning can mean a rebuild, but it can also mean a connection is being intercepted or pointed at the wrong system. Do not dismiss it automatically. Verify the new fingerprint through a separate trusted path before accepting it.
Hardening comes after a tested key login
Once a second key-based login works, a server-specific SSH configuration can disable routine root and password login:
PermitRootLogin no; PasswordAuthentication no; KbdInteractiveAuthentication no; PubkeyAuthentication yesTest the SSH configuration syntax before reloading the service, and keep the original session alive until the replacement connection has been proven. Those two habits are more important than memorizing a snippet.
Keep an access inventory
Record the device, account, purpose, fingerprint, and who is responsible for removing the key. When access ends, remove that exact public-key line from the target account and test another approved path. Do not share private keys to avoid setting up a new one. Rotate the key when a device is replaced or might have been exposed.
When a key login fails
Confirm the username, the fingerprint being offered, and the matching public key on the server. Check permissions on the server-side .ssh directory and authorized_keys file. Then read the server log and use verbose client output if needed: ssh -vvv -o PreferredAuthentications=publickey user@host true.
A private-key permission error is the client protecting the key. Fix the file ownership and permissions rather than disabling that check. Good SSH hygiene is mostly small, deliberate steps that leave you with a known way back in.