SSH connection refused, explained and fixed

ssh: connect to host 203.0.113.10 port 22: Connection refused means the network path works, the target machine is there, and it actively declined the connection on that port. In practice: the SSH daemon is not running, it listens on a different port than the client asked for, or a firewall on the host rejects the port. The refusal itself is information, a silent network problem or a filtered port looks different (a long hang ending in a timeout), so the two should never be troubleshooted the same way.

The checks, in order

  1. Confirm the address and port you actually used: a nonstandard port is the most common self-inflicted cause; servers are frequently moved off 22. ssh -p PORT user@host, and check ~/.ssh/config for a stale Port entry overriding your intention for that host alias.
  2. Check whether sshd is alive on the server through whatever access exists (cloud console, another account, a management panel): systemctl status sshd (or ssh on Debian/Ubuntu, where the service is named ssh). Start it, and if it fails to start, its error output names the cause (a broken config line in /etc/ssh/sshd_config is common after edits; sshd -t validates it).
  3. Confirm it listens: ss -tlnp | grep ssh on the server shows the real port and interfaces. Listening only on 127.0.0.1 explains a server that accepts local but refuses remote connections.
  4. Then look at the host firewall: ufw status, firewalld, or the cloud security group for the instance. A rule that rejects (not drops) the port produces “refused”; a rule that drops produces the timeout lookalike instead.

How the lookalikes differ

  1. Connection refused: an immediate answer, nothing accepts on that port, or an explicit reject rule. Server-side problem.
  2. Connection timed out: no answer at all, packets dropped by a firewall or security group, a wrong IP, or a host that is down. Network-path problem.
  3. Permission denied (publickey): the connection succeeded and authentication failed; sshd is healthy, the problem is keys or users, a different page entirely.
  4. Host key verification failed: also a healthy sshd; the stored identity does not match, an identity problem, not a connectivity one.

Common questions

Why did it break right after I edited sshd_config? A syntax error or an invalid value stops sshd from starting on the next restart or reload, and the port goes silent. Validate before restarting with sshd -t and keep a console session open while changing SSH settings on a remote machine.

The port is open in the cloud panel but still refused, why? Cloud rules govern the path to the host; the host still needs a listening sshd and its own firewall open. All three layers (cloud group, host firewall, daemon) must agree, and “refused” usually means the path is fine and the last layer said no.

Can a server refuse because of load or rate limiting? Yes, protection tools (fail2ban and sshd's own MaxStartups) can reject new connections after repeated failures or during floods. The server's auth log shows bans by address; waiting or allowlisting the client address is the remedy.

Related errors

Permission denied (publickey) · Host key verification failed · Java: Connection refused