Recuperare quando SSH smette di funzionare

Server Manager comunica con il tuo server solo tramite SSH. Se SSH smette di funzionare, Server Manager non può aiutarti: non ha altri canali per entrare nella macchina. Ma il server sta bene, e hai altri modi per rientrare. Questo articolo ti aiuta a identificare i sintomi più comuni e ti guida nei percorsi di recupero.

Leggi questo prima di andare nel panico. Nessuno degli scenari classici in cui SSH si rompe significa che i tuoi dati sono spariti. Il server è ancora in esecuzione; semplicemente non riesci ad accedervi dal punto da cui lo fai di solito. Nel caso peggiore, ripristini l'accesso SSH dalla console web del tuo provider cloud: stessa macchina, stessi dischi, stessi file.

Passaggio 1 — Leggi l'errore in linguaggio chiaro

Se hai provato a collegarti tramite Server Manager e l'operazione non è riuscita, la finestra Connetti mostra già una diagnosi in linguaggio chiaro di ciò che probabilmente non va:

Quel messaggio indica la causa più probabile. La tabella qui sotto collega il messaggio mostrato da Server Manager al punto da cui partire.

Passaggio 2 — Recupera l'accesso tramite la console web del provider

Se la diagnosi sopra indica che "qualcosa è rotto sul server stesso" (la maggior parte delle righe della tabella), il modo per rientrare è la console web del tuo provider cloud: un terminale nel browser che aggira completamente SSH. Tutti i principali provider ne hanno una, solo con nomi diversi:

Una volta entrato dalla console web, hai accesso completo alla shell senza passare da SSH: quindi puoi correggere ciò che blocca SSH e poi tornare a Server Manager.

La console web chiede la password locale del server. È la password a livello di sistema operativo per il tuo utente sul server stesso: di solito quella che il provider ti ha inviato via email, oppure la password che hai impostato durante la configurazione iniziale. Non è la passphrase di Server Manager né la password dell'account del provider cloud. Se non ne hai mai impostata una e hai usato solo una chiave, esegui passwd <user> tramite il servizio di metadata del provider (DigitalOcean ha "Reset root password" → invia una nuova password via email; AWS permette il reset della password tramite Systems Manager).

Passaggio 3 — Risolvi le cause più comuni

Una volta entrato dalla console web, passa in rassegna questi casi:

"Ho modificato sshd_config e mi sono chiuso fuori"

Un classico. Hai cambiato qualcosa in /etc/ssh/sshd_config, hai riavviato sshd e ora non riesci più a rientrare. Recupero:

bashsudo sshd -t                                  # controlla la sintassi della configurazione attuale
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.broken
sudo nano /etc/ssh/sshd_config                # annulla la modifica che causa il problema
sudo sshd -t                                  # controlla di nuovo la sintassi
sudo systemctl restart sshd                   # riavvia in modo pulito

Cose comuni che fanno restare fuori:

• PermitRootLogin no mentre ti stai collegando come root → riabilita root oppure crea prima un utente non root con sudo
• PasswordAuthentication no prima di aver aggiunto la chiave a ~/.ssh/authorized_keys
• Port 2222 (o un'altra porta non predefinita) — il server è ancora attivo, sta solo ascoltando altrove; ricollegati alla nuova porta
• AllowUsers alice che esclude l'utente con cui stai effettivamente provando ad accedere

"fail2ban ha bannato il mio IP"

Se hai digitato la password sbagliata 3–5 volte di fila, fail2ban (o sshguard) spesso blocca il tuo IP per un periodo da 10 minuti a un'ora. Per controllare e rimuovere il ban:

bashsudo fail2ban-client status sshd               # mostra gli IP bannati
sudo fail2ban-client unban <YOUR-IP>           # rimuove il ban dal tuo IP

Il tuo IP attuale è quello mostrato da curl ifconfig.me dalla tua connessione di casa (non dal server). Per evitarlo la prossima volta, aggiungiti a /etc/fail2ban/jail.local sotto ignoreip = quando riesci di nuovo ad accedere.

"ufw / iptables mi ha chiuso fuori"

Hai attivato il firewall senza consentire esplicitamente la porta 22:

bashsudo ufw status                                # mostra le regole attuali
sudo ufw allow 22/tcp                          # consente esplicitamente SSH
sudo ufw reload

Per iptables direttamente:

bashsudo iptables -L INPUT -n -v                   # mostra cosa sta bloccando
sudo iptables -I INPUT -p tcp --dport 22 -j ACCEPT
sudo netfilter-persistent save                 # salva (Debian/Ubuntu)

"Ho rimosso la mia chiave pubblica da authorized_keys"

Se hai svuotato per sbaglio ~/.ssh/authorized_keys (o hai impostato permessi errati con chmod), riaggiungila dalla console web:

bashmkdir -p ~/.ssh && chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys                    # incolla la tua chiave pubblica e salva
chmod 600 ~/.ssh/authorized_keys

La chiave pubblica è il file breve, su una sola riga, che di solito si trova in ~/.ssh/id_ed25519.pub (o id_rsa.pub) sul tuo laptop. Incolla tutta la riga, incluso il prefisso ssh-ed25519 … e il suffisso user@host.

Se non hai più la chiave pubblica originale, genera una nuova coppia di chiavi sul laptop:

bashssh-keygen -t ed25519 -C "you@laptop"          # crea ~/.ssh/id_ed25519 + .pub
cat ~/.ssh/id_ed25519.pub                       # incolla questo in authorized_keys

"Il firewall del provider è cambiato da solo"

Non è cambiato da solo, ma i provider aggiornano periodicamente le policy predefinite. Apri la pagina Security List / Network Security Group / Firewall Rules del tuo provider e verifica che la porta 22 (o qualunque porta su cui ascolti il tuo SSH) sia ancora consentita da internet pubblico (0.0.0.0/0) o dal tuo intervallo IP specifico.

Se il tuo IP è cambiato (ISP di casa, cambio città, passaggio al mobile) e avevi limitato il firewall al vecchio IP, il nuovo IP viene bloccato. Allarga temporaneamente la regola a 0.0.0.0/0, entra, poi restringila di nuovo se vuoi.

Passaggio 4 — Ricollegati da Server Manager

Quando SSH funziona dal tuo terminale (prova con ssh -v <user>@<host>), torna su Server Manager e fai clic su Connetti server. Reinserisci le credenziali e sei di nuovo al punto in cui eri. La cronologia della chat della sessione precedente è persa (le sessioni SSH sono solo in RAM per progettazione), ma i tuoi siti e servizi sul server non sono stati toccati.

Se hai salvato il server (con una passphrase di cifratura di Server Manager), selezionalo dal menu a discesa invece di reinserire tutto.

Opzioni di ultima istanza

Se non riesci a entrare nemmeno dalla console web del provider, hai ancora alcune possibilità:

• Rollback da snapshot — se hai creato uno snapshot prima che le cose andassero male (e la maggior parte dei provider li offre, a volte anche automatici), ripristina quello snapshot. Perdi le modifiche successive, ma torni a un sistema che sai funzionare.
• Ricostruzione da backup — se hai un bundle .tar.gz di Server Manager (vedi Backup), avvia un server nuovo, installaci Server Manager e usa la procedura guidata Ripristina da un backup. Stesso sito, nuovo server.
• Scollega il disco e montalo su un'altra VM — è una procedura avanzata, ma funziona con la maggior parte dei provider. Arresta la VM guasta, scollega il suo disco di avvio, collegalo a una VM funzionante come disco secondario, montalo, modifica i file che erano rotti (sshd_config, authorized_keys), smontalo, ricollegalo alla VM originale e riavvia. La documentazione del tuo provider contiene i passaggi dettagliati.

Prevenzione — prima di modificare qualunque cosa legata a SSH

Una breve checklist da seguire prima di modificare sshd_config, che ha risparmiato a molte persone un panico alle 2 di notte:

1. Apri una seconda sessione SSH prima di modificare — così, se ti chiudi fuori dalla nuova sessione, quella vecchia resta attiva e puoi tornare indietro.
2. **sudo sshd -t** prima di riavviare — intercetta la maggior parte degli errori di sintassi.
3. Prova la nuova configurazione senza renderla permanente. sudo /usr/sbin/sshd -D -p 2222 -f /etc/ssh/sshd_config.new esegue un sshd di test sulla porta 2222 con una configurazione di test. Entra via SSH con -p 2222 per verificare; se funziona, allora sostituisci la configurazione e riavvia davvero.
4. Prepara l'accesso alla console web del provider prima di iniziare. Apri la scheda, accedi, conferma che la console funzioni, poi inizia a modificare.
5. **Non eseguire ufw enable tramite SSH** senza prima aver eseguito sudo ufw allow 22/tcp.

Per le modifiche che Server Manager esegue tramite la chat: Faro si ferma per chiedere la tua approvazione su ogni comando e non propone nulla che possa rompere SSH (niente modifiche a sshd_config, niente ufw enable senza una regola esplicita di allow). Sono le sessioni manuali con nano /etc/ssh/sshd_config a cogliere le persone di sorpresa.

Domande frequenti

Ho perso qualcosa? No — i tuoi file, i tuoi siti e i tuoi database sono esattamente come li hai lasciati. SSH è solo il canale; il server in sé non è stato toccato.

La cronologia della chat è sparita? Sì. Le sessioni SSH vivono solo in RAM: quando la sessione termina (dal tuo lato o dal lato server), la chat si azzera. Il lavoro fatto dalla chat sul server però resta: siti distribuiti, configurazioni modificate e servizi installati persistono normalmente.

Posso evitarlo del tutto? In gran parte sì. Il percorso gestito da Server Manager è più sicuro (approvazione a ogni passaggio; nessuna modifica a sshd_config). Il rischio nasce dalle sessioni SSH manuali in cui modifichi tu la configurazione. Se fai tutto tramite Server Manager, lo scenario in cui resti chiuso fuori accade quasi mai.

Il mio server è su un provider non elencato nella tabella sopra. Il principio è universale: la maggior parte dei provider offre qualche forma di console fuori banda (VNC, seriale, shell web). Cerca nella documentazione del tuo provider "console" o "rescue mode". Se hai accesso fisico (homelab), un monitor e una tastiera fanno lo stesso lavoro.

Server Manager dice "Connessione rifiutata", ma ho appena usato SSH dal mio terminale 5 minuti fa. O sshd è andato in crash (controlla dalla console del provider: systemctl status sshd), oppure fail2ban ha bannato l'IP del VPS di Server Manager (diverso dal tuo IP di casa: Server Manager gira nel proprio datacenter e il tuo server vede quell'IP come sorgente). Inserisci l'IP di uscita di Server Manager nella whitelist di fail2ban in ignoreip = , oppure allenta le impostazioni findtime/maxretry.

Cosa NON rientra in questa guida

• Recupero a livello di account (hai dimenticato il login di Server Manager, hai dimenticato la password dell'account del provider cloud) — questi sono canali separati: procedura di recupero account del provider + reset password di Server Manager dalla pagina di accesso.
• Recupero di dischi cifrati (root cifrata con LUKS che non si sblocca) — dipende dal provider; consulta la documentazione del tuo provider per "rescue mode" o "single-user boot".
• Chiave SSH persa definitivamente senza altri metodi di accesso — a quel punto la strada pratica è ricostruire da un backup. Vedi Ripristina da un backup e Backup per il quadro completo.