The 'Network is unreachable' SSH error occurs when the client machine cannot establish a network route to the remote host. This typically results from missing network connectivity, incorrect routing configuration, firewall blocking, or the remote host being offline. Unlike connection refused errors, this indicates the network path itself is unavailable, not that the SSH service is unreachable.
The "Network is unreachable" error is a network-level error that occurs when your SSH client attempts to establish a TCP connection to the remote host but cannot find a valid network route. This error comes from the operating system's network stack, not from the SSH protocol itself. Key characteristics of this error: - **Network layer failure**: The problem is at the TCP/IP level, not SSH-specific - **No connection attempt**: The SSH protocol never starts; the TCP handshake fails - **IPv4 vs IPv6**: Can occur when trying to route to either IPv4 or IPv6 addresses - **Client-side issue**: The problem is with the client's network configuration, not the remote server This differs from other common SSH connection errors: - "Connection refused" means the server is reachable but SSH isn't accepting connections - "Connection timed out" means the route exists but the server isn't responding - "No route to host" is similar but more specifically indicates routing issues - "Network is unreachable" means the network interface or gateway is unavailable
First, confirm that your client machine has an active network connection:
# Check if you have network connectivity
ping 8.8.8.8 # Test internet
ping google.com # Test DNS and internet
# Check your network interfaces
ip addr show
# or on macOS
ifconfig
# Check you have a default gateway
ip route
# or
route -nIf you can't ping 8.8.8.8, your internet is down. If you see "No such file or directory" or missing default gateway, your network isn't properly configured.
Test whether the network path to the target host exists:
# Ping the target host using its IP address
ping -c 4 192.168.1.100
# Or use its hostname
ping -c 4 example.com
# Check if DNS resolves correctly
nslookup example.com
# or
dig example.comIf ping fails with "Network is unreachable", the network path doesn't exist. If ping works but SSH fails, continue to the next steps.
If the hostname doesn't resolve, use the IP address directly:
Some hosts may be on different network subnets with different routing requirements:
# View your routing table
ip route show
# or
route -n
# Check your network interface and IP
ip addr show
# For example, if you're on 192.168.1.0/24:
# - Hosts on 192.168.1.x are local (direct route)
# - Hosts on other networks need a gateway route
# - The default route (0.0.0.0/0) handles unknown networksIf the target IP is not in your local subnet and you have no default route, add one:
# Add default route (Linux - temporary)
sudo ip route add default via 192.168.1.1
# Or permanently on Debian/Ubuntu
# Edit /etc/network/interfaces or netplan config
# On RHEL/CentOS
# Edit /etc/sysconfig/network-scripts/ifcfg-eth0 and set GATEWAY=192.168.1.1Local firewall rules can block outbound SSH connections:
# Check UFW (Ubuntu)
sudo ufw status
sudo ufw status verbose
# Allow SSH if blocked
sudo ufw allow ssh
sudo ufw allow out 22/tcp
# Check firewalld (RHEL/CentOS)
sudo firewall-cmd --list-all
sudo firewall-cmd --add-service=ssh --permanent
sudo firewall-cmd --reload
# Check iptables rules
sudo iptables -L -n
sudo iptables -L -n | grep 22
# Temporarily disable firewall for testing (Linux)
sudo ufw disable # UFW
sudo systemctl stop firewalld # firewalld
# macOS firewall
# System Preferences > Security & Privacy > Firewall OptionsLook for rules that might block outbound port 22. If you find blocking rules, add an exception:
# Allow outbound SSH with iptables
sudo iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT
# Or with UFW
sudo ufw allow out 22/tcpIf using a hostname, try connecting directly to the IP address to rule out DNS issues:
# Convert hostname to IP
nslookup example.com
# or
host example.com
# Try connecting to the IP directly
ssh [email protected]
# If this works but the hostname doesn't, it's a DNS/routing issue, not network reachabilityIf the direct IP works but the hostname doesn't, the issue may be:
- DNS resolving to an IP in a different subnet
- Split DNS returning different IPs from different locations
- Network not routing to the resolved IP address
Some networks have IPv6 connectivity issues. Force IPv4 to test:
# Use -4 flag to force IPv4
ssh -4 [email protected]
# If this works, IPv6 is the problem
# You can make this permanent in ~/.ssh/config:
# AddressFamily inet (for IPv4 only)If forcing IPv4 solves the problem, check your IPv6 routing:
# Check IPv6 routing
ip -6 route show
# Disable IPv6 on an interface (temporary)
sudo sysctl net.ipv6.conf.eth0.disable_ipv6=1
# Or permanently in /etc/sysctl.conf
# net.ipv6.conf.all.disable_ipv6 = 1
# net.ipv6.conf.default.disable_ipv6 = 1If the target is on a private network, you may need to connect through a VPN or jump host first:
# Connect through a jump host (bastion)
ssh -J jumphost.example.com [email protected]
# Configure in ~/.ssh/config for easier access
Host internal-host
HostName internal-host.example.com
User username
ProxyJump jumphost.example.com
# Then just use:
ssh internal-hostFor VPN connections:
# Ensure VPN is connected
sudo openvpn --config myclient.ovpn
# Or for commercial VPN providers, use their client
# Once connected, verify routing includes the VPN network:
ip route showAfter connecting to VPN, retry SSH:
Ensure your network interface is actually UP and has an IP address:
# Check interface status
ip link show
# or
ifconfig
# Look for the interface (eth0, wlan0, en0, etc.)
# It should say "UP" and have an IP address (inet)
# If interface is DOWN, bring it up:
sudo ip link set eth0 up
# or
sudo ifup eth0
# On macOS
sudo ifconfig en0 upMake sure the interface shows "UP" and has an IP address assigned. If not, configure it:
# Temporary IP assignment (Linux)
sudo ip addr add 192.168.1.100/24 dev eth0
# Or use DHCP
sudo dhclient eth0Get detailed connection information to understand where the failure occurs:
# Maximum verbosity shows network-level details
ssh -vvv [email protected]
# Output will show:
# - Which hostname/IP is being used
# - Routing attempts
# - Where the connection fails
# - Exact error from the network stackLook for lines like:
- "Trying ... port 22" - shows IP being attempted
- "ssh: connect to host ... port 22: Network is unreachable" - exact failure
This tells you which IP address is being attempted and confirms it's a network issue.
Once you have network connectivity, ensure the remote host is actually running and SSH is enabled:
# If you have access to the remote machine, check SSH daemon status
sudo systemctl status sshd
# or
sudo service ssh status
# Start SSH if it's not running
sudo systemctl start sshd
sudo systemctl enable sshd # Enable on boot
# Check if SSH is listening on port 22
sudo netstat -tlnp | grep ssh
# or
sudo ss -tlnp | grep ssh
# or with lsof
sudo lsof -i :22If you don't have direct access to the remote host, use network scanning:
# Check if port 22 is open on the remote host
nc -zv example.com 22
# or
telnet example.com 22
# Use nmap if available
sudo nmap -p 22 example.comUnderstanding network layers:
The "Network is unreachable" error occurs at OSI Layer 3 (Network Layer), before the SSH protocol even starts. This is why the error appears immediately without timeout—the operating system's network stack can't find a route to the destination.
Common routing scenarios:
1. Direct route: If target is on same subnet (192.168.1.0/24), packet goes directly
2. Default route: If target is on different subnet, packet goes to default gateway (0.0.0.0/0 via 192.168.1.1)
3. No route: If no matching route exists and no default route, "Network is unreachable"
When a route fails, the ICMP error "Destination unreachable, no route to host" comes back, and SSH reports "Network is unreachable".
Difference between similar errors:
- Network is unreachable: No route exists at all
- No route to host: Route exists but host on that network is unreachable
- Connection refused: Route exists, host is reachable, but nothing is listening on port 22
- Connection timed out: Route exists, SYN packets go out, but no response comes back
IPv4 vs IPv6 issues:
Some systems have misconfigured IPv6 routing. When you specify a hostname, DNS might return an IPv6 address, but your client's IPv6 routing might be broken. This is why forcing IPv4 with -4 often works as a workaround.
Network namespaces and containers:
If running SSH from inside a container or network namespace, routing is isolated from the host. The container must have:
- A network interface assigned
- A default route to the container's gateway
- The gateway routing packets to the target network
Firewall debugging:
If your firewall blocks the connection, you won't see "Network is unreachable" but rather a timeout or connection reset. "Network is unreachable" suggests the firewall isn't involved—the network path genuinely doesn't exist.
Tools for debugging routing:
- traceroute: Shows the network path hop-by-hop
- mtr: Continuous traceroute with statistics
- route -n: Shows your routing table
- ip route show: More detailed routing info (Linux)
- ip link show: Shows interface status
- tcpdump: Captures packets to see what's being sent
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH