SSH "Permission denied (publickey)": how to fix it

What "Permission denied (publickey)" means

This error means the server refused your authentication — the network connection worked, but the server didn't accept any of the credentials your client offered. With (publickey) in the parentheses, the server only allows key authentication and none of your keys matched. It is almost always one of five causes: wrong username, wrong/missing key, the public key isn't on the server, wrong permissions on ~/.ssh, or the server disallows your auth method. Here's how to find which one in minutes.

The five causes, in order of likelihood

1 — Check the username first

The most common cause, especially on cloud servers: each image has its own default user — ubuntu (Ubuntu), ec2-user (Amazon Linux), root (many VPS images), pi (older Raspberry Pi OS), debian, admin… If the username is wrong, the server rejects you before your key is even considered, and the error looks identical.

2 — Make sure the right key is offered

On a desktop, ssh -v user@host shows which keys the client tries ("Offering public key…"). In a mobile client, open the connection settings and confirm a key is actually attached to this connection — a connection created "with password" doesn't offer a key at all. In TermAI, edit the connection and switch auth to your key.

3 — Install the public key on the server

The server only accepts keys listed in ~/.ssh/authorized_keys for the user you log in as. If you can still get in another way (password, console):

# from a machine that can log in:
ssh-copy-id user@host
# or manually append your public key:
cat your_key.pub >> ~/.ssh/authorized_keys

From a phone, TermAI can do this for you: it generates an Ed25519 key and has a one-tap deploy to server that writes the public key into authorized_keys over an existing working login. Note: the key goes under the specific user's home — installing it for root doesn't help you log in as ubuntu.

4 — Fix permissions on the server

OpenSSH silently ignores authorized_keys if the file or directories are too open. On the server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

Also check the home directory itself isn't group/world-writable. This is the classic "I installed the key but it still asks/fails" cause — check /var/log/auth.log on the server; it logs "Authentication refused: bad ownership or modes".

5 — Check what the server allows

In /etc/ssh/sshd_config: if PasswordAuthentication no and your key isn't installed, you're locked into the failing path; if PermitRootLogin no and you're trying root, that's the rejection. Fix the config (or use the right user), then sudo systemctl restart ssh. See disabling root login safely.

Debugging this from a phone

When this hits while you're on a phone, the painful part is reading verbose errors and remembering the diagnostic commands. If you have any working session to the box, select the error output and ask the assistant — TermAI's AI reads the actual message and the server context and tells you which of the five causes it is, with the exact fix command to review and run.

FAQ

What does Permission denied (publickey) mean?
The server only accepts SSH key authentication and none of the keys your client offered matched. Check username, key selection, authorized_keys, and permissions — in that order.

Why does it fail even though I installed the key?
Usually permissions: ~/.ssh must be 700 and authorized_keys 600, owned by the login user. Or the key was installed under a different user than the one you log in as.

How do I see what's actually failing?
On a desktop run ssh -v user@host; on the server check /var/log/auth.log (or journalctl -u ssh) — it states the reason explicitly.

Can I fix this from my phone?
Yes, if you have any working way in (password login or another key). TermAI can deploy a fresh key to the server in one tap, and its AI can diagnose the auth.log output.

Quick Facts

• Meaning: server refused auth — no offered key matched (auth, not network)
• Top causes: wrong username · key not offered · key not in authorized_keys · bad permissions · server config
• Permissions: ~/.ssh 700, authorized_keys 600
• See the real reason: ssh -v client-side, /var/log/auth.log server-side