SSH Permission Denied (publickey)? How to Fix It

"Permission denied (publickey)" means SSH reached your server but it rejected your key. Run ssh -v to see which key was offered, then check authorized_keys.

Getting locked out of your own server is stressful, especially when a site is down and you need to get in now. The good news: SSH errors are precise. "Connection timed out", "Connection refused" and "Permission denied" each point at a different layer, and the server's auth log tells you exactly why it said no. This is the order I work through on my own Ubuntu servers and on client boxes where someone changed a firewall rule or a permission and lost access.

Key takeaways

• Read the exact error first. Timed out = network or firewall. Refused = nothing listening on that port. Permission denied = sshd is running but rejected your login.
• ssh -v shows which keys your client offered and where the handshake stopped. It's the fastest single check.
• The server's log says why it refused: sudo journalctl -u ssh on Ubuntu. "Bad ownership or modes" is the classic.
• Permissions matter: ~/.ssh must be 700 and authorized_keys 600, owned by the user, or sshd ignores them.
• Fully locked out? Use your VPS provider's web or serial console. It works without SSH.

Which SSH error do you have?

Run the connection with verbose output and look at the last lines:

ssh -v deploy@203.0.113.10
# more detail if you need it:
ssh -vvv deploy@203.0.113.10

• Connection timed out: packets never got an answer. Wrong IP, server down, or a firewall (UFW, the provider's cloud firewall, a security group) dropping port 22.
• Connection refused: the server answered "nothing here". sshd isn't running, it listens on another port, or Fail2ban rejects your IP.
• Permission denied (publickey): you reached sshd and authentication failed. This is the most common one and the rest of this guide covers it in detail.
• Host key verification failed or "REMOTE HOST IDENTIFICATION HAS CHANGED": the server's identity differs from what your laptop remembers. Normal after a rebuild; suspicious if nothing changed.

Fix "Permission denied (publickey)"

1. Check which key your client offers

ssh -v deploy@203.0.113.10 2>&1 | grep -E 'Offering|Authenticated|denied'

If the key you expect isn't in the "Offering public key" lines, point at it explicitly: ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes deploy@203.0.113.10. IdentitiesOnly also fixes "Too many authentication failures", which happens when your SSH agent offers five wrong keys before the right one and the server gives up.

Also check the username. Many cloud images only accept ubuntu, debian or root for the first login, and a key added to deploy's account won't work for root.

2. Get in another way and read the server's log

Use the provider's browser console (Hetzner, DigitalOcean, Hostinger, AWS and others all have one) or another user that still works. Then:

sudo journalctl -u ssh -n 50 --no-pager      # Ubuntu / Debian
sudo journalctl -u sshd -n 50 --no-pager     # RHEL, Rocky, Alma
sudo tail -n 50 /var/log/auth.log            # older setups

The log line usually names the problem: bad permissions, an unknown user, a key type that isn't allowed, or a user not in AllowUsers.

3. Fix permissions and ownership

sshd's StrictModes (on by default) refuses keys when the home directory, ~/.ssh or authorized_keys is writable by anyone else. This is the cause I see most after someone ran chmod -R 777 or copied files as root:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 755 /home/deploy          # or 750; never group/world-writable
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys

4. Check the key is actually in authorized_keys

Each key must be one line, starting with its type (ssh-ed25519, ssh-rsa, ecdsa-sha2-…). Pasting into a web console often breaks the line or adds smart quotes. Compare fingerprints on both sides:

# on your laptop
ssh-keygen -lf ~/.ssh/id_ed25519.pub
# on the server
ssh-keygen -lf /home/deploy/.ssh/authorized_keys

If the server is old and you use a new key type, or the server is new and your key is an old ssh-rsa one, the algorithm can be refused. OpenSSH 8.8 and later disable RSA signatures with SHA-1 by default. The clean fix is a new Ed25519 key: ssh-keygen -t ed25519.

5. Check sshd's effective config

sudo sshd -T | grep -E 'pubkeyauthentication|passwordauthentication|permitrootlogin|allowusers|authorizedkeysfile'

sshd -T prints the settings sshd actually uses, including files in /etc/ssh/sshd_config.d/, where cloud images drop overrides such as 50-cloud-init.conf. Look for PermitRootLogin no when you log in as root, an AllowUsers line that leaves you out, or a custom AuthorizedKeysFile. Always test before restarting: sudo sshd -t must print nothing.

Fix "Connection refused"

sudo systemctl status ssh
sudo ss -tlnp | grep ssh
sudo fail2ban-client status sshd          # if Fail2ban is installed

• sshd not running: sudo sshd -t shows the config error that stopped it. Fix it, then sudo systemctl restart ssh.
• Different port: connect with ssh -p 2222 …. On Ubuntu 24.04, sshd is socket-activated: after changing Port you must run sudo systemctl daemon-reload and sudo systemctl restart ssh.socket, or it keeps listening on the old port. That trips up a lot of people following older guides.
• Banned by Fail2ban after a few failed attempts: sudo fail2ban-client set sshd unbanip YOUR.IP.

Fix "Connection timed out"

Check the server is up in your provider's panel, then the firewalls. There are often two: UFW on the server and a cloud firewall in the provider's dashboard. Both must allow your SSH port. If you changed the SSH port, allow the new one before removing 22:

sudo ufw allow 2222/tcp
sudo ufw status numbered

How to never get locked out again

• Keep a second session open while you change sshd or firewall settings, and test a new login before closing it.
• Have two keys in authorized_keys (laptop and a backup) and a sudo user besides root.
• Know where your provider's console is before you need it.
• Harden in the right order: keys work first, then disable passwords. My Ubuntu 24.04 hardening checklist does it step by step.

And if the host key changed when you didn't rebuild anything, or you see logins you don't recognise in the auth log, stop and read what to do if your server was hacked. If you got in but the site still isn't loading, the website down checklist is the next step.

Frequently asked questions

What does "Permission denied (publickey)" mean?

Your client reached the SSH server, but none of the keys it offered was accepted for that user, and password login is disabled. The usual causes are the wrong key or username, a missing or broken line in authorized_keys, or permissions on ~/.ssh that are too open.

What permissions should ~/.ssh and authorized_keys have?

The ~/.ssh directory should be 700 and authorized_keys 600, both owned by the user. The home directory must not be writable by group or others, or sshd ignores the keys.

How do I get into my server if SSH is completely broken?

Use your hosting provider's web console, VNC or serial console, which connects like a physical screen and doesn't depend on SSH. Some providers also offer a rescue mode that boots a separate system so you can fix files on the disk.

Why does SSH still use port 22 after I changed it on Ubuntu 24.04?

Ubuntu 24.04 starts sshd through a systemd socket, which reads the port when systemd reloads. Run sudo systemctl daemon-reload and then sudo systemctl restart ssh.socket after editing the Port setting.

Is "REMOTE HOST IDENTIFICATION HAS CHANGED" dangerous?

It's expected after you reinstall or rebuild a server; remove the old entry with ssh-keygen -R and the IP or hostname. If nothing was rebuilt, treat it as a warning sign and verify the new host key through the provider's console before connecting.

Locked out of your server right now?

I recover access to locked-out Linux servers, then set up keys, firewall and console access so it doesn't happen again. See my Linux system admin services or contact me now with the exact SSH error and your provider's name.