Persistent SSH Error 'port 22: No route to host'

The error "No route to host" indicates a fundamental network layer failure where the operating system cannot find a path to the destination IP, typically due to incorrect routing tables, disabled interfaces, or physical connectivity loss. Unlike firewall blocks that return "Connection refused," this message means the packet was dropped before reaching the application port because the network stack rejected it entirely.

Distinguishing Network Errors from Firewall Blocks

It is critical to understand why your previous troubleshooting attempts may have failed by focusing on SSH configurations. A common misconception is that "No route to host" is caused by a firewall blocking port 22. This is technically incorrect. Firewalls that drop packets usually result in a timeout, while firewalls that actively reject connections send a TCP RST packet, resulting in "Connection refused." The "No route to host" error originates at the IP layer (Layer 3), not the transport layer (Layer 4). This distinction guides your diagnostic strategy. If you see "No route to host," you must investigate the network infrastructure, interface status, and routing logic. You should not waste time checking iptables rules or ufw statuses until you confirm basic reachability. For more context on general connection failures, see our guide on Troubleshooting SSH Connection Issues on Linux.

Verifying Physical and Link Layer Connectivity

Before diving into complex routing tables, verify that the local machine can actually send packets onto the network segment. Start by checking the status of your network interface using the ip link show command. Ensure the interface is in the UP state and has a valid MAC address assigned. If the interface is down, bring it up with sudo ip link set dev eth0 up, replacing eth0 with your actual interface name. Next, check for duplicate IP addresses or ARP failures. Use arping -I eth0 to send an Address Resolution Protocol request directly to the target. If this fails, the issue is likely on the local switch or cabling level. In virtualized environments, ensure the virtual NIC is connected to the correct virtual switch. See Connecting to Ubuntu using ssh over Ethernet for detailed steps on verifying Ethernet configuration stability.

Inspecting Routing Tables and Gateways

The core cause of this error is often an incomplete or incorrect routing table. Run ip route show to view the current routing configuration. Look for a default route (default via) pointing to a valid gateway. If the destination IP belongs to a different subnet, there must be a specific route entry for that network prefix. If the route is missing, add it temporarily with sudo ip route add / via . To make this persistent, you must edit your network configuration files, such as /etc/network/interfaces on Debian-based systems or the Netplan YAML files on Ubuntu 18.04+. Incorrect static routes are a frequent culprit when migrating servers between data centers or changing ISP providers.

Checking Subnet Masks

Ensure the subnet mask on your local machine matches the network topology. An incorrectly configured netmask can cause the kernel to believe the destination is on the local link when it is not, leading to ARP failures and subsequent routing errors. Verify the CIDR notation aligns with your router's configuration.

DNS and Hostname Resolution Issues

While "No route to host" is primarily an IP-layer issue, it can sometimes appear if DNS resolution returns an invalid or unreachable IP address. Always test connectivity using the raw IP address first: ssh user@. If this works but ssh user@hostname fails, the problem is DNS, not routing. Check your /etc/resolv.conf file for valid nameservers. Use nslookup or dig to verify that the hostname resolves to the correct public IP. If you are using internal DNS, ensure the server is reachable and responding. Misconfigured DNS caches can also lead to stale records pointing to decommissioned servers, triggering this error.

Firewall and SELinux Considerations

Although firewalls rarely cause "No route to host," they can interfere with routing decisions in specific scenarios. On Linux systems with SELinux enabled, certain policies might restrict network namespace changes or interface bindings, though this is uncommon for standard SSH traffic. Check SELinux logs with ausearch -m avc -ts recent if you suspect policy violations. For standard iptables or nftables, remember that a DROP rule causes timeouts, and a REJECT rule causes "Connection refused." If you have recently modified firewall rules, revert them to default ACCEPT states to isolate whether the firewall is contributing to the confusion. However, prioritize routing fixes first.

Testing with Alternative Protocols

Use ping and traceroute to diagnose the path. ping uses ICMP Echo Request. If ping fails with "Destination Host Unreachable," the issue is definitely local routing or ARP. If ping succeeds but SSH fails, the issue is strictly application-level. If you are connecting from Windows, ensure your SSH client (like OpenSSH for Windows) is using the correct network adapter. Virtual adapters created by Docker or WSL can sometimes intercept traffic intended for the host LAN. Disable unused adapters to prevent routing conflicts.

Frequently Asked Questions

Why does my SSH work via IP but fail via hostname?

This indicates a DNS resolution problem rather than a routing issue. Your system cannot translate the domain name to the correct IP address, or it resolves to an outdated address. Verify your DNS servers in /etc/resolv.conf and use nslookup to check for accurate records.

Can a misconfigured subnet mask cause "No route to host"?

Yes, if your subnet mask is too narrow, the kernel may think the destination is remote when it is local, or vice versa. This leads to incorrect ARP requests or routing lookups. Ensure your netmask matches the network segment's design exactly.

Is "No route to host" the same as "Connection timed out"?

No. "Timed out" means packets were sent but received no response, suggesting a firewall drop or distant network congestion. "No route to host" means the local OS immediately rejected the packet because it had no path to forward it, indicating a local configuration or physical failure.

How do I fix this error on a virtual machine?

Check the virtual network adapter settings in your hypervisor (VMware, VirtualBox, Hyper-V). Ensure the VM is attached to the correct virtual switch or NAT network. Restarting the virtual network service or re-assigning the adapter often restores the routing table.

Should I disable SELinux to fix this error?

Disabling SELinux is generally not recommended and rarely solves routing issues. Instead, check if specific SELinux booleans related to network access are disabled. Use getsebool -a | grep network to review relevant policies without turning off security features entirely.