What's the difference between 'Connection refused' and 'Connection timed out' for SSH?

They point at opposite problems. Refused means your packet reached the host and the host actively said no — it sent back a TCP RST because nothing is listening on port 22. The machine is up and reachable; SSH just isn't answering there. Timed out means your packet got no reply at all — a firewall silently dropped it, or the host is down or unreachable. Refused = the box spoke to you, look at the SSH service. Timed out = it never did, look at the firewall or the route. Same 'I can't log in' symptom, completely different fix.

SSH says refused but I know the server is running. Why?

Almost always one of three things. The sshd daemon isn't actually running (it crashed, failed to start after a config edit, or was never enabled). It's listening on a different port than 22 (someone set `Port 2222` in sshd_config). Or it's bound to `127.0.0.1` via a `ListenAddress` line, so it only accepts connections from the machine itself and refuses everything from outside. Check the port and the bind address before you touch the firewall — refused is a service problem, not a firewall one.

It worked yesterday and now it's refused from my IP only. What happened?

If everyone else can reach it but you get refused specifically from your address, suspect fail2ban or a similar intrusion-prevention tool. After a few failed logins it adds a firewall rule that rejects your IP, which surfaces as Connection refused from your machine while the server is perfectly reachable for others. Wait out the ban, or get in from another network to remove your IP from the jail.

Do I change the SSH port to fix this?

No — changing the port doesn't fix a refused connection, it just moves the target. If sshd is down, it's down on every port. Diagnose why nothing is listening on the port you're actually connecting to first. Changing ports is a hardening choice (it cuts drive-by scan noise), not a repair for 'refused', and if you do change it you have to open the new port in every firewall in the path or you'll trade refused for timed out.

Views: 12

ssh: connect to host port 22: Connection refused

ssh port 22 Connection refused means the host answered but nothing's listening there — not a firewall timeout. Fix it in order. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Refused Is Good News, Actually

ssh: connect to host port 22: Connection refused looks like a failure, and it is — but it’s the helpful kind. Refused means your connection attempt made it all the way to the server, and the server answered. It answered “no,” but it answered. The network path works, the host is up and reachable, DNS resolved to the right place. You’ve eliminated an entire category of problems in a single word.

Here’s the mechanism. When you ssh to a host, your machine sends a TCP SYN to port 22. If a program is listening there, you get a SYN-ACK and the connection proceeds. If the host is up but nothing is listening on port 22, the operating system immediately fires back a TCP RST — a reset — and your client reports “Connection refused.” That RST is the host actively rejecting you on the spot. It could only have come from the host itself, which means the packet got there.

Contrast that with the other error you might have seen: Connection timed out. That’s silence. You sent the SYN and got nothing back — no RST, no reply — until the client gives up. Silence almost always means a firewall dropped your packet on the floor, or the host is unreachable entirely. Same login failure to a human; opposite place to look.

This one distinction is the whole diagnosis. Refused → the packet reached the machine, so the problem is the SSH service (or the port it’s on). Timed out → the packet never got a reply, so the problem is a firewall or the route in front of the machine. Get this backwards and you’ll spend an hour rewriting firewall rules to fix a daemon that simply isn’t running.

Top 3 Causes of Refused on Port 22

sshd isn’t running. The most common cause, and the one people check last. The daemon crashed, or it failed to restart after someone edited sshd_config and left a syntax error, or it was never enabled to start on boot. With nothing listening on 22, the kernel refuses every connection instantly. systemctl status ssh (or sshd) on the box tells you in one line. If it won’t start, sshd -t validates the config without launching.
SSH is listening on a different port. Someone changed Port 22 to Port 2222 in sshd_config — a common hardening step — and now ssh host (which defaults to 22) hits a port with nothing behind it and gets refused. The service is healthy; you’re knocking on the wrong door. Connect with ssh -p 2222 host, or check ss -tlnp | grep sshd on the server to see what it’s actually bound to.
sshd is bound to localhost only. A ListenAddress 127.0.0.1 line (or a service that ships that way) makes sshd accept connections only from the machine itself. From the box, ssh localhost works perfectly; from anywhere else, refused. This looks exactly like a firewall problem and isn’t — the fix is binding to 0.0.0.0 (all interfaces) or the correct public address, then restarting sshd.

A fourth worth naming because it fools people: fail2ban banning your own IP. If it’s refused from your address but fine from others, an intrusion-prevention tool has added a rule rejecting you after failed attempts. That’s not the server being down; it’s the server keeping you out specifically.

Diagnose with DechoNet

Port Check — run it against your server on port 22 (or your custom SSH port) from outside. This is the single most useful test, because it tells you which of the two worlds you’re in. Closed (refused) confirms the host is up and nothing is listening — go fix the SSH service. Filtered (timeout) means something is dropping the packets — go fix the firewall. An external check settles the refused-vs-timeout question that your own machine can’t answer about itself.
DNS Lookup — before blaming SSH, confirm the hostname resolves to the IP you expect. If the name points at an old server, a load balancer, or a CDN edge, you’re getting refused from a machine that was never running your sshd. A stale A record produces a very convincing “SSH is broken” that is really a DNS problem.

Resolution Checklist

Confirm which error you have. Refused = service/port problem (this guide). Timed out = firewall/route problem (check security groups and firewall rules instead).
Verify the hostname resolves to the server you think it does before anything else.
On the server, check the daemon: systemctl status ssh / sshd. If it’s dead, sshd -t to find the config error, then restart.
Confirm the port. ss -tlnp | grep sshd shows what sshd is bound to. If it’s not 22, connect with -p <port> or change it back.
Confirm the bind address. If it’s 127.0.0.1, sshd is localhost-only — bind it to 0.0.0.0 or the public interface and restart.
If refused from your IP alone, check fail2ban / intrusion-prevention jails and unban yourself.
Re-run Port Check from outside after each change to confirm 22 is actually reachable, not just listening locally.

When to Escalate

If Port Check reports filtered / timed out rather than closed, you’re not in this guide anymore — the packets aren’t reaching sshd. Look at the host firewall, cloud security groups, and network ACLs, all of which default to dropping inbound traffic silently.
If the server is a managed instance you don’t have console access to and sshd won’t come back, escalate to whoever holds out-of-band access (the cloud console, a serial/rescue console). Once you’re locked out of SSH, fixing SSH usually requires a path that isn’t SSH.