SSH Connection Refused Means the Host Is Alive: Six Causes and the Ten-Minute Fix

"Connection refused" is the best error message SSH can give you, and almost nobody treats it that way: a refusal arrives in milliseconds because the remote host's kernel personally answered your SYN with a TCP reset (RST), which proves three things at once — the host is up, the network path works, and the IP address is correct — and narrows the entire failure to a single question: why is nothing listening on that port? That question has exactly six answers on a Linux cloud server, and this article is the procedure for identifying which one you have and fixing it in under ten minutes.

The redefinition that makes the fix fast: an SSH "connection refused" is a service-layer problem, not a network problem. The working principle that experienced operators use is "refused means check the service, timeout means check the network" — a timeout means your SYN packet was silently dropped somewhere in transit (a security group, a firewall DROP rule, a routing black hole), while a refusal means the packet completed a full round trip and received an explicit "no" from the destination. Everything about the two errors' diagnosis follows from that distinction, and conflating them is the single most common way teams waste an afternoon opening the wrong firewall for a problem that lives inside the server.

What follows is the working method: how to read the refused message and what the RST packet proves; the refused-versus-timeout triage that prevents the wrong debugging path; the six causes of SSH connection refused in order of statistical likelihood, each with its one-command check; the ten-minute diagnostic sequence that localizes the cause; the exact fix commands for each cause, including the Ubuntu socket-activation and drop-in-config traps that make port changes silently fail; the lockout-safe procedure for editing sshd configuration without losing console access; the pre-flight checklist that prevents the error on a fresh server; and the seven questions people actually ask when SSH says no.

What "Connection Refused" Actually Tells You

The direct answer: "connection refused" means your SYN packet reached the target host and the host's kernel replied with an RST reset packet because no socket was bound to the address and port you dialed — the host is alive, the route works, and the only defect is that no process is listening where you knocked, which is a service problem you can fix from the console in minutes.

The mechanics are worth thirty seconds because they power every diagnosis that follows. A TCP connect to port 22 sends a SYN. Three things can happen. If a socket is bound to that address and port, the kernel replies SYN-ACK and the handshake proceeds. If the SYN arrives at a host where no socket is bound to that address-and-port pair, the kernel itself generates an RST — no application is involved, because there is no application to involve — and your client reports "connection refused" within milliseconds. If the SYN is silently discarded anywhere along the path, nothing comes back at all, your client retries with exponential backoff, and roughly two minutes later you get "connection timed out" instead. The refusal is fast, explicit, and informative; the timeout is slow, silent, and ambiguous. That asymmetry is the entire basis of the triage in the next section.

One habit converts this table from theory into practice: when the error appears, read the exact wording and note the elapsed time before touching anything. "Connection refused" after ten milliseconds and "connection timed out" after two minutes send you to entirely different checklists — the first to the service and its configuration, the second to firewalls and security groups. Teams that skip this step routinely spend an hour editing security-group rules for a server whose sshd was never installed, which is the most common cause of all and the next stop.

Refused vs Timed Out: Read the Error Before You Debug

The direct answer: the two errors have almost disjoint cause sets — refusal means the service layer (sshd missing, dead, misconfigured, or on another port or address), timeout means the network layer (default-deny security groups, DROP rules, provider edge filters) — so the error text alone eliminates half the possible causes before you run a single command.

The layering matters because a cloud server sits behind two independent filters that behave differently. The cloud security group — the platform-level firewall in the provider console — almost always drops rather than rejects, so a security group blocking port 22 produces a timeout, not a refusal. The host firewall inside the OS (iptables, firewalld, ufw) can do either: a DROP rule produces a timeout, while a REJECT rule — specifically one using reject-with tcp-reset — produces a refusal indistinguishable from "no listener." This is why the diagnostic order for a refusal checks the service first and the host firewall's REJECT rules last, and why a refusal should almost never send you to the provider console's security-group page: a security group cannot produce the error you are looking at.

The practical payoff of this table: if you see "connection refused," you can skip the provider console entirely and work from the server's own console session, because every cause of a refusal lives inside the host or in the way you addressed it. That is what makes the ten-minute fix possible — the entire diagnosis runs on one machine.

The Six Causes of SSH Connection Refused

The direct answer: on a Linux cloud server, an SSH connection refused comes from exactly six causes — openssh-server was never installed, sshd failed to start, sshd is listening on a different port than you are dialing, sshd is bound to the wrong address, a REJECT rule or NAT device is actively resetting you, or you are connecting to the wrong IP or address family — and each has a one-command check.

The six causes, in the order of statistical likelihood for a typical cloud server:

Two patterns are worth internalizing before running the checks. On a freshly created server, causes 1, 2, and 4 dominate — the image never had the SSH server installed, or the service failed its first start, or it bound to loopback. On a server that worked and stopped after a change you made, causes 3 and 5 dominate — a port change that did not take effect the way you assumed, or a firewall hardening step that added a REJECT. The ten-minute sequence in the next section walks the list in exactly that order.

The Ten-Minute Diagnostic Sequence

The direct answer: run five checks in order — confirm the refusal from outside, check the service status, check the listener and its bound address, check the effective port configuration, and check for REJECT rules — and the first check that fails names your cause, with the whole sequence taking about ten minutes from the provider's web console.

The sequence, with each step's command and interpretation:

1. Confirm the failure mode from outside (1 minute). From your own machine: nc -zv -w 3 <server-ip> 22 (or telnet <server-ip> 22). The -w 3 caps the wait so a timeout costs you three seconds, not two minutes. "Refused" confirms you are on the right checklist; "timed out" means you have a network-layer problem instead — the security group or a DROP rule — and the rest of this sequence does not apply.
2. Check the service (1 minute). From the provider's web console or VNC — not SSH, which is the thing that is broken: systemctl status ssh (Debian/Ubuntu) or systemctl status sshd (RHEL family). You are looking for "active (running)" versus "inactive," "failed," or "not-found." Not-found on a fresh Ubuntu box is cause 1; failed is cause 2 and journalctl -u ssh -e will name the reason.
3. Check the listener and its address (2 minutes). ss -tlnp | grep sshd. Read two columns: the Local Address:Port and the process name. A healthy line reads 0.0.0.0:22 (all IPv4 interfaces) or *:22 (all interfaces, both families). 127.0.0.1:22 is cause 4 — the listener exists but only answers localhost. A port other than 22 is cause 3. No line at all loops back to step 2: the service is not running.
4. Check the effective configuration (3 minutes). sshd -T | grep -Ei 'port|listenaddress' dumps the effective configuration after all drop-ins and overrides — what sshd actually believes, not what your editor shows. If the port is not what /etc/ssh/sshd_config says it should be, a drop-in file in /etc/ssh/sshd_config.d/ or the systemd socket (covered in its own section below) is overriding you, and that is the fix target.
5. Check for REJECT rules (2 minutes). iptables -L INPUT -n -v --line-numbers and ufw status verbose. You are looking for the word REJECT on a line covering TCP port 22 — a REJECT with tcp-reset produces a refusal indistinguishable from a missing listener. If steps 2 through 4 were all clean, this is what you have; the fix is replacing the REJECT with an ACCEPT for the SSH port.

Why this order: each step is a precondition for the next one's meaning. There is no point reading listener state if the service is dead, no point reading the config if the listener is on the wrong address, and no point hunting REJECT rules if the listener is healthy and correctly bound — at which point, if you are still refused, the cause is almost certainly cause 6: the address you are dialing, which the final check in the FAQ's first question resolves in one command.

Cause 1: openssh-server Was Never Installed

The direct answer: the single most common cause of SSH connection refused on a fresh Linux server is that the SSH server package was never installed — Ubuntu desktop images, minimal images, and most container images ship without openssh-server by default — and the fix is apt install openssh-server followed by systemctl enable --now ssh, after which the refusal disappears.

The trap is that the client side is always present — every mainstream distribution ships the ssh client out of the box, so ssh localhost from the server itself can fail with the same refusal and mislead you into thinking "SSH is installed." The client and the server are separate packages: openssh-client (present) versus openssh-server (frequently absent). The check is one command: dpkg -l | grep openssh-server on Debian-family systems, rpm -q openssh-server on the RHEL family. Empty output is the diagnosis.

The fix, as an ordered list:

1. Install the package. sudo apt update && sudo apt install -y openssh-server (Debian/Ubuntu) or sudo dnf install -y openssh-server (RHEL family). On Debian-family systems the post-install script starts and enables the service automatically; verify rather than assume.
2. Verify the service. systemctl status ssh — expect "active (running)" and "enabled."
3. Verify the listener. ss -tlnp | grep sshd — expect 0.0.0.0:22.
4. Test from outside. Re-run the step-1 port test from your own machine. A refusal that becomes a password or key prompt is closed; a refusal that becomes a timeout means the install fixed the service and exposed a network-layer block — the security group — which is the other checklist.

One cloud-specific note: on images that do ship the server, the first-boot process normally starts it — so a "not-found" result on a cloud image usually means the image was minimal or container-oriented by design, not that anything is broken. If you build custom images, adding openssh-server to the base image is the permanent fix; if you rent servers where SSH should be there and is not, that is a fact about the image catalog worth knowing before the next server.

Cause 2: sshd Failed to Start — Config Errors and Missing Host Keys

The direct answer: when sshd is installed but the service shows "failed" or "inactive," the two usual reasons are a syntax error in the SSH configuration — caught before launch by sshd -t, which prints the exact line — or missing host keys, fixed by ssh-keygen -A — and in both cases journalctl -u ssh -e names the reason in plain text.

The procedure when the service is not running:

1. Read the logs first. sudo journalctl -u ssh -e (or sshd on the RHEL family). The last lines before the failure almost always contain the exact reason: a bad directive, a file permission complaint, or a missing host key. Diagnosing from the log beats guessing from memory.
2. Test the config. sudo sshd -t. A clean run prints nothing and exits zero; a broken config prints the file, line number, and the offending directive. This command is also your pre-flight check before every restart — it is the difference between "reloaded" and "locked out."
3. Regenerate host keys if missing. An image built without host keys produces "sshd: no hostkeys available — exiting" in the log. sudo ssh-keygen -A generates the full default set into /etc/ssh/, after which the service starts normally.
4. Start and enable. sudo systemctl enable --now ssh, then re-verify with systemctl status ssh and ss -tlnp | grep sshd.

The recurring theme worth adopting as a rule: never restart sshd without running sshd -t first. The test is instantaneous, it catches typos in directives and values before they become an outage, and it is the habit that separates a planned change from an unplanned trip to the web console. The same discipline powers the lockout-safe procedure near the end of this article.

Cause 3: The Port Changed Without You — Drop-ins and Socket Activation

The direct answer: if sshd is running but ss -tlnp shows a port other than 22, the usual culprits are a drop-in file in /etc/ssh/sshd_config.d/ overriding your Port directive — cloud-init's 50-cloud-init.conf is the classic — or, on Ubuntu 22.10 and later, systemd socket activation, where ssh.socket's ListenStream owns the port and silently overrides sshd_config's Port — and sshd -T | grep -i port shows the effective value that actually governs.

The drop-in mechanism first. Modern OpenSSH reads every file matching /etc/ssh/sshd_config.d/*.conf before the main config, and for most directives the first value obtained wins — which means a Port directive in a drop-in file outranks the Port you edited in the main sshd_config. Cloud images frequently ship a 50-cloud-init.conf drop-in that sets Port, PasswordAuthentication, or both; you edit the main file, restart, and nothing changes, because your edit was never the effective configuration. The check: sudo grep -ri port /etc/ssh/sshd_config /etc/ssh/sshd_config.d/ — every file that mentions Port, side by side. The fix is editing or removing the drop-in, not re-editing the main file a third time.

Socket activation second, because it is the newer trap. On Ubuntu 22.10 and later, the SSH service is wired through systemd socket activation: ssh.socket binds port 22 and starts sshd on demand, which means the listening port is defined in the socket unit — ListenStream=22 — not in sshd_config. If you change Port in sshd_config and restart the service, the socket keeps listening on 22 and your new port never opens; connections to the new port are refused because nothing binds it. The check: systemctl cat ssh.socket. The fix is either editing the socket's ListenStream to match and running systemctl daemon-reload && systemctl restart ssh.socket ssh.service, or disabling the socket layer entirely (systemctl disable --now ssh.socket && systemctl enable --now ssh.service) so sshd_config owns the port again.

The general lesson from both traps: the effective configuration is the only configuration. sshd -T prints what sshd actually parsed, after drop-ins, includes, and defaults — and trusting it over the file in your editor will save you from an entire genre of "I changed it and nothing happened" incidents, the SSH-specific version of the same lesson that applies to checking CPU usage in Linux: measure the live system, not your assumptions about it.

Cause 4: sshd Is Bound to the Wrong Address

The direct answer: if ss -tlnp | grep sshd shows the listener on 127.0.0.1:22 instead of 0.0.0.0:22, sshd is answering only the loopback interface — every external connection to the public IP arrives, finds no socket on that address, and gets reset — and the fix is setting 0.0.0.0 (or removing a restrictive ListenAddress line) in the effective config, then restarting the service.

The signature symptom makes this cause self-identifying: SSH from the server to itself (ssh localhost) works perfectly while every external attempt is refused — the listener exists, the service is healthy, and it is simply bound to the wrong interface. The usual origins are a hardened image that shipped ListenAddress 127.0.0.1, a manual hardening edit that was never revisited, or an AddressFamily inet6 setting that binds only the IPv6 wildcard ::, which leaves IPv4 dialers refused. The address column of ss -tlnp distinguishes all of these at a glance: 0.0.0.0:22 is all IPv4 interfaces, [::]:22 is all interfaces on IPv6 (and, on most kernels, IPv4-mapped too), 127.0.0.1:22 is loopback-only, and a specific public IP is that interface only.

The fix, as an ordered list:

1. Find the directive's source. sudo grep -ri listenaddress /etc/ssh/sshd_config /etc/ssh/sshd_config.d/ — remember the drop-in directory outranks the main file for first-obtained values.
2. Set the wildcard bind. Edit the effective source to ListenAddress 0.0.0.0, or comment the line out entirely — with no ListenAddress, sshd binds all interfaces of the configured address family, which is the default and what you almost always want.
3. Test and restart. sudo sshd -t, then sudo systemctl restart ssh.
4. Verify the bind. ss -tlnp | grep sshd must now show 0.0.0.0:22 (or *:22), and the external port test should stop refusing.

Causes 5 and 6: REJECT Rules, NAT Devices, and the Wrong Address

The direct answer: the two remaining causes of a refusal are an active reset from a firewall REJECT rule with tcp-reset (or a NAT device or load balancer with no healthy backend) — visible in iptables -L INPUT -n -v — and dialing the wrong destination entirely: a stale DNS record, the wrong interface IP after an address change, or the wrong IP version, separated in one command each.

The REJECT case. Most firewall drops are silent (DROP, producing a timeout), but an explicit REJECT --reject-with tcp-reset rule answers your SYN with the same RST a closed port would send — a refusal with a listener present. The check is sudo iptables -L INPUT -n -v --line-numbers: scan for REJECT on a line matching TCP and port 22 (or your port). The fix is replacing the REJECT with an ACCEPT for the SSH port — sudo iptables -D INPUT <line-number> followed by sudo iptables -I INPUT -p tcp --dport 22 -j ACCEPT — and persisting the change the way your distribution does (netfilter-persistent save, or your rules file). The same active-reset behavior comes from infrastructure in front of the server: a load balancer with no healthy backend often refuses rather than times out, and a NAT port-forwarding rule pointing at a dead internal port does the same — if the server's own checks are all clean, look one hop out.

The wrong-address case, in three variants. Stale DNS: the hostname resolves to an old IP where some other host (or nothing) answers — dig +short <hostname> against the IP you intended exposes the mismatch; dial the IP directly to bypass DNS entirely. Wrong interface: after an IP change or a migration, the address in your SSH config or known_hosts workflow points at yesterday's address. Wrong family: the hostname has an AAAA record and your client silently prefers IPv6, but sshd is bound IPv4-only — ssh -4 user@host forces IPv4 and ssh -6 forces IPv6, and the one that works names the mismatch. All three variants share the same moral: before deep-diving the server, verify the destination is the destination.

The Lockout-Safe Fix Procedure

The direct answer: the safe way to change anything in SSH configuration is to open a second console session and keep it alive, run sshd -t before every restart, restart, verify the listener with ss -tlnp, and test a fresh external login before closing the console — four habits that make a self-inflicted lockout structurally impossible.

The procedure, as an ordered list:

1. Open the console session first. The provider's web console or VNC is your lifeline — it does not depend on sshd or on port 22. Open it before touching anything, and keep it open until the final step passes. If your change severs SSH, the live console is the way back in.
2. Test the configuration. sudo sshd -t. Fix anything it reports before proceeding — a config that fails the test will fail the restart, and a service that fails to restart is cause 2 from the top of this article.
3. Restart and verify the listener. sudo systemctl restart ssh, then ss -tlnp | grep sshd — confirm the port and the bind address are exactly what you intended, not what you assumed.
4. Test a fresh external login. From your own machine, open a new SSH session — not a re-used terminal with a cached connection. Only a fresh handshake exercises the full path you just changed.
5. Close the console last. When the fresh login succeeds, the change is verified end to end and the console can be closed. Any order short of this is hoping rather than verifying.

The same test-before-you-restart discipline generalizes beyond SSH: it is the working habit behind renewing Let's Encrypt certificates on nginx and Apache servers without an outage, where a config that fails the reload check takes down your site exactly the way a config that fails sshd -t takes away your shell. Verify first, restart second — on every service where the restart is the risk.

The same procedure applies to firewall changes with one addition: before editing any iptables rule that touches port 22, note the --line-numbers output so you can delete by number from the console if the edit goes wrong, and remember that an ACCEPT appended after a REJECT never executes — insert with -I, not append with -A, because iptables stops at the first match.

The Fresh-Server Pre-Flight Checklist

The direct answer: on every new Linux server, a five-minute pre-flight — install and enable openssh-server, verify the listener on 0.0.0.0:22, allow the port in the host firewall, allow it in the security group, and test a fresh external login — prevents every cause in this article before the first refusal can occur.

The checklist, in order:

1. Install and enable the service. sudo apt install -y openssh-server && sudo systemctl enable --now ssh — harmless if already present, decisive if absent.
2. Verify the listener. ss -tlnp | grep sshd — expect 0.0.0.0:22. This one line rules out causes 1, 2, 3, and 4 simultaneously.
3. Allow the port in the host firewall. sudo ufw allow 22/tcp (or your distribution's equivalent) — and if you run a non-standard port, allow that port, not 22.
4. Allow the port in the security group. In the provider console, an inbound TCP rule for port 22, scoped to your source IP (your.ip/32) rather than 0.0.0.0/0 — the security group produces timeouts, not refusals, but you will meet it the moment the service layer is clean.
5. Test a fresh external login. One real SSH handshake from your own machine, before the server carries any workload.
6. Harden, then re-test. Key-only authentication, no root password login, fail2ban if the logs show knocking — and after every hardening step, one more fresh login, because hardening is exactly when refusals are self-inflicted.

A note on the server itself, since the checklist's first step assumes one worth hardening: for lightweight workloads — a single service, a bot, a small site, a CI runner — a lightweight cloud server plan is usually the right shape, and entry pricing for a 1 vCPU / 2 GB / 40 GB NVMe instance with a dedicated IPv4 sits around $2.9 per month for new users as of October 2026 (renewing at $7.5/mo) on SurferCloud's ULightHost line, with Linux and Windows images both available. If your refusal happened on a server you were about to replace anyway, a fresh instance plus this checklist is often faster than archaeology on an old one — and if your workload is region-sensitive, the same catalog covers the common cases, including a Hong Kong VPS for reaching China and Southeast Asia markets where latency to both matters.

FAQ: Seven Questions People Actually Ask

"SSH says connection refused but I can ping the server — is it down?" No, and the combination is diagnostic gold: ping succeeding proves the host is up and the network path carries traffic, which is exactly what an RST already told you. The server is alive; port 22 simply has no listener. Work causes 1 through 4 — installed, running, right port, right address — and skip every network-layer check.

"Why does my friend connect fine but I get connection refused?" Different destination or different path. The two usual explanations: you are dialing different addresses (a stale DNS record on your side — compare dig +short outputs), or a REJECT rule scoped to a source range that covers you but not them. The one-command separator: both run nc -zv <same-ip> 22 against the identical IP — if the results differ, the difference is in the path or the rule, not the server.

"I changed the SSH port and now everything is refused — what happened?" One of the two override traps from cause 3: a drop-in file in /etc/ssh/sshd_config.d/ outranking your edit, or systemd socket activation (Ubuntu 22.10+) keeping ssh.socket on port 22 while your new port never opened. Run ss -tlnp | grep sshd to see the real port, then sshd -T | grep -i port and systemctl cat ssh.socket to find which layer owns it.

"Connection refused on port 22 but the website on port 80 works — how?" Easily, and it is the most common fresh-server pattern of all: the web server is installed and listening; the SSH server is not (or is misbound). Ports are independent services. The port-80 success proves host and network; the port-22 refusal indicts the SSH service layer alone — start at cause 1.

"ssh localhost works on the server but external SSH is refused — why?" That is cause 4's signature: sshd is bound to 127.0.0.1, so loopback connections find a listener while connections to the public IP find none and get reset. ss -tlnp | grep sshd will show 127.0.0.1:22; set ListenAddress 0.0.0.0 (or remove the directive), test with sshd -t, restart, verify.

"Does connection refused mean someone blocked or hacked me?" Almost never. A refusal is a routine, honest "nothing is listening here" from the kernel — the boring mechanical outcome of a missing or misbound listener, or occasionally a scoped REJECT rule. Blocks and drops produce timeouts, not refusals. Check the six causes before checking the logs for villains; in the overwhelming majority of cases the villain was a config edit.

"sshd isn't running and I can't SSH in — how do I fix a server I can't reach?" Through the provider's web console or VNC, which is precisely what it exists for: it attaches to the server's screen and keyboard over the provider's management network, entirely independent of sshd. From the console, the ten-minute sequence runs unchanged — status, listener, effective config, logs — and once the service is healthy again, SSH returns on its own.

The refusal, read correctly, is a gift: it is the one connection error that comes with a proof of life attached. The host answered you; the path carried your packet both ways; the address was right. All that remains is the service — and the service, unlike the internet, is entirely yours to fix.