The "Permission denied (publickey)" error means the SSH server would not accept your key, or you offered the wrong one. It is almost always one of a handful of causes — here is how to find which, and fix it.
Quick answer
"Permission denied (publickey)" means the server did not accept the SSH key you offered. Run ssh -v user@server to see why, then check the usual causes: the wrong username, your public key missing from ~/.ssh/authorized_keys, wrong permissions (700 on ~/.ssh, 600 on the file), or the wrong key offered — choose it with -i.
Run the connection with -v (verbose): ssh -v user@server. The output shows exactly which keys were offered and why each was rejected — the fastest way to diagnose this.
Cause 1: wrong username
A key installed for one user will not work for another. Cloud images ship with a specific default user — not your own name. Use the right one for your image:
| Image / distro | Default SSH user |
|---|---|
| Ubuntu | ubuntu |
| Debian | debian (or root) |
| AlmaLinux / Rocky / CentOS | almalinux / rocky / centos (or root) |
| Most bare VPS / dedicated | root |
Cause 2: the key is not on the server (or is the wrong one)
Your public key must be in ~/.ssh/authorized_keys on the server, for the user you log in as. If it is missing, add it (via console access or your host's panel). Make sure your client offers the matching private key:
ssh -i ~/.ssh/id_ed25519 user@your-server-ipCause 3: wrong file permissions (very common)
SSH refuses keys if the permissions are too open — this is a security feature. On the server, the .ssh folder and authorized_keys file must be locked down:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.sshThe exact permissions SSH expects — get any of these wrong and the key is refused:
| Path | Permission | Meaning |
|---|---|---|
| ~/.ssh (folder) | 700 | Only you can read/write/enter it |
| ~/.ssh/authorized_keys | 600 | Only you can read/write it |
| Private key (your PC) | 600 | Only you can read it |
| Home directory | 755 or stricter | Not group/other writable |
On your local machine, your private key should be chmod 600 too.
Cause 4: keys only, and yours is not working
If password login is disabled (good hardening) and your key fails, you cannot fall back to a password — you must fix the key or use your host's console/recovery to add a working one. This is why you should always test a new key before disabling passwords.
The quick checklist
- Run
ssh -vand read which key is rejected and why. - Confirm you are using the correct username for your image.
- Make sure your public key is in the server's
~/.ssh/authorized_keys. - Fix permissions:
700on.ssh,600onauthorized_keys. - Point to the right private key with
-i.
Nine times out of ten this is either the wrong username or too-open permissions on ~/.ssh. Check those two first.
Cause 5: the SSH agent is offering the wrong key (or too many)
If your agent holds several keys, SSH may offer the wrong ones first and get rejected before reaching the right one — which can even trip a "too many authentication failures" cutoff. Force the correct key with -i and IdentitiesOnly=yes, or clean up your agent. See too many authentication failures.
Cause 6: the server rejects your key type or a home-directory permission
Newer OpenSSH releases refuse old key algorithms (like legacy RSA-SHA1) by default, so an older key can be silently declined. A world-writable home directory also makes SSH ignore authorized_keys. Generate a modern ed25519 key, and make sure your home directory isn't group/other writable.
How to prevent SSH key lockouts
- Always keep a working session open when changing SSH or permissions, and test the new key in a second terminal.
- Never disable password login until key login is confirmed working.
- Use a modern ed25519 key and keep private keys at chmod 600.
- Know where your host's VNC/console recovery is before you need it.
Related errors
If SSH refuses the connection entirely rather than rejecting your key, see SSH connection refused. New to SSH? Start with connecting to your server with SSH. For the full lockdown approach, see how to secure a Linux VPS.