Lavorando su un progetto cloud in produzione, una delle difese base più comuni e necessarie è Fail2Ban (o meccanismi simili di firewall). Questa guida documenta un episodio reale: cosa succede quando tu (o uno script automatizzato) sbagli a connetterti in SSH per qualche volta di troppo, e vieni letteralmente "chiuso fuori" dal tuo stesso server.
1. L'Antefatto: Tentativi SSH e "Connection Refused"
Mentre un task automatizzato stava tentando di sincronizzare dei file in produzione (attraverso rsync via SSH), ha commesso un errore fatale: ha effettuato 3 tentativi consecutivi di login usando utenti standard (come root e ubuntu) senza specificare la chiave privata corretta, ricevendo l'errore:
Permission denied (publickey,password).Subito dopo aver tentato la connessione con la chiave corretta, il server ha smesso di rispondere, emettendo il temuto messaggio:
ssh: connect to host xxx.xxx.xxx.xxx port 22: Connection refused
Cosa è successo? Il passaggio istantaneo da "Permission denied" a "Connection refused" è la firma inconfondibile di Fail2Ban o di una regola iptables scattata per mitigare un potenziale attacco brute-force. Il demone di sicurezza ha letto i log di autorizzazione, ha individuato i tentativi falliti in pochi secondi e ha bloccato il traffico in entrata sulla porta 22 per l'IP di origine.
2. Il Problema della Rete Condivisa (Hotspot)
La situazione si è complicata perché l'ambiente di sviluppo locale condivideva la stessa connessione di rete dell'operatore umano (tramite un hotspot mobile).
Di conseguenza, quando Fail2Ban ha bannato l'indirizzo IP, ha bloccato l'intera rete locale di sviluppo. L'operatore si è ritrovato impossibilitato ad accedere alla propria VPS anche inserendo la chiave SSH perfetta.
3. La Soluzione: Il Trucco dell'IP Dinamico
Invece di attendere lo scadere del ban, esiste una scappatoia immediata se si utilizza una connessione cellulare.
È bastato attivare la Modalità Aereo sul telefono che faceva da Hotspot per circa 5 secondi, e poi disattivarla.
Perché funziona? Le reti cellulari usano indirizzi IP dinamici (spesso dietro un Carrier-Grade NAT). Riconnettendosi, l'ISP assegna un indirizzo IP pubblico diverso. Fail2Ban, basandosi esclusivamente sull'indirizzo IP, non riconoscerà più la connessione come minacciosa, permettendo al deploy di concludersi con successo.
Stai sviluppando un'App iOS Nativa o un'Architettura Cloud?
Hai bisogno di consulenza tecnica su Swift Concurrency, Docker backend, notifiche push APNs o pubblicazione su App Store? Parliamone direttamente.
Contattami su WhatsAppDiagnosi sicura: distinguere un ban da un problema SSH
Un errore SSH non dimostra da solo che Fail2Ban abbia bloccato l'indirizzo IP. Prima di cambiare rete o modificare il firewall, annota l'ora esatta, l'indirizzo IP pubblico del client e il messaggio completo del terminale. “Connection timed out”, “Connection refused” e “Permission denied” indicano problemi diversi: il primo può dipendere da routing o filtri silenziosi, il secondo da porta chiusa o servizio non in ascolto, il terzo da autenticazione o permessi. Fare questa distinzione evita di indebolire la sicurezza per risolvere la causa sbagliata.
Controlli dal server, se hai accesso alla console
Usa la console del provider o una sessione amministrativa già aperta, se disponibile. Su sistemi con systemd, controlla lo stato di SSH e Fail2Ban con sudo systemctl status ssh (su alcune distribuzioni il servizio si chiama sshd) e sudo systemctl status fail2ban. Per esaminare i ban gestiti da Fail2Ban, sudo fail2ban-client status mostra le jail attive; sudo fail2ban-client status sshd mostra i dettagli della jail SSH quando si chiama sshd. Il nome della jail può essere diverso, quindi verifica l'output invece di copiare un comando alla cieca.
Per controllare i log, consulta sudo journalctl -u ssh --since "30 minutes ago" oppure il servizio corretto della distribuzione. Anche i log di Fail2Ban possono chiarire quale regola ha attivato il blocco. Non pubblicare log grezzi senza rimuovere IP, nomi utente e altri dati identificativi.
Rimuovere un ban senza disattivare la protezione
Se i log confermano il ban e hai verificato che l'IP sia tuo, rimuovi soltanto quell'indirizzo dalla jail corretta: sudo fail2ban-client set sshd unbanip INDIRIZZO_IP, sostituendo sshd con il nome reale della jail e INDIRIZZO_IP con l'indirizzo verificato. Il comando non va eseguito se non hai confermato la causa. Evita di fermare Fail2Ban, svuotare tutte le regole del firewall o aprire SSH a qualsiasi origine come soluzione rapida.
Prevenzione per deploy automatizzati
- Usa chiavi SSH dedicate, permessi minimi e un utente di deploy non privilegiato.
- Verifica che CI/CD, laptop e VPS usino la chiave corretta prima di ripetere i tentativi.
- Se l'IP cambia spesso, valuta un accesso tramite VPN affidabile o un runner con IP controllato, senza creare whitelist troppo ampie.
- Conserva una console di recupero del provider e documenta il percorso di ripristino prima di modificare firewall o SSH.
- Applica aggiornamenti di sicurezza e limita l'esposizione della porta SSH quando l'architettura lo consente.
Checklist rapida prima di riprendere il deploy
Conferma che la porta sia raggiungibile dalla rete autorizzata, che il servizio SSH sia attivo, che la chiave corrisponda all'utente e che Fail2Ban non mostri un ban attivo. Dopo il ripristino, esegui un solo tentativo di connessione e controlla i log. Se l'accesso continua a fallire, fermati e raccogli l'errore preciso: tentativi ripetuti possono riattivare il ban e rendere la diagnosi più difficile.
Nota: i nomi dei servizi, delle jail e i percorsi dei log variano tra Ubuntu, Debian e altre distribuzioni. Verifica sempre la configurazione effettiva del tuo server e conserva un accesso di emergenza prima di intervenire.