SSH: fail2ban dopo reboot blocca accessi legittimi

Quando l’hardening SSH viene fatto in fretta, il problema non è quasi mai “se” qualcosa si romperà. Il problema è cosa si rompe per primo.

Il caso tipico è questo: si abilita fail2ban, si chiude un po’ troppo sshd_config, si stringono i permessi dei file, poi al reboot l’accesso sparisce. Dal lato operatore sembra un blocco totale. Dal lato server spesso è un mix di jail troppo aggressiva, log non letti, chiavi con permessi sbagliati o un reload fatto nel momento peggiore.

Qui vediamo come diagnosticare il guasto, come rientrare senza peggiorare la situazione e come impostare un rollback pratico. Non è un tutorial di installazione base. È una guida per quando l’hardening ha già causato un incidente.

Prerequisiti

• Accesso console fuori banda, KVM, IPMI, VNC, web console del provider o rescue mode.
• Un utente secondario con sudo, non solo l’account principale.
• SSH server attivo su Debian, Ubuntu, AlmaLinux o simili.
• fail2ban già installato o previsto come parte della configurazione.
• Accesso ai log locali, anche da console, in /var/log/auth.log o /var/log/secure.

Warning: se hai solo accesso SSH e stai già fuori, non fare tentativi ciechi. Prima apri una console alternativa o un canale di recupero.

Note: i comandi sotto sono da terminale. Se usi un pannello hosting con terminale integrato, aprilo dalla sezione strumenti o console del server.

Step numerati

1) Capire se il blocco è fail2ban, sshd o firewall

Prima distingui il sintomo. Un ban di fail2ban non è uguale a un servizio SSH non in ascolto. Anche il firewall può sembrare colpevole.

Da console locale controlla subito tre punti: processo, porta e ban attivi.

systemctl status sshd --no-pager
systemctl status fail2ban --no-pager
ss -tlnp | grep ':22'
fail2ban-client status sshd
# Output:
# sshd attivo, porta 22 in ascolto, fail2ban con jail sshd e lista ban visibile oppure vuota

Se sshd è attivo ma la porta non ascolta, il problema è nella configurazione SSH o nel servizio. Se la porta ascolta ma il tuo IP risulta bannato, il problema è fail2ban. Se tutto sembra regolare ma non entri, passa al firewall e ai permessi.

Note: su sistemi con firewall gestito dal pannello, verifica anche le regole da interfaccia. In molti hosting la porta 22 può essere filtrata a livello provider.

2) Verificare i log reali dell’ultimo tentativo

La diagnosi migliore arriva dai log. Non dai messaggi del client, che spesso sono troppo generici.

journalctl -u sshd -n 50 --no-pager
journalctl -u fail2ban -n 80 --no-pager
tail -n 60 /var/log/auth.log
# Output:
# "Failed password", "Invalid user", "Ban 203.0.113.10", oppure errori di parsing su sshd_config

Cerca tre pattern. Il primo è il ban ripetuto sul tuo IP. Il secondo è un errore di sintassi in sshd_config. Il terzo è un problema di permessi su authorized_keys o sulla directory home.

Se trovi una riga come sshd[1234]: Bad configuration option, il servizio può non ripartire dopo un reload. Se trovi Authentication refused: bad ownership or modes, il server rifiuta la chiave anche se la chiave è corretta.

3) Disinnescare il ban senza spegnere tutta la protezione

Se il tuo IP è stato bannato, rimuovi solo quel ban. Non fermare fail2ban a meno che non sia l’unico modo per rientrare.

fail2ban-client status sshd
fail2ban-client set sshd unbanip 203.0.113.10
fail2ban-client status sshd
# Output:
# IP rimosso dalla jail sshd, protezione ancora attiva per gli altri indirizzi

Se non riesci a usare fail2ban-client, entra da console e pulisci solo la riga del tuo IP nel file di stato, ma è una soluzione di emergenza. Meglio agire dal client quando possibile.

Warning: non cancellare a mano file interni di fail2ban senza sapere la versione. Alcune azioni persistono in backend diversi.

4) Correggere i permessi delle chiavi e della home

Uno dei guasti più frequenti dopo l’hardening è questo: permessi troppo stretti o troppo larghi. SSH è severo. Basta poco per bloccare tutto.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER":"$USER" ~/.ssh
chmod 750 ~
# Output:
# directory .ssh privata, authorized_keys leggibile solo dal proprietario, home coerente con il login

Se hai modificato anche la home, controlla che non sia scrivibile da altri. Una home con permessi strani può far fallire il login con chiave.

Su server condivisi o con più utenti, il principio è semplice: ogni directory deve essere leggibile solo quanto serve. Il resto va chiuso.

5) Rivedere sshd_config con una modifica minima

Molti guasti nascono da un set di parametri troppo aggressivo. Per esempio: disabilitare password, cambiare porta, togliere l’utente root e chiudere le chiavi senza testare il login alternativo.

Apri il file, ma cambia una cosa per volta. L’obiettivo è ripristinare l’accesso, non “indurire di più”.

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M)
sshd -t
# Output:
# nessun output se la configurazione è valida
# oppure errori di sintassi con riga e opzione difettosa

Se sshd -t segnala errore, correggi prima quello. Solo dopo fai reload. Se vuoi impostare un rollback rapido, conserva sempre una copia del file prima di ogni modifica.

Una baseline prudente usa queste idee: chiavi abilitate, password disabilitate solo dopo verifica, root login vietato solo se hai un utente sudo funzionante, porta personalizzata solo se il firewall è già coerente.

6) Ripristinare il servizio senza perdere la sessione di emergenza

Se hai una console aperta e un file di backup valido, ricarica il servizio solo dopo il test di sintassi.

cp /etc/ssh/sshd_config.bak.2026-03-26-0100 /etc/ssh/sshd_config
sshd -t && systemctl restart sshd
systemctl status sshd --no-pager
# Output:
# sshd attivo e senza errori di configurazione

Se il server usa un nome servizio diverso, su alcune distribuzioni è ssh invece di sshd. Il punto non cambia: prima test, poi riavvio.

Note: se sei da remoto e temi di chiuderti fuori, usa systemctl reload sshd solo quando il cambio è compatibile con le sessioni attive. Un restart è più rischioso.

7) Allineare fail2ban a una soglia realistica

La jail SSH non deve punire i normali errori umani. Se un amministratore si autentica da una linea mobile o da una VPN instabile, tre tentativi possono essere troppo pochi.

Controlla la jail e i tempi di ban. In molti ambienti conviene alzare il valore di maxretry e usare un bantime progressivo.

[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 30m
# Output:
# jail SSH attiva, soglia più tollerante, ban temporaneo ma non estremo

Se vuoi proteggere il server senza bloccare gli operatori, aggiungi gli IP fidati o la VPN di accesso nella lista di ignore. Non lasciare però una whitelist troppo ampia.

La regola più utile è questa: proteggi il servizio, non l’abitudine di collegarti da ovunque senza controllo.

Verifica finale

Dopo il ripristino, verifica da una seconda macchina o da una rete diversa. La prova migliore non è “mi collego io che sono già dentro”.

• Il login con chiave funziona.
• Il login con password, se previsto, è coerente con la policy.
• fail2ban registra nuovi tentativi e non banna subito l’IP corretto.
• Il servizio SSH resta attivo dopo un reboot di prova o un reload.
• I permessi di home e .ssh non sono stati allentati per emergenza e lasciati così.

Se usi un pannello hosting, controlla anche i log di sicurezza dal menu dedicato. In alcuni casi il provider conserva eventi utili che il sistema locale non evidenzia bene.

Troubleshooting

Errore: Permission denied (publickey)

Causa: la chiave è corretta, ma i permessi o il proprietario della home non lo sono.

Fix:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER":"$USER" ~/.ssh
chmod 750 ~
# Output:
# SSH accetta di nuovo la chiave pubblica

Errore: sshd: Bad configuration option

Causa: una direttiva nuova o copiata male in sshd_config blocca il servizio.

Fix:

sshd -t
nano /etc/ssh/sshd_config
systemctl restart sshd
# Output:
# configurazione valida e servizio riavviato senza errori

Errore: Ban 203.0.113.10 nei log di fail2ban

Causa: l’indirizzo pubblico dell’amministratore è stato classificato come sospetto dopo troppi tentativi.

Fix:

fail2ban-client set sshd unbanip 203.0.113.10
fail2ban-client status sshd
# Output:
# IP rimosso dalla jail e protezione ancora attiva

Warning: se il ban torna subito, controlla anche il client SSH salvato nel browser, nel password manager o in un alias shell. Spesso il problema è un vecchio tentativo automatico ripetuto in background.

Conclusione

L’hardening SSH funziona solo se è reversibile. Ogni modifica a fail2ban, permessi e sshd_config deve avere un percorso di rientro già pronto.

Il prossimo passo concreto è creare una checklist di recupero con backup del file SSH, accesso console e un utente sudo secondario. È il modo più semplice per evitare che una misura di sicurezza diventi un fermo operativo.