ssh: connect to host … port 22: Connection refused means the network reached the server and something actively said “nothing is listening here.” That is different from a timeout: a refused connection is a fast, definite no, so the problem is almost always on the server, not the route to it.
Four things cause it, in rough order of frequency: the SSH daemon is not running, it listens on a different port, a firewall rejects the port, or you are connecting to the wrong address. Work through them in that order.
1. Is sshd actually running?
If you have console access (through your provider’s panel or a rescue system), check the service first:
sudo systemctl status ssh # Debian/Ubuntu
sudo systemctl status sshd # RHEL/Rocky/Alma/Fedora
sudo systemctl start ssh
sudo systemctl enable sshA crash after an edit to /etc/ssh/sshd_config is common. Validate the config before restarting so you do not lock yourself out further:
sudo sshd -t # prints the offending line, or nothing if OK
sudo systemctl restart ssh2. Is it listening on the port you expect?
Many hardened servers move SSH off 22. Confirm what is actually bound:
sudo ss -tlnp | grep sshIf it answers on, say, 2222, connect with ssh -p 2222 user@host. No line at all means the daemon is down, so go back to step 1.
3. Is a firewall rejecting the port?
A firewall that rejects (rather than drops) produces exactly this message. Allow the SSH port and re-check:
# Debian/Ubuntu (ufw)
sudo ufw allow 22/tcp && sudo ufw reload
# RHEL family (firewalld)
sudo firewall-cmd --add-service=ssh --permanent
sudo firewall-cmd --reload4. Are you connecting to the right host?
- A stale DNS record points your hostname at an old IP. Test the raw address:
ssh user@203.0.113.10. - The server was rebuilt and got a new key or IP. Clear the stale entry with
ssh-keygen -R hostif you also see a key-mismatch warning.
Refused vs. timed out
If instead of “refused” you see the connection hang and eventually Connection timed out, the packet never reached a listening socket. That is a routing or drop-style firewall problem, or the wrong IP entirely, not a stopped daemon. Refused is loud and immediate; timeout is silence.
To tell the two apart from outside your own network, enter the server’s address and port 22 in the open port checker: it reports closed for a refusal and no answer for a drop.
And if the connection now goes through but ends in Permission denied (publickey), sshd is fine: the server is rejecting your key, which is a different set of causes: Permission denied (publickey).
If you have locked yourself out completely, a host with out-of-band console access saves the day. Every VMHeaven KVM plan ships with a browser VNC console in the panel, so a bad sshd_config is a two-minute fix rather than a reinstall.
Frequently asked
What is the difference between 'connection refused' and 'connection timed out'?
Refused is immediate: a socket exists and rejected you, so sshd is usually down or the port is wrong. Timed out is silence: packets never reached a listener, which points to routing, a drop-style firewall or the wrong IP.
SSH was working yesterday and now refuses. What changed?
Most often an edit to sshd_config that crashed the daemon on restart, or a firewall rule that closed the port. Run 'sudo sshd -t' from the console to catch a bad config.
How do I get in if SSH refuses all connections?
Use out-of-band access: your provider's panel console or a rescue system. From there you can start sshd, fix the config or open the firewall.