1,200 26/03/2026 07/04/2026 4 min

Diagnosi probabile

Se un server espone SSH su Internet, gli attacchi più comuni sono tentativi ripetuti di login, password deboli, account con troppi privilegi e file privati leggibili da utenti o processi sbagliati. In molti casi il problema non è un singolo bug, ma una combinazione di impostazioni permissive e manutenzione irregolare.

I due approcci più usati sono diversi:

  • Approccio A: hardening SSH “pulito” con chiavi, login disabilitato per root, permessi corretti, aggiornamenti e segreti fuori dal server.
  • Approccio B: hardening + fail2ban, utile quando il server riceve molti tentativi di accesso o non puoi eliminare subito l’uso di password.

Se amministri un VPS poco esposto, spesso basta l’approccio A. Se invece vedi molti tentativi nei log o gestisci accessi da più persone, l’approccio B aggiunge una barriera pratica.

Verifiche immediate

  1. Controlla se SSH accetta ancora password: se sì, l’esposizione agli attacchi è più alta. Verifica il file /etc/ssh/sshd_config e cerca PasswordAuthentication e PermitRootLogin.
  2. Controlla i permessi delle chiavi: ~/.ssh deve essere privato e authorized_keys non deve essere leggibile da altri utenti. Un permesso errato spesso rompe l’accesso o apre un rischio inutile.
  3. Guarda i log di autenticazione: molti Failed password o Invalid user indicano brute force; in quel caso fail2ban ha senso.

Soluzione consigliata passo-passo

Approccio A: scegliere l’hardening essenziale quando hai pochi accessi, usi chiavi SSH e vuoi ridurre la complessità.

  1. Fai un backup del file di configurazione prima di toccarlo: cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak. È il rollback minimo se qualcosa va storto.
  2. Imposta chiavi al posto delle password, disabilita il login root e lascia un utente admin con sudo. Questo riduce molto il rischio senza introdurre servizi extra.
  3. Correggi i permessi delle chiavi: la cartella ~/.ssh deve essere tipicamente 700 e authorized_keys 600. Se i permessi sono troppo larghi, SSH può ignorare la chiave o esporla.
  4. Verifica aggiornamenti di sistema regolari. Su server poco cambiati, il vero punto debole non è solo SSH ma tutto ciò che resta non patchato.
  5. Sposta i segreti fuori dal file manager o dal web root: variabili d’ambiente, file in directory non pubbliche o secret manager sono preferibili a password e token lasciati in chiaro in cartelle servite dal web server.

Approccio B: scegliere fail2ban quando i log mostrano attacchi ripetuti, hai IP dinamici o devi convivere con login a password per un periodo transitorio.

  1. Installa e abilita fail2ban solo dopo aver verificato che SSH accetti correttamente l’accesso con chiave. In questo modo eviti di confondere un blocco legittimo con un problema di configurazione.
  2. Proteggi il servizio SSH con una jail dedicata e una soglia non aggressiva. L’obiettivo è bloccare i tentativi automatici, non tagliarti fuori per un errore umano.
  3. Controlla che il ban colpisca solo il traffico di brute force e non i tuoi IP di lavoro o quelli del provider. Se usi IP fissi, valutali in whitelist con cautela.
  4. Monitora i log di fail2ban: se vedi falsi positivi, meglio alzare la soglia o limitare il filtro invece di lasciare il servizio troppo permissivo.

In pratica: Approccio A è migliore per semplicità, stabilità e meno componenti da mantenere; Approccio B è migliore quando il server è bersagliato o quando la transizione verso le sole chiavi non è ancora completa.

Regola utile: prima togli le cause del rischio, poi aggiungi il blocco automatico. Fail2ban non sostituisce chiavi, permessi corretti e aggiornamenti.

Controlli finali / rollback

  1. Riapri una sessione SSH di test da una finestra separata prima di chiudere quella attuale. Se la nuova sessione entra, la modifica è valida.
  2. Verifica che root non possa più entrare direttamente e che l’utente admin possa usare sudo. Questo conferma il principio del least privilege.
  3. Se qualcosa si rompe, ripristina /etc/ssh/sshd_config dal backup e riavvia il demone solo dopo aver ricontrollato sintassi e accesso di test.
  4. Se usi fail2ban, controlla che i ban non colpiscano il tuo IP di manutenzione. In caso contrario, rimuovi il ban e correggi la jail prima di continuare.

Scelta rapida: server piccolo e accessi pochi = hardening essenziale; server esposto o sotto scansione continua = hardening essenziale più fail2ban.