The "Host is down" error occurs when SSH cannot reach the remote server at the network level. This indicates a network connectivity issue—the target host is unreachable, offline, or has network problems preventing any communication.
When SSH attempts to connect to a remote host, it first sends network packets (ICMP or TCP) to establish connectivity. The "Host is down" error means the SSH client received network-level confirmation that the target host is unreachable—either the host is powered off, disconnected from the network, or has a network interface problem. This is different from "Connection refused" (which means the host is up but SSH daemon isn't listening) or "Connection timed out" (where packets are being dropped). "Host is down" is a definitive network reachability problem.
Double-check that you're using the correct hostname or IP address:
ssh [email protected]
# or
ssh [email protected]If you're not sure of the IP, try to resolve the hostname:
ping hostname.com
nslookup hostname.com
dig hostname.comIf DNS resolution fails or returns an unexpected IP, that's your first problem. Verify the DNS records or use the known IP address directly.
Use ping to check if the host is reachable at the network level:
ping -c 4 hostname.com
# or
ping -c 4 192.168.1.100Expected output (host is up):
PING hostname.com (192.168.1.100): 56 data bytes
64 bytes from 192.168.1.100: icmp_seq=0 ttl=64 time=15.234 msExpected output (host is down):
PING hostname.com (192.168.1.100): 56 data bytes
(No response / Request timeout)If ping fails, the host is genuinely unreachable and you need to resolve network connectivity before SSH will work.
If you have physical access or can check the host status:
1. For cloud providers (AWS, Azure, GCP):
- Log in to your cloud console
- Check if the instance is running (not stopped or terminated)
- Verify the instance has a public IP or is in the correct subnet
2. For physical servers:
- Check if the server is powered on (look for power lights)
- Verify network cable is plugged in
- Check if it completed boot (may take 1-2 minutes after power on)
3. For remote machines you don't have access to:
- Contact the server owner/administrator
- Ask if the host is currently online
- Request they check server logs or hardware status
Ensure you have a working network connection:
# Check if you have internet connectivity
ping 8.8.8.8 # Google's DNS server
# Check your routing table
netstat -rn # Linux/Mac
route print # Windows
# Check your network interfaces
ifconfig # Linux/Mac
ipconfig # WindowsIf you can't reach external networks (like Google DNS), your local network is down or misconfigured. Fix that first.
If the host is on the same local network but still unreachable:
# Check ARP table to see if host is on the local network
arp -a
# If on same subnet, check firewall on your machine
# macOS:
sudo pfctl -sa
# Linux with UFW:
sudo ufw status
# Windows:
netsh advfirewall show allprofilesIf the host is on a different network:
# Check your route to that network
# Trace the path packets take:
traceroute hostname.com # Linux/Mac
tracert hostname.com # Windows
# If traceroute stops at an intermediate router, that's where the break isIf a firewall is blocking the connection, configure it to allow SSH traffic (port 22 or custom SSH port) from your IP.
If the host was recently powered on, it may need time to fully boot:
# Check once
ping hostname.com
# Wait 30-60 seconds for boot to complete
sleep 60
# Try again
ssh [email protected]Cloud instances can take 1-3 minutes to be fully ready after starting. If you just launched an instance, wait a minute before trying SSH.
If the host should be online but isn't reachable:
1. Cloud instances (AWS, Azure, GCP):
- Verify the instance status in the cloud console (should be "Running")
- Check security groups allow inbound SSH (port 22)
- Verify the instance has a public IP assigned
- Check instance monitoring/logs for crashes
2. Data center or shared hosting:
- Contact your hosting provider
- Ask if the server is running
- Check if there's a network issue affecting that data center
- Request they restart the machine if it's hung
3. On your local network:
- Ask the network administrator
- Check if the subnet/VLAN is active
- Verify the switch/router that connects to that host is working
Advanced troubleshooting:
IPv4 vs IPv6: If you have both IPv4 and IPv6 addresses, try specifying the version explicitly:
# Force IPv4
ssh -4 [email protected]
# Force IPv6
ssh -6 [email protected]VPN/Proxy Connections: If connecting through a VPN or jump host, the issue could be on the intermediate hop:
# Test connectivity through jump host
ssh -J jump-host user@target-host
# Or manually:
ssh user@jump-host
# Then from jump host:
ping target-hostKubernetes/Container Networks: For containers, the "host is down" usually means:
- Container is not running: kubectl get pods -o wide
- Pod IP is stale: Check if pod was recently restarted
- Network policy is blocking traffic: Review NetworkPolicy objects
NAT/Port Forwarding: If using port forwarding:
# Connect through forwarded port
ssh -p 2222 user@localhostIf the forwarding is broken, the host appears down even if it's actually reachable on the other side.
Cloud Metadata Services: Some cloud platforms require instance metadata service to be reachable. If that's down, instances may not boot properly. Check your cloud provider's instance logs.
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