Short answer: Permission denied (publickey) means SSH reached the server, but the server refused every key your client offered, and password login is off, so there is no fallback prompt. Run ssh -v to see which key is offered, then check the user name, the key file, the permissions of ~/.ssh and whether the public key is installed.
| Cause | How you can tell | Fix |
|---|---|---|
| Wrong user name | The key is installed for another account (root vs ubuntu, debian, rocky) | ssh correct-user@host |
| The client offers the wrong key, or none | ssh -v never shows your key in an "Offering public key" line | ssh -i ~/.ssh/id_ed25519 user@host, or IdentityFile plus IdentitiesOnly yes in ~/.ssh/config |
| Permissions on the server | The server log says "Authentication refused: bad ownership or modes" | chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, home directory not writable by others |
| The public key is not in authorized_keys | grep the key's last characters in ~/.ssh/authorized_keys finds nothing | ssh-copy-id, or paste the .pub file as one unbroken line |
| Key login is off on the server | sudo sshd -T | grep -i pubkeyauthentication prints no | PubkeyAuthentication yes, then reload ssh |
| An old client signs an RSA key with SHA-1 | The server log names ssh-rsa and PubkeyAcceptedAlgorithms (OpenSSH 8.8 and later refuse it by default) | Update the client, or use an Ed25519 key |
The words in the brackets are the login methods the server still accepts. With (publickey) only a key will do. (publickey,password) means password login is still on, and (publickey,keyboard-interactive) usually means a password or one-time code prompt is possible as well; the sections below go through the key side.
Start with verbose output
The -v flag tells you exactly which keys the client offered and how the server responded. Read it before changing anything:
ssh -v user@host
# look for lines like:
# Offering public key: /home/you/.ssh/id_ed25519
# Authentications that can continue: publickey1. Are you logging in as the right user?
A key in root’s authorized_keys does nothing for ssh ubuntu@host. Cloud images have a default account (ubuntu, debian, admin, ec2-user, rocky), and the key is usually installed there, not for root.
2. Is the client offering the right key?
If -v shows it never offers your key, point at it explicitly:
ssh -i ~/.ssh/id_ed25519 user@hostMake it permanent in ~/.ssh/config so you never guess again:
Host myserver
HostName 203.0.113.10
User ubuntu
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes3. File permissions on the server
sshd refuses keys silently if the files are group- or world-writable. This is the single most common cause after a manual copy. Fix them from a working session or the console:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh4. Is the key actually installed?
Copy it properly rather than pasting by hand: ssh-copy-id appends it with the right permissions:
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host
# manual equivalent, if password login is still on:
cat ~/.ssh/id_ed25519.pub | ssh user@host \
"mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"Confirm you are pasting the .pub file, not the private key, and that it is a single unbroken line beginning with ssh-ed25519 or ssh-rsa.
PuTTY: “Server refused our key”
PuTTY shows Server refused our key where OpenSSH prints Permission denied (publickey). The causes in the table above apply, plus two that are specific to PuTTY:
First, the public key was pasted in the wrong format. PuTTYgen can save the public key as a multi-line file that starts with ---- BEGIN SSH2 PUBLIC KEY ----; OpenSSH does not read that in authorized_keys. Copy the one-line text from the box “Public key for pasting into OpenSSH authorized_keys file” in PuTTYgen instead, which starts with ssh-ed25519 or ssh-rsa.
Second, PuTTY needs its own .ppk format for the private key. A key made with ssh-keygen has to be loaded into PuTTYgen (Conversions, Import key) and saved as a private key first. An old PuTTY release that signs RSA keys with SHA-1 is also refused by current OpenSSH servers; updating PuTTY fixes that.
Permission denied (publickey,keyboard-interactive)
The list in the brackets names the methods the server would still take at that moment. keyboard-interactive is a prompt run by the server, usually a PAM password or a one-time code. When this message ends the login, the server accepts either method and neither worked.
Your key was refused, so the causes in the table above apply, and the prompt failed or never ran: a script running with BatchMode=yes, for example, never shows one. To test the prompt on its own:
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=keyboard-interactive user@hostA different message: the server demands both. With AuthenticationMethods publickey,keyboard-interactive in sshd_config, the comma means “then”: the key first, the prompt after it. Only the next method is offered, so a refused key ends in Permission denied (publickey) and a failed second step in Permission denied (keyboard-interactive). If ssh -v prints Authenticated using "publickey" with partial success. before the prompt step, your key is fine, so stop checking the key and check the code or the password instead.
On the server, these settings decide which case you have:
sudo sshd -T | grep -Ei 'authenticationmethods|kbdinteractiveauthentication|passwordauthentication|usepam'authenticationmethods any is the default and means any single method is enough. KbdInteractiveAuthentication switches the prompt on or off; older guides call it ChallengeResponseAuthentication, which is now a deprecated alias. With UsePAM yes, the password prompt often comes through keyboard-interactive, so setting only PasswordAuthentication no may leave a password prompt in place.
Check the server config and logs
# what the daemon logged when you tried
sudo journalctl -u ssh -n 30
# make sure key auth is even enabled
sudo grep -Ei 'PubkeyAuthentication|AuthorizedKeysFile' /etc/ssh/sshd_configA key-only server with no console access is a lockout waiting to happen. On a VMHeaven VPS the panel sets a new root password and SSH key, and its browser VNC console lets you fix authorized_keys without a reinstall, which is worth having before you disable passwords.
Frequently asked
Why does it not just ask for a password instead?
The server has password authentication disabled, so when the key fails there is no fallback. That is by design on a hardened box; fix the key rather than re-enabling passwords.
My key worked before and now fails. What happened?
Commonly the home directory or ~/.ssh permissions changed and became group-writable, which makes sshd silently ignore the key. Reset them to 700/600.
How do I see which key SSH is actually trying?
Run 'ssh -v user@host' and read the 'Offering public key' lines. Pin the right one with -i and IdentitiesOnly=yes.