What causes "ssh: connect to host hostname port 22: No route to host"?

Firewall (local iptables, ufw, or network firewall) blocking the connection path Target host is offline, powered down, or crashed Incorrect IP address or hostname does not resolve correctly

Is the "ssh: connect to host hostname port 22: No route to host" error serious?

Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

How to fix ssh: connect to host hostname port 22: No route to host in SSH

SSHINTERMEDIATEHIGHUpdated Jan 4, 2026· 278 views

This error indicates the SSH client cannot establish a network path to the remote host. It typically means the target server is unreachable due to network connectivity issues, firewall blocks, routing problems, or the host being offline.

Quick fix

Fixes ssh: connect to host hostname port 22: No route to host

ping -c 4 hostname.example.com
# or ping the IP directly
ping -c 4 192.168.1.100

Verify basic network connectivity with ping
Check DNS resolution
Check local firewall rules
Verify network interface and routing

ssh — error

$ping -c 4 hostname.example.com
# or ping the IP directly
ping -c 4 192.168.1.100
ssh: connect to host hostname port 22: No route to host

What this error means

The "No route to host" error occurs when the operating system's network stack cannot find a valid route to reach the destination IP address. Unlike "Connection refused" (which means the host is reachable but rejected the connection), "No route to host" means the networking layer cannot even reach the target machine. This can happen at various points in the network path: your local machine, intermediate routers, firewalls, or network configuration issues.

Typical symptoms

SSH connection fails immediately with 'No route to host' message
Connection attempt takes several seconds before failing (timeout)
Manual ping to the same host also fails with similar error
Works from other networks or machines but not from your current location
Works with direct IP but not with hostname (or vice versa)
Error occurs even with verbose output (-vvv) showing it fails at connection stage

Common causes

Firewall (local iptables, ufw, or network firewall) blocking the connection path
Target host is offline, powered down, or crashed
Incorrect IP address or hostname does not resolve correctly
Network interface not properly configured (no gateway or route)
Host is on a different network segment without routing configured
VPN not connected or not routing traffic to the target network
DNS resolution failure causing inability to find target host
Network cable disconnected or wireless connection dropped
ISP or network provider blocking outbound traffic to that destination
Cloud security group (AWS) or network ACL not allowing traffic

How to fix "ssh: connect to host hostname port 22: No route to host"

1Verify basic network connectivity with ping

First, confirm if the target host is reachable at the network level:

bash

ping -c 4 hostname.example.com
# or ping the IP directly
ping -c 4 192.168.1.100

If ping fails with "No route to host" or "Destination unreachable", the problem is at the network layer, not SSH-specific. If ping succeeds, the issue may be SSH-specific (see next steps). If the hostname doesn't resolve, try the IP address directly.

2Check DNS resolution

Verify that the hostname resolves to the correct IP address:

bash

nslookup hostname.example.com
# or
dig hostname.example.com
# or
getent hosts hostname.example.com

If the hostname doesn't resolve or resolves to an unexpected IP, update your DNS settings or /etc/hosts:

bash

# Add entry to /etc/hosts if DNS isn't working
echo "192.168.1.100 hostname.example.com" | sudo tee -a /etc/hosts

Try SSH again with the corrected hostname or by using the IP address directly.

3Check local firewall rules

On your local machine, verify that outbound traffic to port 22 is not blocked:

bash

# Check UFW status (Ubuntu/Debian)
sudo ufw status
sudo ufw allow out 22/tcp

# Check iptables (generic Linux)
sudo iptables -L -n | grep 22
sudo iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT

# Check macOS firewall
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate

If you see blocking rules, adjust them to allow SSH traffic (port 22) to your target host.

4Verify network interface and routing

Check if your network interface is configured and has proper routing:

bash

# View all network interfaces
ip addr
# or
ifconfig

# Check routing table
ip route
# or
route -n

# Verify default gateway is set
ip route | grep default

If you see "UNKNOWN" state or no default route, your network interface may not be properly configured. Restart networking:

bash

# Ubuntu/Debian
sudo systemctl restart networking
# or
sudo systemctl restart systemd-networkd

# RHEL/CentOS
sudo systemctl restart network

5Verify target host is online

Confirm the target server is actually powered on and accessible:

bash

# Ping the target
ping -c 4 192.168.1.100

# Try telnet to port 22 (if available)
telnet 192.168.1.100 22

# Try netcat
nc -zv 192.168.1.100 22

If all connectivity tests fail, the host may be offline. Check with the host administrator or try connecting later. If it's a cloud instance (AWS, GCP, Azure), verify it's running in the console.

6Check remote firewall (if you have access)

If you have access to the target server or its firewall settings, verify SSH port 22 is open:

bash

# On the target server, check if SSH daemon is listening
sudo netstat -tlnp | grep 22
# or
sudo ss -tlnp | grep 22

# Allow SSH through firewall
sudo ufw allow 22/tcp
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

# Restart SSH service if needed
sudo systemctl restart sshd

Ensure SSH is enabled and firewall allows incoming port 22 traffic.

7Test SSH with verbose output to diagnose further

If basic connectivity works but SSH still fails, use verbose mode to see where it breaks:

bash

ssh -vvv user@hostname.example.com

The output will show exactly which stage fails. Look for lines showing:
- "Trying [IP]" - where it's attempting to connect
- "Connected to [IP]" - if it gets past routing
- "Authentications that can continue: publickey, password" - if it reaches SSH protocol stage

If it hangs at "Trying" stage, routing is the problem. If it connects but fails authentication, move to the authentication troubleshooting steps.

8Test if VPN or proxy is needed

If the target host is on a private network, you may need VPN access:

bash

# Check if VPN is active
ip route | grep -i vpn
# or check VPN status (depends on VPN client)
ifconfig | grep -i vpn

# Verify local network routes
ip route show

If the target is on a private network (10.x.x.x, 172.16.x.x, 192.168.x.x), you likely need:
- VPN connection
- Bastion/jump host
- SSH tunnel through an intermediate server

Connect to the VPN first, then attempt SSH again.

Advanced notes

Advanced troubleshooting:

Routing via traceroute: If you suspect routing problems, use traceroute hostname to see where the connection fails. This shows each hop to the destination and can reveal where the path breaks.

IPv6 vs IPv4: Some systems have both IPv4 and IPv6 configured. If hostname resolves to IPv6 but your network doesn't support it, SSH will fail. Try ssh -4 user@hostname to force IPv4 only.

Cloud Security Groups: AWS, GCP, and Azure have security group/firewall layers separate from the OS firewall. Check:
- AWS EC2: Security Group inbound rules must allow port 22
- Azure NSG: Inbound rule for SSH must allow source IP or range
- GCP: Firewall rule must allow ingress on TCP 22

Kubernetes/Containers: If connecting to Kubernetes pods or containers, you may need to use kubectl port-forward instead of direct SSH.

SSH through Jump Host: If direct connection isn't possible, use SSH jump hosts:

bash

ssh -J bastion@jump-host.com user@target.example.com

Debug at kernel level: For very stubborn issues, enable kernel-level packet capture:

bash

sudo tcpdump -i any -n 'tcp port 22'

This shows if packets are even reaching your interface.

Frequently asked questions

What does "ssh: connect to host hostname port 22: No route to host" mean?: The "No route to host" error occurs when the operating system's network stack cannot find a valid route to reach the destination IP address. Unlike "Connection refused" (which means the host is reachable but rejected the connection), "No route to host" means the networking layer cannot even reach the target machine. This can happen at various points in the network path: your local machine, intermediate routers, firewalls, or network configuration issues.
How do I fix "ssh: connect to host hostname port 22: No route to host"?: This error indicates the SSH client cannot establish a network path to the remote host. It typically means the target server is unreachable due to network connectivity issues, firewall blocks, routing problems, or the host being offline.
What causes "ssh: connect to host hostname port 22: No route to host"?: Firewall (local iptables, ufw, or network firewall) blocking the connection path Target host is offline, powered down, or crashed Incorrect IP address or hostname does not resolve correctly
Is the "ssh: connect to host hostname port 22: No route to host" error serious?: Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading

📚SSH Official Documentation
📖
TecMint: Fix 'No route to host' SSH Error in Linux(Official Docs)
HowToUseLinux: SSH Connect to Host Port 22 - No Route to Host
📖
Linux man pages: ip-route(8) - routing table manipulation(Official Docs)
📖
Linux man pages: route(8) - show/manipulate the IP routing table(Official Docs)

How to fix ssh: connect to host hostname port 22: No route to host in SSH

Quick fix

What this error means

Typical symptoms

Common causes

How to fix "ssh: connect to host hostname port 22: No route to host"

Advanced notes

Frequently asked questions

Related errors

Official resources & further reading