Serve ancora fail2ban se ho disattivato la password su SSH?

La domanda è posta male

Se avete amministrato anche soltanto una VPS saprete certamente che quasi tutte le guide di hardening arrivano prima o poi allo stesso punto: installare fail2ban, configurare la jail sshd ed andare avanti come se la faccenda fosse chiusa. Io invece partirei dalla domanda opposta, ovvero CONTRO COSA dovrebbe proteggermi fail2ban se su SSH non esiste più una password da indovinare? Se l'autenticazione effettiva accetta soltanto chiavi pubbliche, un bot che prova root con 123456, admin con password od altre combinazioni del genere non sta affrontando una password molto difficile, sta proponendo un metodo di autenticazione che il server non deve proprio accettare. In quel caso fail2ban può certamente ridurre il rumore, tagliare connessioni ripetute provenienti dagli stessi indirizzi ed alleggerire qualcosa dopo che un indirizzo è stato bannato, ma non sta chiudendo la porta attraverso la quale quel brute force sarebbe potuto entrare. Quella porta l'avete già murata.

C'è però un dettaglio abbastanza importante che spesso viene saltato, perché PasswordAuthentication no DA SOLO non significa necessariamente che ogni forma di autenticazione assimilabile ad una password sia sparita. OpenSSH distingue password da keyboard-interactive ed il valore effettivo di KbdInteractiveAuthentication va controllato; inoltre PermitRootLogin prohibit-password disabilita password e keyboard-interactive per root, non automaticamente per tutti gli altri utenti. Prima di dire che il brute force delle password non può riuscire io quindi non guarderei soltanto due righe del file sshd_config, guarderei l'effettiva configurazione che sshd ha caricato, compresi eventuali file Include. Il punto di partenza deve essere questo: PasswordAuthentication no, KbdInteractiveAuthentication no se non vi serve per un secondo fattore ed autenticazione pubblica realmente funzionante. Solo dopo ha senso discutere se la jail SSH di fail2ban stia ancora comprando sicurezza oppure soprattutto silenzio.

Cosa c'è davvero nei miei log

Qui i numeri contano molto più delle impressioni. Nel controllo che ho fatto sulla mia VPS il 21 agosto 2026 fail2ban aveva una sola jail attiva, sshd, ed in quel preciso momento la catena del firewall conteneva un solo indirizzo bannato da quella jail; è un dato reale, ma NON lo trasformo artificialmente in un numero di tentativi al giorno perché una fotografia del firewall non dice quante connessioni siano arrivate nelle ventiquattro ore precedenti. Per sapere se sto ricevendo cinquanta, cinquemila o ventimila tentativi bisogna contarli nei log nello stesso intervallo, distinguere gli IP e capire soprattutto che cosa abbiano effettivamente tentato. Un Invalid user, un Failed publickey, una negoziazione abortita ed un vero tentativo di password non sono la stessa cosa, ed ammassarli tutti sotto la parola ATTACCHI produce numeri impressionanti ma tecnicamente abbastanza poveri.

Anche la porta cambia il rumore, non la sostanza. Lasciare SSH sulla 22 significa stare in mezzo alla scansione automatica di Internet e spostarlo su una porta insolita può far crollare parecchio il numero delle righe nei log, ma non trasforma una chiave forte in una chiave più forte e non sostituisce una misura di sicurezza. Serve soprattutto ad evitare una quantità di spazzatura automatica. Io quindi preferisco misurare il traffico prima e dopo, tenere il dato per qualche giorno ed arrivare ad una conclusione basata su ciò che succede davvero sulla macchina, non sul numero spaventoso preso da una guida.

Cosa può fare fail2ban quando la password non esiste

Fail2ban fa esattamente quello che promette: legge log, applica espressioni regolari, conta gli eventi che corrispondono ad un filtro e quando una sorgente supera una soglia esegue un'azione, normalmente aggiungendo quell'indirizzo ad una regola del firewall per un certo periodo. Se il metodo password è disabilitato davvero, quindi, fail2ban non rende impossibile un login con password perché quel login era già impossibile; può però troncare prima le successive connessioni provenienti dallo stesso IP, ridurre il rumore del journal ed in alcuni scenari togliere un po' di lavoro ad sshd. Non è zero utilità, semplicemente è UN'UTILITÀ DIVERSA da quella che gli viene attribuita quando lo si presenta come barriera contro il brute force delle password.

Ed è qui che per me cambia la decisione. Con sole chiavi pubbliche la minaccia importante non è più qualcuno che indovina una password a forza di tentativi, ma la compromissione della chiave privata, una chiave lasciata senza protezione dove non dovrebbe stare, un account autorizzato male, una vulnerabilità di sshd oppure una configurazione che permette un metodo di autenticazione che credevamo spento. Un ban temporaneo dell'IP non risolve nessuna di queste cose. Può essere un ulteriore strato operativo, certo, ma non gli attribuirei un ruolo che in quella configurazione non ha.

Il costo che nessuno conta

Il consumo di CPU e RAM di fail2ban su una VPS normale può essere piccolo, a volte quasi irrilevante, ma il numero serio è quello misurato sulla propria macchina e non ho intenzione di inventarne uno per rendere più bella una frase. Il costo che mi interessa di più è architetturale: c'è un processo che deve osservare eventi prodotti anche da traffico remoto, passarli attraverso filtri basati su espressioni regolari e comandare meccanismi di ban del firewall, normalmente con privilegi elevati. Detto così, per me la conclusione è abbastanza semplice: se quel processo sta eliminando una minaccia reale lo tengo volentieri, se sta soltanto facendo sparire righe fastidiose dal log voglio almeno sapere perché lo sto tenendo.

E non è soltanto un ragionamento teorico. Il 15 agosto 2026 il progetto Fail2Ban ha pubblicato un advisory per una ReDoS nel filtro domino-smtp: un nome utente SMTP costruito appositamente poteva finire nel log ed obbligare una regex vulnerabile ad impiegare da secondi fino ad un tempo enormemente superiore per elaborare una singola riga, bloccando il thread di quella jail; il filtro era disabilitato di default, il problema non riguardava la jail sshd ed è stato corretto nella versione 1.1.1, quindi NON sto dicendo che fail2ban su SSH sia vulnerabile per questo motivo. Sto dicendo una cosa molto più banale: un componente che interpreta input derivato dalla rete ed agisce sul firewall è software, ed ogni software aggiunto ha codice, configurazione e possibili errori propri. La sicurezza non consiste nell'installare più roba possibile, consiste nel sapere quale rischio ogni pezzo sta riducendo.

Il giorno in cui fail2ban può bannare anche te

Non mi invento l'aneddoto del giorno in cui mi sono chiuso fuori se quel giorno non c'è stato, ma la possibilità è tutt'altro che teorica. Il rischio esiste ogni volta che una jail può riconoscere come ostili anche i vostri errori, ma qui c'è una precisazione interessante: il filtro sshd attuale di Fail2Ban usa per default publickey = nofail, quindi un Failed publickey di un utente valido non viene normalmente contato come un fallimento da bannare; la situazione cambia con filtri personalizzati, modalità più aggressive od altri eventi che rientrano nelle regex della jail. In quei casi basta fare abbastanza tentativi che il filtro considera fallimenti ed il risultato può essere che il firewall cominci a respingere proprio voi. A quel punto la differenza fra un inconveniente ed una serata rovinata la fanno l'accesso alla console del provider, una sessione già aperta od una ignoreip configurata con criterio; mettere però il proprio IP dinamico in whitelist soltanto per paura di essere bannati può diventare a sua volta una falsa sicurezza, perché domani quell'indirizzo potrebbe non essere più vostro.

Il problema non è che fail2ban sia inaffidabile, anzi sta facendo esattamente quello che gli avete chiesto. Il problema è il solito dei sistemi automatici: la regola vede eventi, non conosce le vostre intenzioni. Se il suo lavoro su SSH è diventato soltanto quello di zittire bot che non avrebbero comunque potuto autenticarsi, allora anche questo piccolo rischio operativo entra nel conto.

Cosa tengo su SSH al posto suo

La prima cosa che tengo è una configurazione SSH che non si limita ad essere scritta bene ma che verifico nel suo valore EFFETTIVO, perché sshd può caricare Include ed opzioni distribuite in più file. PubkeyAuthentication deve essere attivo, PasswordAuthentication deve essere no e se non uso keyboard-interactive per MFA imposto anche KbdInteractiveAuthentication no; per root preferisco PermitRootLogin prohibit-password oppure, quando non mi serve proprio l'accesso diretto di root, PermitRootLogin no. Poi guardo MaxAuthTries e MaxStartups, perché sono meccanismi interni ad OpenSSH che limitano rispettivamente i tentativi per connessione e la pressione delle connessioni non ancora autenticate, senza affidare ad un parser esterno il compito di decidere chi bandire.

Non considero invece il cambio della porta una misura crittografica, perché non lo è. Può essere utile per togliere una grande parte del rumore automatico dai log, rendere più leggibile ciò che resta ed evitare una parte delle scansioni più stupide, ma chi sta cercando davvero il servizio trova anche una porta diversa dalla 22. Se posso restringere SSH ad indirizzi o reti realmente stabili lo faccio a livello firewall, se non posso preferisco non costruire allowlist fragili che mi chiuderanno fuori appena cambia la connettività. E soprattutto proteggo la chiave privata, perché in un sistema key-only È QUELLA la credenziale che conta.

Dove invece lo lascio acceso

Fail2ban continua ad avere perfettamente senso nei punti in cui esiste ancora qualcosa che un attaccante può provare ripetutamente ed il fallimento lascia una traccia affidabile. SMTP con SASL, IMAP, pannelli amministrativi, VPN basate su credenziali ed applicazioni web possono essere casi molto più interessanti della mia SSH key-only, perché lì rallentare od interrompere centinaia di tentativi consecutivi significa davvero ridurre una superficie di brute force. Anche un pannello PrestaShop può rientrare nel discorso, ma soltanto se dispongo di un evento di log affidabile che distingua il login fallito dal normale traffico; non basta prendere alla cieca una richiesta verso la pagina amministrativa e chiamarla attacco.

In pratica non disinstallerei fail2ban per principio e non lo installerei per religione. Lo lascerei dove esiste una password, un token provabile ripetutamente od un pattern di abuso che il filtro riesce a riconoscere bene, mentre su SSH con sole chiavi mi chiederei se la riduzione del rumore e delle connessioni ripetute valga il processo, le regole ed il rischio operativo aggiuntivo. È una distinzione piccola, ma cambia completamente il modo di ragionare sulla sicurezza.

Verificarlo sulla tua macchina in cinque minuti

Prima controllo quello che sshd sta usando davvero, non quello che penso di avere scritto nei file:

`bash

sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|permitrootlogin|authenticationmethods|maxauthtries|maxstartups|port) '

`

Poi guardo fail2ban, le jail attive ed in particolare quella SSH:

`bash

sudo fail2ban-client status

sudo fail2ban-client status sshd

`

Per contare il rumore delle ultime ventiquattro ore uso journalctl su entrambi i nomi di unità più comuni e separo almeno gli eventi SSH sospetti dal resto:

`bash

sudo journalctl -u ssh -u sshd --since '24 hours ago' --no-pager | grep -E 'Invalid user|Failed password|Failed publickey|Connection closed by (invalid|authenticating) user|Unable to negotiate' | wc -l

`

Per farmi un'idea degli IPv4 distinti nello stesso intervallo:

`bash

sudo journalctl -u ssh -u sshd --since '24 hours ago' --no-pager | grep -E 'Invalid user|Failed password|Failed publickey|Connection closed by (invalid|authenticating) user|Unable to negotiate' | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | sort -u | wc -l

`

Poi misuro il processo invece di attribuirgli un consumo preso da Internet:

`bash

ps -C fail2ban-server -o pid,%cpu,%mem,rss,etime,cmd

sudo systemctl show fail2ban -p MemoryCurrent -p CPUUsageNSec

`

Ed infine guardo quanto sta effettivamente aggiungendo al firewall e quanto spazio stanno occupando trenta giorni di eventi SSH:

`bash

sudo nft list ruleset 2>/dev/null | wc -c

sudo iptables-save 2>/dev/null | wc -c

sudo journalctl -u ssh -u sshd --since '30 days ago' --no-pager | wc -c | awk '{printf "%.2f MB\n",$1/1048576}'

`

Fatti questi controlli la domanda iniziale cambia parecchio, perché non è più se fail2ban sia un programma buono o cattivo, ma se NELLA VOSTRA CONFIGURAZIONE stia fermando qualcosa che potrebbe davvero entrare oppure stia soltanto rendendo più silenzioso un muro sul quale i bot continuano a bussare!