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

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

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.

Verify that the hostname resolves to the correct IP address:

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:

# 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.

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

# 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.

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

# 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:

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

# RHEL/CentOS
sudo systemctl restart network

Confirm the target server is actually powered on and accessible:

# 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.

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

# 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.

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

ssh -vvv [email protected]

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.

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

# 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.