Fix SSH No Route to Host Error (2026)

The SSH client failed to establish a network connection to the SSH server because it couldn’t find a path through the network to reach the server’s IP address.

Common Causes and Fixes

1. Incorrect IP Address or Hostname:

• Diagnosis: On the client machine, run ping <server_ip_or_hostname>. If this fails with "unknown host" or "network unreachable," the IP/hostname is likely wrong or unresolvable.
• Fix: Double-check the IP address or hostname for typos. If using a hostname, ensure it’s correctly configured in your DNS or /etc/hosts file. For example, if the IP is 192.168.1.100, ensure you’re not typing 192.168.1.10.
• Why it works: The ping utility sends ICMP echo requests to the target. If the target address is invalid or unresolvable, the request never leaves your local network segment or is dropped by a DNS resolver, indicating a fundamental addressing issue.

2. Server is Down or Unreachable:

• Diagnosis: From a machine on the same local network as the SSH server, try ping <server_ip>. If this fails, the server is likely offline or has a network interface issue.
• Fix: Ensure the server is powered on and its network cable is connected. Check the server’s network interface status using ip addr show or ifconfig on the server itself.
• Why it works: If even a local ping fails, the server is either not broadcasting an IP address, its network interface is down, or the physical connection is severed. The problem lies with the server’s network availability, not the client’s routing.

3. Firewall Blocking SSH Traffic:

• Diagnosis: On the client machine, use nc -vz <server_ip> 22. If it returns "Connection refused" or times out after a short while, a firewall might be blocking port 22. On the server, check sudo ufw status (for UFW) or sudo firewall-cmd --list-all (for firewalld).
• Fix: If using UFW, allow port 22: sudo ufw allow 22/tcp. If using firewalld, add the SSH service: sudo firewall-cmd --permanent --add-service=ssh followed by sudo firewall-cmd --reload.
• Why it works: Firewalls act as gatekeepers. If port 22 (the default for SSH) is not explicitly allowed by a firewall on the server or an intermediate network device, incoming connection attempts to that port will be silently dropped or rejected.

4. Incorrect Network Routing:

• Diagnosis: From the client machine, run traceroute <server_ip> or mtr <server_ip>. Look for where the hops stop or show asterisks (* * *). If the last successful hop is your local router and then nothing, your network doesn’t know how to reach the server’s subnet.
• Fix: This usually requires configuration on your router or gateway. Ensure a static route is added if the server is on a different subnet that your router doesn’t automatically know how to reach. For example, if your client is on 192.168.1.0/24 and the server is on 10.0.0.0/24, your router (gateway for 192.168.1.0/24) needs a route pointing to 10.0.0.0/24 via the correct next-hop router.
• Why it works: traceroute maps the path packets take. If it stops before reaching the destination, it means a router along the path doesn’t have a configured route to forward the packets to the next segment of the network where the destination resides.

5. Network Interface Configuration on Server:

• Diagnosis: On the server, check ip addr show. Ensure the network interface has a valid IP address assigned and that the interface is in an "UP" state.
• Fix: If the interface is down, bring it up: sudo ip link set <interface_name> up. If no IP is assigned, configure it statically (e.g., sudo ip addr add 192.168.1.100/24 dev eth0) or ensure your DHCP client is running and successful.
• Why it works: The server’s network interface must be active and possess a valid IP address within a reachable network segment for any traffic to be sent or received.

6. Subnet Mask Mismatch:

• Diagnosis: On both the client and server, check their respective subnet masks (ip addr show or ifconfig). If the client and server are on different logical subnets but have identical subnet masks, or vice-versa, routing might fail.
• Fix: Ensure the subnet masks are consistent with the network design. For example, if your network uses 192.168.1.0 with a 255.255.255.0 mask, both machines should have IPs in that range and that mask (e.g., client 192.168.1.50/24, server 192.168.1.100/24).
• Why it works: The subnet mask defines the network portion of an IP address. If it’s incorrect, a host might incorrectly believe another host is on its local network when it’s not, leading to attempts to send traffic directly instead of via a router, or vice-versa.

7. DNS Resolution Issues (Client Side):

• Diagnosis: If you’re using a hostname, try dig <server_hostname> or nslookup <server_hostname>. If this fails to return an IP address, your client cannot resolve the name.
• Fix: Check your client’s DNS settings in /etc/resolv.conf. Ensure the listed DNS servers are correct and reachable. Try ping <dns_server_ip> for each listed server.
• Why it works: When you use a hostname, your system first queries a DNS server to translate that name into an IP address. If DNS resolution fails, your SSH client never gets the IP it needs to even attempt a connection.

The next error you’ll likely encounter if all these are fixed is Connection refused, indicating that the server is reachable but the SSH daemon (sshd) isn’t running or is not listening on the expected port.