Fuori dal server: «Connection refused» e «Permission denied» su SSH, guida passo passo

Chi gestisce un server lo scopre sempre nel momento peggiore: il terminale risponde con Connection refused oppure con Permission denied (publickey) e il sito, o il pannello, restano irraggiungibili. Prima regola: non toccare nulla su sshd_config finché non hai capito quale dei due errori è, perché le cause e i rimedi sono diversi.

Cosa significano i due errori

Connection refused vuol dire che il pacchetto è arrivato alla macchina (o a un firewall davanti) ma nessun processo ha risposto su quella porta: o la porta è sbagliata, o il firewall la blocca, o sshd non è in esecuzione. Permission denied (publickey) vuol dire l'opposto: il server ha risposto, la connessione TCP è andata a buon fine, ma ha rifiutato la chiave o la password che hai offerto.

Connection refused: le cause in ordine

1. Porta cambiata. Se qualcuno ha spostato SSH dalla 22 a un'altra porta, il comando da lanciare (sistema locale) è ssh -p 2222 utente@host sostituendo 2222 con la porta giusta. Per vedere su quale porta ascolta sshd, sul server: sudo ss -tlnp | grep sshd.

2. Firewall o gruppo di sicurezza. Su Ubuntu con UFW: sudo ufw status verbose deve mostrare la porta SSH in ALLOW. Se il server è un VPS o un cloud, controlla anche il firewall a monte (security group, cloud firewall) nel pannello del fornitore: UFW può dare esito positivo e il traffico venire comunque bloccato prima di arrivare alla macchina. Qui il problema è spesso del fornitore, non tuo: se UFW è a posto e la porta resta chiusa dall'esterno, è il momento di aprire un ticket.

3. Servizio sshd fermo. Solo se hai già un accesso alternativo (console web del fornitore, altro utente attivo): sudo systemctl status ssh su Ubuntu/Debian, sudo systemctl status sshd su CentOS/RHEL/AlmaLinux. Se è fermo: sudo systemctl start ssh (Ubuntu) o sudo systemctl start sshd (RHEL-like), poi sudo systemctl enable ssh perché riparta da solo al prossimo riavvio.

Permission denied: le cause in ordine

1. Fail2ban ti ha bloccato. Capita dopo troppi tentativi falliti, anche tuoi (chiave sbagliata ripetuta, script di deploy che tenta con l'utente errato). I valori di default del progetto fail2ban, letti dal file di configurazione ufficiale, sono: ban di 10 minuti dopo 5 tentativi falliti in una finestra di 10 minuti. Per verificare dalla console di emergenza: sudo fail2ban-client status sshd. Per sbloccare subito il tuo IP: sudo fail2ban-client set sshd unbanip TUO.IP.QUI.

2. Chiave sbagliata o permessi di .ssh troppo aperti. Dal client, per vedere quale chiave viene offerta e dove si ferma: ssh -vvv utente@host 2>&1 | grep -i offering. Sul server, i permessi devono essere 700 sulla cartella ~/.ssh e 600 sul file ~/.ssh/authorized_keys, di proprietà dell'utente che fa login e non di root. Per controllarli: stat -c "%a %U %G %n" ~ ~/.ssh ~/.ssh/authorized_keys. Per correggerli: chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys && chown -R $(id -un):$(id -gn) ~/.ssh.

3. Disco pieno. Un disco a 100% impedisce a sshd di scrivere i file temporanei di sessione e il login fallisce anche con chiave corretta. Dalla console di emergenza: df -h. Se la root è piena, prima libera spazio (log vecchi, cache apt con sudo apt clean), poi riprova il login normale.

Dove guardare i log per capire quale caso è il tuo

Su Ubuntu 24.04 con rsyslog installato il file è /var/log/auth.log, altrimenti si usa il journal: sudo journalctl -u ssh -n 50. Su Debian 12 rsyslog non è installato di default, quindi auth.log può non esistere affatto: in quel caso serve journalctl. Su CentOS/RHEL/Rocky il file equivalente è /var/log/secure e il servizio nel journal si chiama sshd: sudo journalctl -u sshd -n 50. La riga che conta, in caso di blocco da fail2ban, è quella che contiene "Ban" seguita dall'IP; in caso di chiave rifiutata è quella con "Failed publickey" seguita dall'impronta della chiave.

Come si entra dalla console di emergenza

Ogni fornitore VPS o cloud offre una console web (VNC o seriale) che bypassa del tutto SSH e passa dal login locale. Da lì si opera come se si fosse davanti alla macchina: si può riavviare sshd, correggere permessi, liberare spazio su disco o sbloccare fail2ban senza bisogno della rete. Il nome della funzione cambia da fornitore a fornitore (console, KVM, VNC console, serial console): si trova nel pannello di gestione della singola istanza.

Le due precauzioni prima di toccare sshd_config

Prima regola: non chiudere mai l'unica sessione SSH attiva mentre modifichi /etc/ssh/sshd_config. Tieni quella sessione aperta, apri un secondo terminale e prova la connessione da lì: se qualcosa va storto, la prima sessione resta il tuo accesso di salvataggio per tornare indietro.

Seconda regola: prima di modificare qualunque parametro (porta, PubkeyAuthentication, PermitRootLogin) verifica che la console di emergenza del fornitore funzioni e sai come raggiungerla. Se la modifica blocca sshd e non hai un paracadute, l'unica via resta aprire un ticket all'assistenza allegando l'orario esatto dell'ultima connessione riuscita, l'IP da cui provavi a collegarti e l'ultima riga di log letta, se l'hai raccolta prima di perdere l'accesso.

Come si verifica che è risolto

Dopo ogni intervento, prova la connessione da un terminale nuovo, non dalla sessione di salvataggio: ssh -v utente@host. Se risponde con il prompt della shell, è risolto. Se cambi la porta o le regole del firewall, verifica anche da una rete diversa dalla tua (per esempio dal telefono in 4G) per escludere che il problema fosse solo nel tuo IP locale.