SSH troubleshooting — fix common connection problems on Linux — garron.me

This post was originally published on go2linux.org. The domain is no longer mine, but I am the original author. I am republishing it here on garron.me with corrections and improvements.

SSH is one of those tools that works so well you only notice it when it breaks. When it does break, the error messages are often cryptic. This guide covers the most common causes and how to fix them.

Step 1: run SSH in verbose mode

Before anything else, run your SSH command with -vvv to see exactly where it fails:

ssh -vvv user@server

The output shows the handshake step by step. Look for the first line that says debug1: ... failed or Connection refused — that is your starting point.

Connection refused

If you get ssh: connect to host server port 22: Connection refused, the SSH daemon is either not running or listening on a different port.

Check on the server:

sudo systemctl status sshd

If it is not running, start it:

sudo systemctl start sshd
sudo systemctl enable sshd

If sshd runs on a non-standard port, connect with:

ssh -p 2222 user@server

Firewall blocking port 22

Even with sshd running, a firewall can block the connection.

Check with ufw (Ubuntu/Debian):

sudo ufw status

Allow SSH:

sudo ufw allow ssh

With firewalld (Fedora/RHEL/CentOS):

sudo firewall-cmd --list-services
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

With raw iptables, check if port 22 is blocked:

sudo iptables -L INPUT -n --line-numbers | grep 22

hosts.allow and hosts.deny

An often-overlooked cause: TCP wrappers. If /etc/hosts.deny contains ALL: ALL, it blocks every incoming connection including SSH.

Check the file:

cat /etc/hosts.deny

If you see ALL: ALL, comment it out or add an explicit allow in /etc/hosts.allow:

sshd: ALL

Make this change carefully — a misconfigured hosts.deny on a remote server can lock you out completely.

Permission denied (publickey)

Key authentication failures are usually a permissions problem on the server. SSH will silently reject keys if the .ssh directory or authorized_keys file has too-open permissions.

Fix the permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Also verify that the public key was actually copied:

cat ~/.ssh/authorized_keys

If it is empty, copy the key from the client:

ssh-copy-id user@server

Too many authentication failures

If you have many keys in your SSH agent, SSH may try them all and hit the server's MaxAuthTries limit before reaching the right one.

Force SSH to use a specific key:

ssh -i ~/.ssh/my_key user@server

Or add this to ~/.ssh/config:

Host myserver
    HostName server.example.com
    User user
    IdentityFile ~/.ssh/my_key
    IdentitiesOnly yes

IdentitiesOnly yes prevents SSH from trying other keys in the agent.

Check server logs

When all else fails, look at the SSH daemon logs on the server:

sudo journalctl -u sshd -n 50

Or on older systems:

sudo tail -50 /var/log/auth.log

The server-side log usually explains the exact reason a connection was refused or a key was rejected.