Fixing 'SSH: No Route to Host' Error [7 Reasons]

The "SSH: No route to host" error to be honest can occur n number of issues. There is no specific one solution which will work for all scenarios. So in this article I will walk you through the most possible reasons which can cause this error and the solution for respective cause.

 

1. Check Network Connectivity

The very first thing to be checked when getting an error "SSH: No route to host" would be network connectivity between client and server. There are a number of tools available at your disposal such as nc (netcat) is one of the most used tool:

nc -zvw2 [server-ip] 22

If nc command is not available then you will have to install it manually:

# On RHEL7 based distribution
sudo yum install epel-release
sudo yum install nc

# On RHEL8 based distribution
sudo yum install nc

# On Debian based distribution
sudo apt install netcat

If the nc command prints a failure message then that would mean the client is unable to communicate with server over provided port.

If you don't have access to install nc command, then you can use below command which doesn't require any additional tool to be installed:

timeout 4 bash -c "</dev/tcp/<server_ip_address>/<ssh_port>"

For example

timeout 4 bash -c "</dev/tcp/192.112.18.203/22"; echo $?

Check the exit status of this command using echo $?. If the output is non-zero then there is no connectivity.

Now again this can be due to several reasons such as server is down, firewall issue or actual network issue. In this section I will share some tools which can be used to debug network issue, I will explain other possible causes separately.

In Linux environment below are some of the commands which you can use to check the routing table for any route related issue:

ip route
route -n

To see where the packets stop when trying to reach the host:

traceroute [server-ip]
mtr [server-ip]

These tools show the path packets take to the destination. traceroute provides a hop-by-hop account, while mtr combines traceroute with ping for a more dynamic view.

 

2. Check SSHD Service and Configuration

How stupid would it look if you waste debugging this issue whole day and it turns out the SSHD service was not running on server or the SSHD configuration was blocking the incoming connection.

Validating this step would require access to server hosting SSHD service, now since you are unable to connect via SSH so you must need an alternate way of connecting the server such as VNC, or directly accessing the console, or if the server is a Kubernetes pod then you can use kubectl etc.

To avoid this try to connect to SSHD service within the server:

ssh -vvv user@127.0.0.1 -p 22

If this goes through then that would mean that SSHD service is working perfectly and it is also allowing 'user new SSH connections.

Or you can also use tools like netstat or ss command to check the list of listening ports. Look out for port 22 and make sure it is listening:

sudo netstat -ntlp | grep :22

Similarly using ss command:

ss -ntlp | grep :22

But if this doesn't work, then you should check the sshd service log files for more information such as sudo journalctl -u sshd or less /var/log/auth.log. You can also increase log verbosity on server by changing LogLevel to DEBUG3 and restarting sshd service.

systemctl status sshd

On some Linux distributions the service name can be different so you can list all systemd services and check for the service name.

Some of the important SSHD configuration option which you should recheck:

sudo sshd -T | egrep -i '^port|permitrootlogin|passwordauthentication|pubkeyauthentication|listenaddress'

The reason why you should use sshd -T instead of directly checking inside /etc/ssh/sshd_config is because many times we update the configuration file but miss to restart the service so the latest changes are not applied. The sshd -T command will show you the currently loaded changes.

 

3. Verify IP Address and Port

Connect to the server which hosts SSHD service and verify the ListenAddress and Port used by SSHD service.

sudo sshd -T | egrep -i '^port|^listenaddress'

If the ListenAddress is listening on 0.0.0.0 then there is nothing to worry about as that would mean SSHD is accepting connections on all available interfaces. But if it is restricted to listen on a specific IP Address or interface then it will accept incoming SSH connections only on tat specific IP or interface,

For example:

listenaddress 192.106.215.50:5022

In this case the SSHD service will accept incoming connection only on 192.106.215.50 IP Address over port 5022 and all other requests will be rejected.

 

4. Ping the Server Host

I honestly don't find this method too useful as in most production environments the ICMP packets are filtered at the firewall so this may or may not give you accurate results. But still this is one of the most easiest and convenient way of checking connectivity. ping cannot be used to check connectivity over a specific port and it will by default use ICMP protocol.

ping -c 4 [server_ip]

If you observe 100% packet drop in the summary of the command output then that does not necessarily means that there is an issue with the network, but may also mean that ICMP packet is not allowed on the server.

On Debian based systems where ufw (Uncomplicated Firewall) is used to manage firewalls, you can use below commands to determine if ICMP packets are getting dropped at firewall:

sudo ufw status verbose
sudo grep -Ri icmp /etc/ufw

Similarly you can check in firewalld which is used in RHEL based distributions:

sudo firewall-cmd --list-all
sudo firewall-cmd --list-icmp-blocks

 

5. Check for Firewall Settings

Now this can be one of the most possible causes for getting "SSH: No route to host" error i.e firewall is blocking incoming connections. So you must check the firewall on the server hosting the SSHD service. I will give some command examples to check and allow incoming connection on port 22 which is the default SSHD port, if you are using a different port then you can updete the command:

Using iptables:

# Viewing Current Rules
sudo iptables -L -v

# Checking for SSH Port
sudo iptables -L INPUT -v -n | grep 22

If you wish to temporarily remove all rules then you can follow below steps:

# Backup existing firewall rules
sudo iptables-save > /path/to/your_backup_file

# Flush the rules
sudo iptables -F

# Restore firewall rules
sudo iptables-restore < /path/to/your_backup_file

You can also allow port 22 in iptables:

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

Using UFW (Uncomplicated Firewall):

To allow SSH:

sudo ufw allow 22

Or you can temporarily disable UFW firewall service for testing:

sudo ufw disable

Once you are done with testing, you can re-enable using

sudo ufw enable

Using firewalld:

To allow incoming SSH connections:

sudo firewall-cmd --zone=public --add-service=ssh --permanent
sudo firewall-cmd --reload

To stop firewalld service temporarily for your testing:

sudo systemctl stop firewalld

Once you are done with your tests, re-start the firewalld service:

sudo systemctl start firewalld

 

6. Test connectivity on a random port number

To be sure you can open any random port on the server side and try to connect the same from your client using nc or timeout bash command as I have shared in the first step. This can also hint you if the problem is specific to port 22 or it is a genuine network issue. As if you are able to connect your server from the client on any other random port then you can stress more on checking why port 22 is blocked.

For example on the server side I will start listening on port 2020 using nc command:

nc -lv 2020

which should show something like:

Listening on 0.0.0.0 2020

You can verify that server is listening on port 2020 by using netstat command:

netstat -ntlp | grep :2020

Next from your client machine try to connect to this port using either telnet or nc or timeout bash command or any other tool as per perference:

nc -zvw2 <server_ip> 2020

If the connection goes through then you should something like this on server node:

Connection received on 10.10.1.10 33628

The port 33628 is the source port so don't get confused, the summary is that the client was able to communicate over port 2020 and if it still fails for port 22 then it would mean that the network issue between server and client is pretty much limited to port 22.

Tip: You may also need to check your firewall to make sure your server is allowing connection on port 2020.

 

7. Still facing error "SSH: No route to host" ?

If none of the above steps helped you resolve the issue then you may have to dig deeper into the network and routing layer. The "No route to host" error most likely indicates that your system is unable to find a path to the destination host's IP address. This is generally due to one or more of the following reasons:

• Network Connectivity Issues: There might be no physical connectivity, or there could be a problem with the network configuration that prevents your machine from finding a route to the target server.
• Firewall Rules: A firewall might be actively blocking traffic to the destination host or the SSH port (usually 22).
• Misconfigured Network Settings: Issues with the routing table or incorrect gateway settings can prevent your system from finding a route to the destination.

You can check the output of ssh -vvv user@host and observe at what stage the connection is failing and that can give you a hint to check next steps. The server log will not be helpful here as the connection will not even reach the server.

You may also wanna look your client SSH configuration file which may be adding some additional content to your connection and causing this error. The SSH configuration files are mostly available at /etc/ssh/ssh_config (notice ssh_config is client config and sshd_config is server config) or ~/.ssh/config.

You can also place your error in the comment box and I can take a look and try to help you get over the situation.