20 Common SSH Errors on Ubuntu (and How to Fix Each One)

SSH error messages are terse. Most of them mean exactly one specific thing, but you have to know which thing. This is a reference list of the 20 errors I’ve actually hit running Ubuntu servers in production and at home, with diagnoses and fixes for each.

Tested against: Ubuntu Server 22.04 LTS, 24.04 LTS. OpenSSH 8.9 and 9.6. Most errors apply to other Linux distros and to OpenSSH on macOS/Windows.

1. Connection refused

ssh: connect to host 192.168.1.50 port 22: Connection refused

Cause: Server is reachable but nothing is listening on port 22.

Fix:
– sudo systemctl status ssh (or ssh.socket on 24.04+) — is it running?
– sudo ss -tnlp | grep :22 — is anything actually bound to port 22?
– Did you change the port in sshd_config? Use ssh -p NEWPORT user@host.
– On a fresh install: did you actually apt install openssh-server? It’s not installed by default on Ubuntu Desktop.

2. Connection timed out

ssh: connect to host 1.2.3.4 port 22: Connection timed out

Cause: Packets aren’t reaching the server. Firewall, routing, or the server is offline.

Fix:
– Can you ping the server? ping host. If no, network/routing issue.
– If ping works but SSH times out, firewall is blocking. Check ufw status on the server.
– Cloud server: check the cloud provider’s security group / network ACL.
– Home network: check the router’s port forwarding rules.

3. Permission denied (publickey)

ssh: Permission denied (publickey).

Cause: The server only accepts SSH key auth and your key isn’t being offered or accepted.

Fix:
– ssh -v user@host 2>&1 | grep -A2 'Offering public key' — which keys are being offered?
– On the server, check ~/.ssh/authorized_keys exists for the user, contains your key, and has correct permissions (600, owner = the user).
– Server-side directory perms: ~/.ssh must be 700, ~/.ssh/authorized_keys must be 600. Looser perms cause silent rejection.
– sudo grep PubkeyAuthentication /etc/ssh/sshd_config — must be yes.

4. Permission denied (publickey,password)

user@host: Permission denied (publickey,password).

Cause: Both auth methods failed. You typed the wrong password, OR the username doesn’t exist on the server.

Fix:
– On the server, run whoami to confirm the username you should use.
– Try the password again, slowly. Check Caps Lock.
– If you’re certain the credentials are right, check /etc/ssh/sshd_config for AllowUsers — if it’s set, only listed users can SSH in.

5. Host key verification failed

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Cause: The server’s host key has changed since the last time you connected.

Fix:
– Most innocent: server was reinstalled or rebuilt, so it has a new host key.
– Less innocent: someone is doing a man-in-the-middle attack.
– To clear the cached old key: ssh-keygen -R 192.168.1.50
– Reconnect, accept the new fingerprint (verify it’s correct first if security is a concern).

6. Connection reset by peer

ssh_exchange_identification: read: Connection reset by peer

Cause: Server actively dropped the TCP connection during handshake.

Fix:
– Most common: fail2ban or similar tool banned your IP. Wait the configured ban time, or unban from another machine: sudo fail2ban-client unban 1.2.3.4.
– Less common: sshd has a misconfiguration causing it to crash on connect. Check journalctl -u ssh.service on the server.
– Even less common: MaxStartups is set very low and you’ve hit the limit (rare on a healthy server).

7. Port 22: No route to host

ssh: connect to host 1.2.3.4 port 22: No route to host

Cause: Network layer can’t find the destination. Either the server is down, or routing/DNS resolves to an unreachable network.

Fix:
– Check the IP is correct. dig host if using a hostname.
– traceroute host to see where the route dies.
– Cloud server: confirm it’s running in the provider console.

8. ssh_exchange_identification: Connection closed by remote host

Cause: Server accepted the TCP connection but closed it before the SSH handshake completed.

Fix:
– Same checklist as #6 (fail2ban, sshd misconfiguration).
– Check /etc/hosts.deny on the server — if your IP is listed there, sshd refuses you instantly.
– Server out of disk space (no, really — sshd can fail to fork new connections if / is full).

9. Permissions are too open

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/id_ed25519' are too open.

Cause: SSH refuses to use a private key that’s readable by anyone other than you.

Fix:

chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh

10. Could not open a connection to your authentication agent

Could not open a connection to your authentication agent.

Cause: ssh-add was run but ssh-agent isn’t started.

Fix:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

11. WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED

Same as #5. See above.

12. ssh: Could not resolve hostname

ssh: Could not resolve hostname server: Name or service not known

Cause: DNS lookup failed.

Fix:
– Check the hostname is spelled right.
– dig server to see if DNS resolves.
– For .local mDNS hostnames: needs avahi-daemon on the network. May not work over corporate VPNs or cellular.
– Use the IP address directly to bypass DNS.

13. Read from socket failed: Connection reset by peer

Cause: Network connection dropped mid-session. Could be router restart, ISP outage, or server side.

Fix:
– Reconnect.
– For sessions you don’t want to lose: use tmux or screen on the server. ssh user@host then tmux. If the SSH session drops, reconnect and tmux attach — you’re back in your session with all your work.

14. error: kex_exchange_identification: client sent invalid protocol identifier

Cause: Something is connecting to port 22 that isn’t SSH. Often a misconfigured load balancer or health check probing the wrong protocol.

Fix:
– Check what’s hitting your SSH port: journalctl -u ssh.service | grep kex
– If it’s a load balancer / monitoring tool, point it elsewhere.

15. fatal: getpwuid failed

Cause: The user account exists in /etc/passwd but their home directory is missing or unreadable.

Fix:
– ls -ld /home/username on the server — does the home directory exist?
– If missing, recreate it: sudo mkhomedir_helper username (or restore from backup).

16. Disconnected: No supported authentication methods available

Cause: Server has disabled every auth method this client offers. Common after disabling password auth without first deploying keys.

Fix:
– This is the “you locked yourself out” message. You need physical/console access to fix sshd_config.
– Edit /etc/ssh/sshd_config from the local console: re-enable PasswordAuthentication yes temporarily, restart sshd, deploy your key, then disable passwords again.

17. Bind for 0.0.0.0:22 failed: address already in use

Cause: sshd can’t start because something else is on port 22.

Fix:
– sudo ss -tnlp | grep :22 — find what’s using the port.
– Often: an old sshd process didn’t clean up. sudo pkill sshd && sudo systemctl start ssh.

18. Too many authentication failures

Received disconnect from 1.2.3.4 port 22:2: Too many authentication failures

Cause: Your SSH agent has many keys, SSH offers them all, server rejects after MaxAuthTries (default 6).

Fix:
– Specify exactly which key to use: ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes user@host
– Or set up ~/.ssh/config with explicit per-host IdentityFile and IdentitiesOnly yes.

19. Welcome message printed but immediate disconnect

Cause: The user’s login shell is broken. SSH authenticates, then tries to start the shell, and the shell exits immediately.

Fix:
– Check the user’s shell in /etc/passwd (last field). Is it a valid shell? /bin/bash is the safe default.
– Check ~/.bashrc and ~/.bash_profile for a syntax error or exit statement.
– Try logging in with a different shell: ssh user@host -t '/bin/sh'.

20. ssh.socket vs ssh.service confusion (Ubuntu 24.04)

Cause: Tutorial says systemctl status ssh shows Active: active (running). On 24.04 you see Active: active (listening) (different state) or Active: inactive (dead) (because socket activation hasn’t fired yet).

Fix:
– This is normal on 24.04+ with socket activation. SSH is working.
– See the Enable SSH on Ubuntu Server pillar for the full explanation. Short version: socket waits for connection, then starts service. inactive (dead) for ssh.service is expected when no one is connected.

Same Errors, Same Fixes, Any Environment

“Connection refused” on your Pi and on a production VM have the same diagnostic steps. “Permission denied (publickey)” means the same thing whether you are connecting to your homelab or to an Azure VM. These error messages do not change based on who owns the server or how much the infrastructure costs.

Troubleshooting SSH at home builds the same diagnostic instinct you need at work. Check the service, check the firewall, check the keys, check the permissions, read the verbose output. That sequence works everywhere. The person who has debugged these errors twenty times on their own kit is the person the team turns to when production SSH breaks at 2am.

---

Companion guides: Enable SSH on Ubuntu Server, SSH Key Authentication on Ubuntu, SSH Hardening, Fail2ban for SSH. If you’ve hit an SSH error not on this list, drop it in the comments and I’ll add it.