Cosa ti dice il messaggio
ssh: connect to host 203.0.113.10 port 22: No route to hostMessaggi simili significano cose diverse, quindi verifica di avere proprio questo. Ogni riga qui sotto è stata prodotta con una regola o una configurazione reale:
| Messaggio | Cosa è successo |
|---|---|
No route to host | Nessuna macchina ha risposto a quell'indirizzo sulla rete locale, oppure un firewall ha risposto host-prohibited |
Network is unreachable | La tua macchina non ha alcuna rotta, spesso manca il gateway predefinito |
Connection refused | La macchina ha risposto, ma nulla accetta connessioni su quella porta, oppure un firewall l'ha rifiutata con port-unreachable. Vedi Connection refused |
Connection timed out | Non è tornata alcuna risposta, spesso un firewall che scarta i pacchetti. Vedi Connection timed out |
Primo test
ping -c 3 203.0.113.10
nc -vz -w 10 203.0.113.10 22Alcuni server ignorano il ping, quindi un ping fallito da solo prova poco. Un ping che funziona mentre la porta 22 dà No route to host indica direttamente un firewall sul server, cioè la causa 2.
Causa 1: la macchina è spenta, o l'indirizzo è sbagliato
Sulla stessa rete locale, la tua macchina chiede chi ha l'indirizzo. Se nessuno risponde, ottieni questo errore entro pochi secondi. Su Linux puoi vedere la ricerca fallita:
ip neigh show to 203.0.113.10203.0.113.10 dev eth0 FAILEDSu macOS usa arp -n 203.0.113.10, che mostra incomplete oppure nessuna voce.
Controlla che la macchina sia accesa e collegata, e verifica il suo indirizzo attuale dalla sua console o dall'elenco dispositivi del tuo router. I router di casa spesso assegnano un nuovo indirizzo dopo un riavvio. Un server cloud può avere un nuovo indirizzo IP dopo essere stato fermato e riavviato.
Causa 2: un firewall sul server ti rifiuta
Questa regola produce esattamente lo stesso messaggio sul client, anche se la macchina è accesa e sshd è in esecuzione:
iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with icmp-host-prohibitedIl rifiuto predefinito di firewalld sui sistemi in stile Red Hat dà lo stesso risultato. Da una console sul server, guarda cosa c'è:
sudo firewall-cmd --list-all
sudo iptables -S INPUT
sudo nft list rulesetPer consentire SSH con firewalld:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reloadCon ufw, vedi come consentire SSH con ufw. In un account cloud, guarda anche il security group o il firewall di rete del provider.
Causa 3: una rotta mancante o una VPN spenta
Chiedi al sistema dove invierebbe il pacchetto. Questi due comandi leggono solo la tabella di routing:
ip route get 203.0.113.10route -n get 203.0.113.10Il primo è per Linux e il secondo per macOS. Guarda l'interfaccia e il gateway:
- Un indirizzo privato come 10.x che esce dal tuo normale Wi-Fi invece che dalla VPN: la VPN è spenta, oppure non copre quella sottorete.
- Due reti che usano lo stesso intervallo, come una rete domestica e una VPN entrambe su 192.168.1.x: vince quella sbagliata. Cambiane una.
- Un gateway sbagliato sul server stesso: può ricevere i tuoi pacchetti e non riuscire a rispondere. Controlla
ip routedalla sua console.
Se quella rete si raggiunge solo da un altro server, passa da lì con un jump host e ProxyJump.
Causa 4: isolamento del Wi-Fi
Le reti ospiti e molte reti di uffici o hotel impediscono ai dispositivi di parlarsi. Se lo stesso comando funziona da un'altra rete, o da una connessione cablata, è questo il motivo. Passa alla rete principale, oppure raggiungi la macchina tramite una VPN.
Causa 5: macOS o iOS bloccano l'app dalla rete locale
Da macOS 15, i programmi hanno bisogno del privilegio Local Network per raggiungere le macchine della tua LAN. Apple dice che gli strumenti da riga di comando eseguiti da Terminale sono consentiti automaticamente, mentre gli altri programmi sono bloccati finché non concedi il privilegio. Quindi se ssh verso un indirizzo della LAN fallisce dentro un'altra app di terminale o un editor ma funziona in Terminale, apri Impostazioni di Sistema, poi Privacy e sicurezza, poi Rete locale, e attiva quell'app. Su iPhone e iPad ogni app SSH ha bisogno dello stesso permesso: Impostazioni, poi Privacy e sicurezza, poi Rete locale. Non riguarda gli indirizzi su internet pubblico.
Domande
No route to host è un problema della chiave SSH?
No. La connessione è fallita prima che SSH partisse, quindi chiavi, password e nome utente non c'entrano. Guarda la rete: l'indirizzo, un firewall o una rotta.
Perché ping funziona ma SSH dice No route to host?
La macchina è accesa e un firewall su di essa rifiuta la porta 22 con una risposta host-prohibited. Controlla iptables, nftables o firewalld sul server, e il security group del provider.
Che differenza c'è fra No route to host e Connection timed out?
No route to host è una risposta precisa: l'indirizzo non è raggiungibile. Il timeout vuol dire che non è arrivata nessuna risposta, di solito per un firewall che scarta i pacchetti in silenzio.
Fonti
- TN3179: Understanding local network privacy, Apple
- Manuale di firewall-cmd, firewalld
- iptables-extensions(8), target REJECT