Fix "ssh: connect to host ... port 22: Connection timed out"

ping -c 3 203.0.113.10
nc -vz -w 5 203.0.113.10 22
# on the server, if ping works but the port does not:
sudo ufw allow OpenSSH                                   # Ubuntu / Debian
sudo firewall-cmd --permanent --add-service=ssh && sudo firewall-cmd --reload   # Fedora / openSUSE

Typical forms of the message:

ssh: connect to host 203.0.113.10 port 22: Connection timed out
ssh: connect to host server.example.com port 2222: Connection timed out
ssh: connect to host 203.0.113.10 port 22: Operation timed out      # macOS / BSD clients

What the error means

Your client sent a TCP SYN to the port and heard nothing back before the timeout (around two minutes on Linux by default). No reply is the key clue. A server that is up but has no SSH daemon answers with a reset, which gives Connection refused. A router that knows the host is unreachable sends an ICMP error, which gives No route to host. A missing route on your own machine gives Network is unreachable instantly. Timed out means packets disappear somewhere, most often in a firewall that drops instead of rejecting.

Work through the path from your side to the server. Each step below rules out one layer.

Cause 1: wrong address or the host is down

Check that the name resolves to the address you expect and that the machine answers at all:

getent hosts server.example.com
ping -c 3 203.0.113.10

Common mistakes: an old DNS record after a server move, a VPS whose public IP changed after a rebuild, a home server whose DHCP address changed, or a private address (192.168.x.x, 10.x.x.x) used from outside that network. Private addresses are only reachable from the same LAN or over a VPN. If the machine is a VM or a cloud instance, check its console or the provider's panel to see whether it is running and has finished booting.

Some hosts block ping, so a failed ping alone does not prove the host is down. Move on to the port test.

Cause 2: a firewall drops port 22

If ping works but the port test hangs, the port is being filtered. Test it explicitly:

nc -vz -w 5 203.0.113.10 22

Example output:

nc: connect to 203.0.113.10 port 22 (tcp) timed out: Operation now in progress

With console access to the server, check its firewall. ufw's default incoming policy is "deny", which drops packets silently, so a fresh ufw enable without an SSH rule produces exactly this error:

# Ubuntu, Debian, Mint
sudo ufw status verbose
sudo ufw allow OpenSSH
# Fedora, openSUSE (firewalld)
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
# any distro with raw nftables
sudo nft list ruleset | grep -n -i -E 'drop|22'

If sshd listens on a custom port, open that port instead (sudo ufw allow 2222/tcp or --add-port=2222/tcp). On Fedora with SELinux the port also needs sudo semanage port -a -t ssh_port_t -p tcp 2222. Our firewall guide covers both tools in detail.

Also check fail2ban or sshguard: a ban often uses a DROP rule, so your IP gets timeouts while others connect fine. sudo fail2ban-client status sshd lists banned addresses.

Cause 3: cloud security groups and provider firewalls

On AWS, Azure, Google Cloud, Oracle Cloud, Hetzner and most VPS providers, a network firewall sits in front of the instance. If it has no rule for TCP 22 from your address, packets are dropped before they reach the machine, and nothing you change inside Linux helps. Add an inbound rule for TCP 22 (or your custom port), ideally limited to your own IP range. Remember that your home IP may have changed since you created a "my IP only" rule.

Cause 4: NAT, port forwarding and VMs

To reach a machine behind a home router from outside, the router must forward an external port to the machine's LAN address and port 22. If the forward is missing or points at an old LAN IP, connections time out. Give the server a fixed address (see setting a static IP) and update the forward.

For VMs: with VirtualBox or libvirt NAT networking the guest is not reachable on its own address from the host. Either add a port forward (host 2222 to guest 22) and connect with ssh -p 2222 [email protected], or switch the VM to a bridged or host-only network.

Some ISPs and guest Wi-Fi networks block outgoing or incoming port 22. If the same server works from another network, try a different port on the server or connect through a VPN.

Cause 5: routing, VPN and IPv6 problems

A VPN can send traffic for the server's subnet into the tunnel, where it is dropped. Check which route the kernel picks:

ip route get 203.0.113.10

If the output names the VPN interface (tun0, wg0) and the server is not behind that VPN, disconnect it or fix its routes. When a host name has both IPv4 and IPv6 addresses and IPv6 is broken on either side, ssh can hang on the IPv6 attempt. Force IPv4 to test:

ssh -4 [email protected]

To find where packets stop, a TCP traceroute to the SSH port is more useful than plain traceroute (it may need to be installed, and -T needs root):

sudo traceroute -T -p 22 203.0.113.10

Distro notes

• Ubuntu, Debian, Mint: ufw is installed on Ubuntu but inactive until you run ufw enable; Debian does not install a firewall by default. Ubuntu Server images in some clouds ship provider-specific iptables rules, so check sudo iptables -S and sudo nft list ruleset even when ufw is inactive.
• Fedora: firewalld is active by default. Workstation's default zone allows SSH, but Fedora Server and other zones may not; check with firewall-cmd --get-active-zones.
• openSUSE Leap 16 and Tumbleweed: firewalld is enabled by default and the ssh service is not always open; the installer has an option for it.
• Arch: no firewall is active unless you set one up, so drops usually come from elsewhere on the path.

Still not working? Watch the server side

With console access, check whether your packets reach the server at all:

sudo tcpdump -ni any tcp port 22

Then retry from the client. No packets at all means they are dropped before the server (cloud firewall, router, wrong IP). Incoming SYNs without replies mean a local firewall or a service not listening while the firewall drops other ports. If the TCP connection succeeds but you see Connection timed out during banner exchange, the network is fine and sshd itself is slow or overloaded: check sudo journalctl -u ssh (Debian/Ubuntu) or -u sshd (Fedora, Arch, openSUSE) and system load.

How to prevent it

• Before enabling a firewall on a remote machine, add the SSH rule first and keep your session open while you test a new one.
• Give servers fixed addresses or DNS names, and update port forwards when they change.
• Add ConnectTimeout 10 to your ~/.ssh/config so failures show quickly; see the SSH cheat sheet.
• Keep console or out-of-band access (provider web console, IPMI) for every remote server.

Frequently asked questions