Server non risponde via SSH: piano di troubleshooting

Un server irraggiungibile via SSH e uno degli scenari più stressanti per chi gestisce infrastrutture. La sequenza di azioni da intraprendere fa la differenza tra un ripristino in 10 minuti e ore di downtime. Vediamo un piano di troubleshooting strutturato.

Step 1: Confermare il problema

Prima di tutto, verifica che il problema sia il server e non il tuo client. Prova da una rete diversa (tethering mobile, server di rimbalzo). Esegui ping IP-server per verificare connettivita IP base. Se ping risponde ma SSH no, il problema e nel servizio o nel firewall, non nella rete. Se ping non risponde, indaga rete o spegnimento.

Step 2: Console di emergenza

Quasi tutti i provider offrono accesso KVM/IPMI dal pannello: una console "fisica" indipendente da rete e SSH. Loggati al pannello provider, apri la console e verifica se il sistema e responsivo. Se il login funziona, hai canale alternativo per diagnosticare e correggere.

Step 3: Verifica del servizio SSH

Dalla console, controlla lo stato: systemctl status sshd o service ssh status. Se non e in esecuzione, riavvialo. Controlla i log: journalctl -u sshd -n 100 per errori recenti. Spesso il problema e una configurazione errata di sshd_config dopo una modifica.

Step 4: Firewall

Verifica regole UFW/iptables: ufw status verbose, iptables -L -n. Una regola che chiude la porta SSH e un'errore comune. Controlla anche fail2ban-client status sshd: il tuo IP potrebbe essere stato bannato dopo tentativi falliti. Sblocca con fail2ban-client set sshd unbanip TUO-IP.

Step 5: Risorse di sistema

Se il server e raggiungibile ma lento o non accetta connessioni, controlla carico (load average), spazio disco (df -h), memoria (free -h). Un disco pieno o RAM esaurita possono impedire sshd di forkare nuove sessioni. Cerca processi runaway con top.

Procedura passo-passo riepilogativa

1. Conferma il problema da rete alternativa.
2. Apri la console KVM/IPMI del provider.
3. Verifica lo stato di sshd e dei log.
4. Controlla firewall e fail2ban.
5. Verifica risorse: carico, disco, memoria.
6. Cerca attacchi in corso o anomalie nei log applicativi.
7. Riavvia sshd se necessario.
8. Se irrecuperabile, considera rescue boot dal pannello.
9. Dopo il recovery, documenta la causa e aggiungi prevenzione.

Errori comuni e come risolverli

• sshd_config modificato erroneamente: la console KVM e il tuo backup; fai sempre sshd -t prima di restart.
• Firewall chiuso accidentalmente: usa iptables-apply o ufw insert con timeout.
• Disco pieno blocca sshd: liberane subito; configura monitoring.
• Fail2ban bannato te stesso: aggiungi sempre IP fissi a ignoreip.

Prevenzione

Tieni una chiave SSH di emergenza separata, accesso console sempre testato, monitoring uptime esterno con alert, lista contatti provider aggiornata. Configura AllowUsers e prevenzione lockout con sessioni multiple aperte durante modifiche.

Domande frequenti

D: Posso accedere senza console KVM?
R: Senza accesso fisico o KVM, le opzioni si riducono molto: contatta il provider.

D: Cosa fare in rescue mode?
R: Monta il disco, correggi sshd_config o firewall, riavvia normale.

D: SSH su porta non standard riduce questi problemi?
R: Riduce solo brute force, non i problemi di configurazione.

Approfondimento tecnico: serial console e rescue mode

La serial console e un canale più basso ancora del KVM/IPMI: si collega all'output testuale del kernel via emulazione UART, indipendentemente da rete e desktop. Per abilitarla su Linux: aggiungi console=ttyS0,115200 a kernel cmdline, abilita serial-getty@ttyS0.service. Permette di vedere i messaggi di boot, panic kernel, accedere a single user mode. Provider come Hetzner, OVH, Online.net offrono accesso seriale via SSH a un concentratore.

La rescue mode e un sistema minimal (initramfs o live Linux) bootato al posto del normale. Da li monti il disco principale, chroot, ripari sshd_config o firewall, rigeneri grub. Molti provider offrono rescue mode dal pannello con un click.

Scenari d'uso reali

Un admin ha disabilitato accidentalmente sshd: KVM via pannello, riabilita servizio, mai più perdere accesso.

Un upgrade kernel fallito con kernel panic: rescue mode, ripristino initramfs precedente, reboot.

Un filesystem corrotto dopo crash: rescue boot, fsck, riavvio.

Checklist operativa emergenza SSH

• Accesso KVM/IPMI testato e funzionante.
• Procedura di rescue boot documentata.
• Chiave SSH di emergenza separata.
• sessione SSH attiva durante modifiche a sshd_config.
• sshd -t prima di restart per validare config.
• fail2ban con ignoreip per IP fissi del team.
• Contatti provider aggiornati e raggiungibili 24/7.

Risorse e riferimenti

Documentazione provider sul KVM/IPMI (Hetzner, OVH, Aruba). Linux Rescue Mode guide. SystemRescue distribution per recovery. Per cluster, drain/cordon prima di intervenire sul singolo nodo. Per audit post-mortem: journalctl, dmesg, last.

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su server non risponde via ssh richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.