Connection to host xxxxxxxxxx at port 22 connection timed out

The "Connection to host at port 22 connection timed out" error indicates that the SSH client cannot establish a TCP handshake with the remote server within the default timeout period. This is typically caused by firewall restrictions, incorrect IP configurations, or network routing issues rather than password authentication failures. Immediate troubleshooting should focus on verifying local connectivity and ensuring no intermediate firewalls are blocking port 22 traffic.

Understanding the Connection Timeout

When you attempt to connect via SSH using ssh user@host, your system sends a SYN packet to the target IP address on port 22. A successful connection requires a SYN-ACK response from the server. If this response does not arrive within a specific timeframe (usually 10-30 seconds depending on the OS), the client throws a "connection timed out" error. This differs significantly from a "Connection refused" error, which means the server is reachable but no service is listening on port 22. It also differs from an authentication failure, where the connection succeeds but the login is rejected. A timeout implies that the packets are either being dropped silently by a firewall, lost due to network congestion, or routed to a non-existent destination. Understanding this distinction is crucial because it directs your troubleshooting toward network infrastructure rather than user credentials.

Distinguishing Between Refused and Timed Out

Before diving into complex network diagnostics, verify the exact nature of the failure. If you receive "Connection refused," the issue is likely that the SSH daemon (sshd) is not running on the target machine, or it is bound to a different port. However, since you are experiencing a timeout, the network path exists but the traffic is being intercepted or blocked. Common culprits include corporate firewalls, ISP-level filtering, or misconfigured router rules.

Step-by-Step Troubleshooting Guide

Resolving this issue requires a systematic approach to isolate where the connection is breaking down. Follow these steps in order, moving from local checks to external network verification.

1. Verify Local Network Connectivity

First, ensure your local machine can reach the internet and other hosts. Open your terminal or command prompt and run a ping test against a reliable public DNS server, such as Google's 8.8.8.8.

ping 8.8.8.8

If this fails, your local network interface or router has a fundamental connectivity issue unrelated to SSH. If it succeeds, proceed to check if you can resolve the hostname correctly. Use nslookup or dig to verify that the domain name resolves to the correct IP address. Incorrect DNS resolution can lead to timeouts if the client attempts to connect to a stale or wrong IP.

2. Test Port Accessibility with Telnet or Netcat

Since SSH uses TCP port 22, you can test if the port is open without actually attempting an SSH login. This helps determine if the blockage is specific to the SSH protocol or general port access.

telnet host_ip 22
# or
nc -vz host_ip 22

If telnet connects and displays a banner (e.g., "SSH-2.0-OpenSSH"), the port is open and accessible. If it hangs and eventually times out, the port is blocked by a firewall or the service is not responding. Note that some modern systems may not have telnet installed; nc (netcat) is often available as a lighter alternative.

3. Check for Firewall Interference

Firewalls are the most common cause of port 22 timeouts. You must check two locations: your local machine’s outgoing firewall and any intermediate firewalls between you and the host. On Linux, check your local firewall rules using iptables or ufw:

sudo ufw status
# or
sudo iptables -L -n

Ensure that outgoing connections to port 22 are allowed. On Windows, check the Windows Defender Firewall settings to ensure outbound rules permit SSH traffic. If you are behind a corporate proxy or NAT device, contact your network administrator to confirm that port 22 is whitelisted. Many organizations block standard SSH ports to prevent unauthorized tunneling, requiring you to use an alternative port like 443 or 2222.

4. Verify Server-Side Configuration

If local checks pass, the issue may lie with the remote server. Ensure that the sshd service is active and listening on all interfaces (0.0.0.0) or the specific IP you are targeting. You can check this by accessing the server console directly or through another working connection method like VNC or physical access. Run the following command on the server:

sudo systemctl status sshd
sudo netstat -tlnp | grep :22

If sshd is not running, start it with sudo systemctl start sshd. If it is running but only listening on IPv6 while you are trying to connect via IPv4, you will experience a timeout. Adjust the ListenAddress directive in /etc/ssh/sshd_config accordingly.

Advanced Diagnostics

If the standard steps do not resolve the issue, deeper network analysis is required. Use traceroute (or tracert on Windows) to identify where packets are dropping.

traceroute host_ip

Look for the hop where the response stops or shows asterisks (*). This indicates the point of failure. If the trace reaches the destination IP but still times out during SSH, the problem is likely an application-layer filter or a strict stateful firewall rule on the destination host. In cloud environments (AWS, Azure, GCP), verify that the Security Group or Firewall Rule associated with the instance allows inbound traffic on port 22 from your specific IP address range. Allowing traffic from 0.0.0.0/0 is insecure; instead, specify your home or office IP. For wireless networking issues, intermittent connectivity can also manifest as timeouts. If you are on Wi-Fi, try switching to a wired Ethernet connection to rule out signal interference. Additionally, check if your ISP is implementing deep packet inspection that might be disrupting long-lived TCP connections. In rare cases, MTU (Maximum Transmission Unit) mismatches can cause silent packet drops. You can test this by pinging the host with a specific packet size:

ping -s 1472 host_ip

If large packets fail but small ones succeed, adjust the MTU on your network interface. For more insights on related networking quirks, see our guide on Troubleshooting Networking and Wireless Issues in Google Chrome, which covers similar packet fragmentation and connectivity problems.

Alternative Connection Methods

If port 22 remains inaccessible due to rigid network policies, consider using SSH over HTTPS. Some proxies allow HTTPS traffic (port 443) while blocking SSH. Tools like stunnel or configuring your SSH client to use a proxy can bypass these restrictions. Alternatively, use a reverse tunnel or a VPN service to route your traffic through an allowed channel.

Frequently Asked Questions

Why does SSH time out but ping works?

Ping uses ICMP protocol, which is often treated differently by firewalls than TCP traffic. A firewall may allow ICMP echo requests for basic diagnostics while silently dropping TCP packets on port 22 to prevent unauthorized remote access. Always verify port accessibility separately from general connectivity.

Can I change the SSH port to avoid timeouts?

Yes, you can configure the SSH server to listen on a different port, such as 2222 or 443. On the client side, you would then use ssh -p 2222 user@host. This is useful if your network blocks standard port 22 but allows other high-numbered ports for services like web traffic.

What causes random SSH timeouts on Wi-Fi?

Wi-Fi networks are prone to interference, signal loss, and roaming issues that can interrupt TCP sessions. If your device switches access points or experiences significant signal degradation, the SSH connection may drop. Switching to a wired connection or ensuring stable Wi-Fi signal strength can mitigate this.

How do I fix timeouts when connecting to a cloud server?

Cloud providers use virtual firewalls called Security Groups or Network ACLs. Ensure that your instance’s security group explicitly allows inbound TCP traffic on port 22 from your current public IP address. Incorrectly configured rules here are the most common cause of timeouts for new cloud deployments.

Is there a way to increase the SSH timeout duration?

You can modify the timeout in your SSH client configuration file (~/.ssh/config) by adding ServerAliveInterval 60 and ServerAliveCountMax 3. This sends keep-alive messages every 60 seconds, helping maintain the connection through idle periods or lenient firewalls, though it won’t fix a hard block.