What the message tells you
ssh: connect to host 203.0.113.10 port 22: No route to hostSimilar messages mean different things, so check that you have this one. Each row below was produced with a real rule or setup:
| Message | What happened |
|---|---|
No route to host | No machine answered at that address on the local network, or a firewall replied host-prohibited |
Network is unreachable | Your machine has no route at all, often no default gateway |
Connection refused | The machine answered, but nothing accepts connections on that port, or a firewall rejected it with port-unreachable. See Connection refused |
Connection timed out | No answer came back, often a firewall that drops packets. See Connection timed out |
First test
ping -c 3 203.0.113.10
nc -vz -w 10 203.0.113.10 22Some servers ignore ping, so a failed ping alone proves little. A ping that works while port 22 gives No route to host points straight at a firewall on the server, which is cause 2.
Cause 1: the machine is off, or the address is wrong
On the same local network, your machine asks who has the address. If nobody answers, you get this error within a few seconds. On Linux you can see the failed lookup:
ip neigh show to 203.0.113.10203.0.113.10 dev eth0 FAILEDOn macOS use arp -n 203.0.113.10, which shows incomplete or no entry.
Check that the machine is powered on and connected, and check its current address from its own console or your router's device list. Home routers often hand out a new address after a restart. A cloud server may have a new IP address after being stopped and started.
Cause 2: a firewall on the server rejects you
This rule produces the exact same message on the client, even though the machine is up and sshd is running:
iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with icmp-host-prohibitedfirewalld's default rejection on Red Hat style systems gives the same result. From a console on the server, see what is there:
sudo firewall-cmd --list-all
sudo iptables -S INPUT
sudo nft list rulesetTo allow SSH under firewalld:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reloadUnder ufw, see how to allow SSH with ufw. In a cloud account, also look at the provider's security group or network firewall.
Cause 3: a missing route or a VPN that is off
Ask your system where it would send the packet. These two commands only read the routing table:
ip route get 203.0.113.10route -n get 203.0.113.10The first is for Linux and the second for macOS. Look at the interface and the gateway:
- A private address such as 10.x going out through your normal Wi-Fi instead of the VPN: the VPN is off, or it does not cover that subnet.
- Two networks using the same range, such as a home network and a VPN both on 192.168.1.x: the wrong one wins. Change one of them.
- A wrong gateway on the server itself: it can receive your packets and fail to reply. Check
ip routefrom its console.
If that network is only reachable through another server, go through it with a jump host and ProxyJump.
Cause 4: Wi-Fi isolation
Guest networks and many office or hotel networks stop devices from talking to each other. If the same command works from another network, or from a wired connection, that is the reason. Move to the main network, or reach the machine through a VPN.
Cause 5: macOS or iOS blocks the app from the local network
Since macOS 15, programs need the Local Network privilege to reach machines on your LAN. Apple says command line tools run from Terminal are allowed automatically, and other programs are blocked until you grant the privilege. So if ssh to a LAN address fails inside another terminal app or editor but works in Terminal, open System Settings, then Privacy & Security, then Local Network, and turn on that app. On iPhone and iPad every SSH app needs the same permission: Settings, then Privacy & Security, then Local Network. It does not affect addresses on the public internet.
Questions
Is No route to host a problem with my SSH key?
No. The connection failed before SSH started, so keys, passwords and the user name play no part. Look at the network: the address, a firewall or a route.
Why does ping work but SSH says No route to host?
The machine is up, and a firewall on it rejects port 22 with a host-prohibited reply. Check iptables, nftables or firewalld on the server, and the provider's security group.
What is the difference between No route to host and Connection timed out?
No route to host is a definite answer that the address cannot be reached. A timeout means no answer came back at all, usually because a firewall drops packets silently.
Sources
- TN3179: Understanding local network privacy, Apple
- firewall-cmd manual, firewalld
- iptables-extensions(8), REJECT target