Can't log in with SSH? Fix "Permission denied (publickey)", "Connection refused" and timeouts

First: don't lock yourself out further

• Keep any session that still works open. Fix things from there, and test with a second window.
• Don't try again and again. Newer OpenSSH blocks your address for a while after a few failures (see step 5).
• No way in at all? Your hosting provider has a web console (often called "Console", "VNC" or "Rescue") that works without SSH. Log in there and fix things from the server side.

1. Which error do you have?

Add -v to see more: ssh -v anna@example.com. The last line tells you which case it is:

• Permission denied (publickey) or (publickey,password): you reached SSH, but it didn't accept your login. See steps 2 to 4.
• Connection refused: you reached the server, but nothing listens on that port. SSH is stopped or listens on another port. See step 6.
• Connection timed out: nothing answered at all. A firewall drops the connection, or the address is wrong. See step 7.
• Connection closed by ... port 22 right away, before any login: often the penalty block from step 5.

2. "Permission denied": read the server's side

The client never says why. The server does. From a working session or the web console:

sudo journalctl -u ssh -n 30 --no-pager

On some systems the service is called sshd instead of ssh. These are the lines we saw:

• Authentication refused: bad ownership or modes for file /home/anna/.ssh/authorized_keys: the key file's permissions are too open. See step 3.
• Authentication refused: bad ownership or modes for directory /home/anna: the home folder can be changed by everyone. See step 3.
• Invalid user bob: that user doesn't exist on the server. Check the name before the @.
• Failed publickey for anna ... ED25519 SHA256:6naU...: the server got a key but didn't find it in authorized_keys. See step 4.

3. Fix the permissions

SSH refuses a key file that other users could have changed. That's a safety check, called StrictModes, and it's on by default. In our test, an authorized_keys file with 666, and a home folder with 777, both made SSH refuse the key. A home folder with 775 was accepted. Set them like this:

sudo chown -R anna:anna /home/anna/.ssh
sudo chmod 755 /home/anna
sudo chmod 700 /home/anna/.ssh
sudo chmod 600 /home/anna/.ssh/authorized_keys

Change anna to the user. A .ssh folder owned by root also failed in our test, but with only a plain "Failed publickey" line, so check the owner too: ls -la /home/anna/.ssh. Don't turn off StrictModes to make the error go away.

4. The key isn't the one on the server

The server's log shows a fingerprint (SHA256:...) of the key you offered. Compare it with your key on your own computer:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

And with the keys on the server:

ssh-keygen -lf /home/anna/.ssh/authorized_keys

If your fingerprint isn't in the server's list, the server doesn't have your key. With ssh -v, the lines starting with Offering public key show which keys your computer tried. If it's the wrong one, name the right key: ssh -i ~/.ssh/id_ed25519 anna@example.com.

A key line split in two also fails. In our test, a key pasted with line breaks in the middle gave the same "Failed publickey". Each key must be one long line in authorized_keys. Add keys with ssh-copy-id from your computer where you can, rather than by copy and paste. See SSH keys and turning off password login.

5. OpenSSH's penalty block

Since version 9.8, OpenSSH blocks an address for a short time after failed logins. Debian 13 has OpenSSH 10, so it's on by default there. Ubuntu 24.04 still has an older version without it. In our test, after 4 failed tries, even the right key got only Connection closed by ... port 22. The server's log said:

drop connection #0 from [203.0.113.10]:39200 on [192.0.2.5]:22 penalty: failed authentication

The block lasted 21 seconds in our test. Each failure adds to it, up to 10 minutes. So if you suddenly get "Connection closed", stop trying for a few minutes, fix the cause, then try once. See the settings with sudo sshd -T | grep -i persourcepenalties.

If you run Fail2ban too, it can block you for longer. Check from the web console: sudo fail2ban-client status sshd.

6. "Connection refused": SSH isn't listening there

In our test, we got this when SSH was stopped, and when it listened on port 2222 but we tried port 22. From the web console, check that SSH runs, and on which port:

sudo systemctl status ssh
sudo ss -ltnp | grep ssh

If you moved SSH to another port, use it: ssh -p 2222 anna@example.com. If SSH won't start after a settings change, check the settings. In our test, one typo was enough to stop it:

$ sudo sshd -t
/etc/ssh/sshd_config.d/lab.conf: line 4: Bad configuration option: PasswordAuthentcation
/etc/ssh/sshd_config.d/lab.conf: terminating, 1 bad configuration options

Always run sudo sshd -t before you reload SSH, and keep a working session open while you test. On Ubuntu 24.04, SSH is usually started by ssh.socket (check with systemctl is-active ssh.socket). Then a new Port line in sshd_config only works after sudo systemctl daemon-reload and sudo systemctl restart ssh.socket. Restarting ssh alone keeps the old port.

7. "Connection timed out": a firewall drops it

In our test, a firewall rule that dropped the SSH port gave Connection timed out, not "refused". Check, in this order:

• The address: is it the right IP? Did the server get a new one?
• The server's firewall: sudo ufw status. Is your SSH port allowed? If you changed the port, did you allow the new one before closing the old one? See the UFW firewall guide.
• The provider's firewall: many providers have a firewall in their control panel, in front of the server. It must allow the port too.
• Your own network: some office and public Wi-Fi networks block uncommon ports. Try from your phone's hotspot.

Quick list

• Permission denied: read journalctl -u ssh on the server.
• bad ownership or modes: chmod 755 home, 700 .ssh, 600 authorized_keys, owned by the user.
• Failed publickey: compare fingerprints with ssh-keygen -lf. One key per line.
• Connection closed right away: OpenSSH's penalty block. Wait a few minutes.
• Connection refused: SSH stopped or on another port. sshd -t before every reload.
• Timed out: a firewall, on the server, at the provider, or on your network.
• No way in: the provider's web console.

Official sources

• sshd_config manual (StrictModes, PerSourcePenalties)
• OpenSSH 9.8 release notes (the penalty feature)
• ssh-keygen manual (-l for fingerprints)

Next steps: once you're back in, go through SSH keys and turning off passwords and SSH two-factor login, and check who logged in while you were locked out.

ServerNest is being built so you can see and fix a server's state from the dashboard, even when SSH gets in the way. Join early access to try it first.

← Back to the security blog