SSH: Connection Refused vs Timed Out, Wetin E Mean

Wetín "Connection refused" and "Connection timed out" mean for SSH

SSH connection wey dem refuse and SSH connection wey e time out na opposite failures, so fix for one no be fix for the other. Refused mean say your packet reach the server and the server kernel answer "nothing is listening here". Timed out mean say your packet no reach anybody wey fit answer, so your client wait and give up. Refused na service problem for the server. Timed out na path problem before the server.

Read the exact line wey your client print, because na the wording carry the whole diagnosis.

ssh: connect to host 203.0.113.10 port 22: Connection refused
ssh: connect to host 203.0.113.10 port 22: Connection timed out

Timing na the second clue. Refused dey come back immediately, around the time wey one round trip take. Timed out dey stay for many seconds before e print, because the client dey retransmit before e give up. macOS print Operation timed out for the same condition. If the protocol still new to you, how SSH dey work and wetin sshd dey do na the background wey this guide assume.

Why “Connection refused” na good news

Refused na TCP (transmission control protocol) reset. Your client dey send SYN packet go port 22. E cross internet, reach the server network stack, and kernel no find socket wey dey listen for that port, so e answer with RST (reset) packet. Your SSH client turn that RST into the words Connection refused.

That one packet wey return prove plenty things. The address correct. The host dey on and routing dey work. Nothing for the path silently dey discard traffic go that port, because something return from the far end. So every remaining suspect dey for the server itself.

• sshd no dey run, because e fail to start or dem never enable am.
• sshd dey listen on another port, usually after hardening change.
• sshd bind to one address, like ListenAddress 127.0.0.1, so na only the server itself fit reach am.
• Firewall set to reject instead of drop, so firewall send the RST on behalf of the host. The ufw reject action and an nftables rule wey end with reject with tcp reset both dey do this.

One more case look like these ones but e different: you type address wey belong to another live host. That host answer your SYN, no get SSH for port 22, and politely refuse you. Confirm the address before you spend one hour for the wrong server. If you know wetin listening port really be for Linux, the rest of this section go read faster.

How to fix Connection refused

You no fit fix this through SSH, because na SSH itself get problem. Open your provider web console or serial console, sign in there, then run these commands one after another.

systemctl status ssh
sudo ss -tlnp
sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

systemctl status ssh dey use the unit name for Ubuntu and Debian. For RHEL and im rebuilds like AlmaLinux, the unit na sshd. ss -tlnp dey list every TCP socket wey dey listening, together with the process wey own am, and na the correct source of truth: if no line mention sshd, nothing dey listen, no matter wetin the config file claim. sshd -T dey print the effective configuration after e merge every Include file. Na there forgotten port for /etc/ssh/sshd_config.d/ go show.

Read the address column well. 0.0.0.0:22 mean every IPv4 address for the machine. [::]:22 mean every IPv6 address. 127.0.0.1:22 mean loopback only, so every remote connection to am go dey refused while local ssh localhost dey work perfectly.

If nothing dey listen, start the service and read the failure message if e no start.

sudo sshd -t
sudo systemctl enable --now ssh
sudo journalctl -u ssh -n 50 --no-pager

sshd -t dey parse the configuration and print the file and line number of any bad directive without touching the running service. Run am before every restart, because rejected config make sshd exit when e start, and your next connection go dey refused.

The socket activation trap for Ubuntu

Ubuntu 24.04 get systemd socket unit for OpenSSH. Where dem enable that unit, systemd dey hold the listening port and start sshd for each connection, so Port 2222 inside sshd_config no dey change anything and the box still dey answer for the old port. Check which mode your own dey use before you edit anything.

systemctl is-enabled ssh.socket
systemctl status ssh.socket

If socket dey enabled, set the port for the socket unit instead of for sshd_config.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

The empty ListenStream= line dey required, because systemd list settings dey add to wetin already dey configured. If you leave am out, the server go listen for both ports. Apply the change with sudo systemctl daemon-reload and sudo systemctl restart ssh.socket, then confirm with sudo ss -tlnp say na the new port systemd dey hold. To move the port na normal step for SSH hardening for VPS, and na this step dey lock people out pass.

Wetin “Connection timed out” mean when nobody answer

Timeout na silence. Your client send one SYN, resend am several times for about one or two minutes, but e never receive any packet back. Nothing about the server don prove here, because no response from the server ever come back.

Silence na exactly wetin one DROP rule dey produce, and dropping na deliberate. Rejection go tell anybody wey dey scan say the host dey exist, so ufw and every cloud provider network firewall dey discard unwanted packets and send nothing back. Your timeout usually mean say firewall dey do im work for port wey you want make open.

• The address dey wrong: DNS record still dey point to server wey you rebuild, or typo carry you go address wey nobody dey use.
• The host no dey up: e fit dey powered off, or e dey halfway through reboot. Provider suspension because of billing go look the same from outside.
• Host firewall dey drop port 22, most times because ufw enable run before any allow rule exist.
• Provider firewall wey dey before the instance dey drop am, and operating system no ever see the packet at all.
• Your own network dey block outbound port 22, and this one common for office and hotel connections.

Run the test from the correct side of the connection

Na here be the mistake wey dey waste the most time. You no fit diagnose dropped packet from inside the box wey the packets no dey reach. If you fit log in to run the command, you for no get the problem. Every command for this section dey run for your own machine.

getent hosts vps.example.com
ssh -G vps.example.com | grep -Ei '^(hostname|port|user)'
ssh -vvv -o ConnectTimeout=10 user@vps.example.com
nc -vz -w 5 203.0.113.10 22

getent hosts shows the address wey your machine go really use. This fit catch stale DNS record within seconds. ssh -G prints the settings wey your client apply after e read ~/.ssh/config. So e fit catch old Host block wey dey quietly rewrite the hostname, port, or user. ssh -vvv shows how far the attempt reach. If the last line talk say e dey connect to the address, then e pause for long, na timeout. But if one line report the remote OpenSSH version, TCP don already succeed, and the real problem na authentication. For Windows, Test-NetConnection 203.0.113.10 -Port 22 for PowerShell dey replace nc.

Test the port, no be the host. Failed ping no prove anything, because many providers dey filter ICMP (internet control message protocol) for the edge. Successful ping no prove anything too, because e no tell you anything about port 22.

Then change the one variable wey no command fit change for you: your network. Try again from phone hotspot. If the hotspot connect and your desk network no connect, the block dey your side of the internet, or dem don ban your office address for the server.

Provider firewall wey you no fit see from server

Plenty VPS panels get network firewall, wey dem sometimes dey call security group or cloud firewall. E dey run upstream from your instance and e get im own rule list. ufw status for server no fit see am. Na why people dey often talk say, “but I don already allow port 22.” Open the panel and read that list before you change any rule for the box.

One command fit settle the matter, but you need console access. Start am for server, then try connect from your laptop while e dey run.

sudo tcpdump -ni any tcp port 22

If nothing show while your client dey try connect, the packets dey get discarded before dem reach operating system. This means say the problem dey with provider firewall or the route go the host. If SYN packets arrive but no reply comot, the drop dey local and na ufw or nftables cause am. That one test divide timeout problem into two, so e make sense to use console.

ufw ordering, IPv6, and ban wey you give yourself

The ufw ordering mistake dey lock out more people pass anything else for here. sudo ufw enable dey apply default policy of deny incoming immediately, so if SSH rule no dey, your current session go survive because of established state, while every new connection go time out. Allow first, then enable.

sudo ufw allow OpenSSH
sudo ufw status verbose

The OpenSSH application profile dey cover port 22 only. If you plan move SSH go 2222, the rule wey you need na sudo ufw allow 2222/tcp. Add am before you change the port, no be after. The wider rule set dey covered for ufw firewall basics for a VPS, and the safe ordering dey part of wetin to do for the first ten minutes on a new VPS.

IPv6 fit produce timeout wey go feel strange. If hostname get AAAA record, your client go try IPv6 first. So, if server IPv6 rules dey missing, connection go hang while normal IPv4 attempt dey work. Separate the two by hand.

ssh -4 user@vps.example.com
ssh -6 user@vps.example.com

If -4 connect and -6 no connect, the fix dey for server IPv6 rules. how to open the same port for IPv6 inside ufw explain the steps.

You fit don ban yourself too. fail2ban dey monitor authentication log and insert firewall rule against addresses wey fail repeatedly. Wrong key or script wey dey retry for background fit lock out one whole office address. Ban wey drop connection go look like timeout. Ban wey reject connection go return No route to host instead. From the console:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.24

Adding your own address to ignoreip na part of working fail2ban setup for Ubuntu 24.04.

Errors wey no be refused and e no time out

No route to host mean say ICMP unreachable message come back. Either your own machine no get route go that network, or something for the path answer with administrative rejection. Na this kind response iptables REJECT rule dey send.

Network is unreachable na your own machine dey talk. E no get route at all for that address family. Na the usual answer be this when hostname resolve only to IPv6 address for IPv4-only connection.

kex_exchange_identification: Connection closed by remote host mean say TCP connect, then server hang up before key exchange finish. The port open and sshd dey alive, so check server load, check MaxStartups, or check whether ban catch you while you dey connect.

Permission denied (publickey) mean say you reach authentication but fail there. The network dey okay and firewall dey okay, so nothing for this guide apply. Go fixing Permission denied (publickey) on SSH instead.

How to enter again, and how to prevent another lockout

Every serious VPS host dey give you console wey no depend on the guest network: na serial console, or browser-based VNC screen. This console na the recovery route for both branches of this guide, because e go still work when sshd stop and when firewall rule discard everything. Find am for the panel, sign in as root or your normal user, then run the checks above. If you never set root password, most panels fit reset one for you.

Where console no dey, use provider rescue mode as fallback. E go boot small recovery system and mount your disk, so you fit edit /etc/ssh/sshd_config or delete firewall rule offline, then reboot.

Two habits fit prevent the next lockout. Keep second SSH session open whenever you edit sshd or firewall, because that session go remain active through established state while you test fresh one. Also, set automatic undo before risky firewall change.

sudo systemd-run --unit=ufw-rollback --on-active=10min /usr/sbin/ufw disable
sudo systemctl stop ufw-rollback.timer

The first line schedule ufw to switch itself off after ten minutes. Apply your new rules, open new SSH session to confirm say dem work, then run the second line to cancel the rollback. If you lock yourself out instead, wait ten minutes and the firewall go stand down by itself. E go leave the box without filtering until you enable ufw again, so use this while you dey for the keyboard, no be as permanent arrangement.

The order wey you go follow

1. Read the error text, and notice how long e take before e show.
2. Refused: go console and check sudo ss -tlnp for listening socket, the port wey e dey use, and the address wey e bind to.
3. Timed out: from your own machine confirm the address first. Then check provider firewall for the panel, and after that check host firewall for the box.
4. If none of those strings show: TCP connection don already happen, so treat am as authentication or server-load matter, no be network matter.

FAQ

Why SSH dey talk say "Connection refused" when sshd dey run?

Because socket dey send the refusal, no be the service, and sshd wey dey run fit still refuse you. Open provider console and run sudo ss -tlnp. Socket for 127.0.0.1:22 go refuse every remote client, because e bind to loopback only. Socket for another port go still refuse everybody wey dey use 22. If systemd socket activation dey use, port go come from ssh.socket and no be sshd_config, so check systemctl is-enabled ssh.socket too. A ufw reject rule fit also return refusal on behalf of the host, so read sudo ufw status verbose before you conclude anything.

Why SSH dey time out when ufw don already allow port 22?

Because timeout mean say no answer come back, and ufw no be the only firewall for the path. Most VPS panels dey run network firewall in front of the instance, and operating system no dey see wetin that firewall drop. From console, run sudo tcpdump -ni any tcp port 22 and try connect from your laptop while e dey run. If no packets arrive, upstream for panel dey drop dem. If packets arrive but no reply comot, local firewall, either ufw or nftables, dey drop dem.

Failed ping mean say my VPS dey down?

No. Plenty providers dey filter ICMP for network edge, so server wey dey serve traffic normally fit ignore every ping wey you send. Successful ping no strong proof too, because e no tell you whether port 22 dey open. Test the port itself with nc -vz -w 5 203.0.113.10 22 from your own machine, or with Test-NetConnection 203.0.113.10 -Port 22 inside PowerShell for Windows.

I change SSH port and now nothing dey connect. Wetin go wrong?

Two ordering mistakes fit cause this. If firewall never get rule for the new port, attempts to the new port go time out while port 22 go refuse, so sudo ufw allow 2222/tcp suppose come before the port change, no be after am. If the box dey use systemd socket activation for SSH, Port 2222 inside sshd_config go get ignored and systemd go continue hold the old port, which you fit confirm with systemctl is-enabled ssh.socket. Recover through provider console, fix the one wey apply, then connect with ssh -p 2222 user@203.0.113.10 once sudo ss -tlnp show the new socket.