An SSH login checks both sides: the client checks the server, and the server checks the user. A failure of one check looks different from a failure of the other.
SSH gives you a command line on another machine. First the client makes sure it talks to the right server: the server has a host key, and the client keeps its copy in known_hosts. Then the server decides whether to let the user in.
The user logs in with a key pair. The private key stays on the client (~/.ssh/id_ed25519) and is never sent anywhere. The public key sits on the server, in the authorized_keys file in the account's home directory.
| Failed check | What ssh prints |
|---|---|
| the client did not recognise the server key | Host key verification failed. |
| the server did not accept the user key | Permission denied (publickey,…) |
At the start of the lesson the second check failed: the client recognised the server, and the server refused deploy.
ssh printed Host key verification failed. Which check failed?
-
A password is asked for after the server key is checked. Here
sshstopped earlier, atknown_hosts. -
The server checks the
authorized_keysmode when it decides about the user, and that refusal looks likePermission denied. -
Things never got as far as checking the user. A refusal from the server shows up as
Permission denied.
Host key verification failed comes from the client: the key the server offered does not match the known_hosts entry, or there is no entry. The server never got to checking the user.
Key points
-
The client checks the server against
known_hosts; the server checks the user againstauthorized_keys. -
Host key verification failedis the client refusing;Permission deniedis the server refusing.