Server: controlli rapidi quando SSH non accetta connessioni

Diagnosi probabile

Quando SSH non accetta connessioni, le cause più frequenti sono quattro: sshd fermo o in crash, porta cambiata o filtrata, firewall/ACL che blocca, oppure errore di configurazione in /etc/ssh/sshd_config. In ambienti con pannelli di controllo, può anche intervenire una regola del provider o una protezione esterna che limita gli accessi dopo troppi tentativi falliti.

Se il server è in produzione, va trattato come un incidente: prima si verifica se il problema è locale al client, poi se il servizio risponde sulla porta giusta, infine si controllano log e stato del demone. L’obiettivo non è “toccare tutto”, ma capire in quale anello della catena si è rotto l’accesso.

Verifiche immediate

1. Prova da un altro client o rete: se da una seconda linea o da un altro IP funziona, il blocco è probabilmente lato rete, firewall o IP ban. Esito atteso: il problema non è universale.
2. Controlla la raggiungibilità della porta dal tuo PC:

   nc -vz IP_SERVER 22

   Esito atteso: succeeded o risposta simile. Se va in timeout o refused, la porta non è raggiungibile o il servizio non ascolta.

3. Verifica che SSH ascolti sul server, se hai accesso alla console del provider o a una web console:

   ss -tlnp | grep sshd

   Esito atteso: una riga con :22 o con la porta configurata.

4. Controlla lo stato del servizio:

   systemctl status sshd

   Esito atteso: active (running). Se è inactive, failed o not found, hai già una pista concreta.

Soluzione consigliata passo-passo

1. Ripristina prima la raggiungibilità minima. Se hai accesso alla console del provider, usa quella prima di fare modifiche via SSH. È il canale più sicuro quando la porta 22 non risponde.
2. Se sshd è fermo, riavvialo e verifica subito:

   systemctl restart sshd
   systemctl status sshd --no-pager

   Se il riavvio fallisce, non insistere: passa ai log, perché il problema è spesso di configurazione.

3. Controlla i log del servizio:

   journalctl -u sshd -n 50 --no-pager

   Cerca errori come porta già in uso, chiavi mancanti, permessi errati o direttive non valide. Esito atteso: un messaggio che spiega il blocco.

4. Valida la configurazione prima di riavviare:

   sshd -t

   Esito atteso: nessun output. Se stampa un errore, correggi il file indicato prima di riavviare il demone.

5. Se la porta è stata cambiata, verifica firewall e policy. Su sistemi comuni controlla che la nuova porta sia aperta nel firewall e nel pannello del provider. Se usi UFW:

   ufw status numbered

   Se usi firewalld:

   firewall-cmd --list-all

   Esito atteso: la porta SSH compare tra quelle consentite.

6. Se sospetti un blocco per tentativi falliti, verifica eventuali regole di ban, ad esempio fail2ban. Controlla gli IP bloccati e rimuovi solo il tuo IP se è stato bannato per errore. Esito atteso: l’IP amministrativo torna autorizzato.
7. Se non hai console diretta, usa il pannello del provider per aprire una web console o una rescue shell. È il percorso più sicuro per correggere un lockout SSH senza peggiorare la situazione.

Controlli finali / rollback

1. Verifica l’accesso reale da terminale con la porta corretta:

   ssh -p PORTA utente@IP_SERVER

   Esito atteso: autenticazione riuscita e shell disponibile.

2. Conferma che il demone resti stabile dopo il riavvio:

   systemctl is-active sshd

   Esito atteso: active anche dopo alcuni minuti.

3. Rollback: se hai modificato /etc/ssh/sshd_config e l’accesso è peggiorato, ripristina il backup del file, valida con sshd -t e riavvia solo dopo il controllo positivo. Se hai aperto una porta firewall in prova, chiudi solo quella aggiunta se non serve più.

Assunzione: il problema riguarda un server Linux con accesso amministrativo almeno via console del provider o pannello di emergenza.