Come mettere in sicurezza SSH su un VPS

Perché SSH è la prima priorità per il hardening

SSH è lo strumento utilizzato per controllare il server. Per questo motivo, è la serratura che ogni attaccante tenta per prima. Non appena un VPS è online, gli scanner iniziano a tentare username e password sulla port 22. È possibile osservare questi tentativi nei log dopo pochi minuti. Il hardening di SSH consiste nel rimuovere gli elementi che gli attaccanti possono indovinare: disabilitare completamente il login tramite password, disabilitare il login come root e consentire solo l'accesso tramite chiavi crittografiche. Una volta completata questa procedura, i tentativi continui falliranno, poiché non ci sarà alcuna password da trovare.

Questo presuppone che SSH sia già funzionante. Se è possibile effettuare il login, è possibile procedere con il hardening. Eseguire i passaggi in ordine e mantenere aperta la sessione corrente finché una nuova sessione non risulta funzionante, per evitare di rimanere bloccati fuori dal sistema in caso di errori.

Step 1: Verificare il funzionamento dell'autenticazione tramite chiave

L'autenticazione tramite chiave sostituisce la password con una coppia di chiavi: una chiave privata che rimane sul computer locale e una chiave pubblica da inserire sul server. Il server verifica il possesso della chiave privata senza che questa lasci mai la macchina locale. Prima di disabilitare le password, confermare il funzionamento delle chiavi per evitare di rimanere bloccati fuori dal sistema.

Sul proprio computer, creare una chiave se non se ne possiede già una:

ssh-keygen -t ed25519

Copiare la chiave pubblica sul server:

ssh-copy-id user@your-server

Aprire quindi una nuova sessione SSH. Se l'accesso avviene senza richiedere la password, la chiave funziona ed è possibile disabilitare le password in sicurezza. Se non si ha esperienza con le chiavi o si utilizzano più computer, concetti base della gestione delle chiavi SSH spiega il modello completo: una chiave per ogni dispositivo, i permessi richiesti da sshd e come revocare una chiave in caso di smarrimento del laptop.

Step 2: Hardening sshd con un file drop-in

Non modificare direttamente /etc/ssh/sshd_config. Ubuntu 24.04 legge i file drop-in da /etc/ssh/sshd_config.d/; un file di piccole dimensioni in questa directory è più pulito, persiste durante gli upgrade dei pacchetti ed è facile da rimuovere in caso di problemi. Il nome è importante: sshd mantiene il primo valore letto per ogni impostazione; le immagini cloud di Ubuntu includono 50-cloud-init.conf con PasswordAuthentication yes in questa directory. Rinomina il tuo file 00- affinché venga elaborato prima dell'altro e abbia la precedenza; un file 99- viene ignorato senza errori. Creane uno:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Inserisci questo contenuto in:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

Ogni riga chiude una porta di accesso. PasswordAuthentication no è la più importante: disabilitando le password, un attacco brute-force non ha nulla da tentare. KbdInteractiveAuthentication no chiude un secondo percorso basato su password. PermitRootLogin no significa che un attaccante deve conoscere il tuo username e possedere la tua chiave, invece di puntare solo all'unico account predefinito, root, presente su ogni sistema.

Step 3: Test the config, then reload

Verifica la configurazione per eventuali errori prima di applicarla. Questo evita che un errore di battitura interrompa il servizio:

sudo sshd -t

Se il comando non restituisce output, la configurazione è valida. Ricarica SSH:

sudo systemctl reload ssh

Verifica quindi le impostazioni effettivamente utilizzate da sshd. Questo serve a individuare eventuali file di configurazione aggiuntivi che sovrascrivono le tue modifiche:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Entrambi i risultati devono indicare no. Ora, senza chiudere la sessione corrente, apri una nuova sessione da un altro terminale. Se l'accesso avviene tramite la tua chiave, l'operazione è completata. Se si verificano errori, la prima sessione è ancora aperta per permetterti di correggere il problema. Questa sovrapposizione funge da rete di sicurezza; non saltare mai questo passaggio.

Step 4: La porta non standard opzionale

Spostare SSH dalla porta 22 a una porta come la 2222 non aumenta la sicurezza reale, poiché un attaccante determinato esegue scansioni su tutte le porte. Questa operazione riduce il rumore nei log, dato che la maggior parte degli scanner automatizzati tenta solo la porta 22. Se desideri procedere, aggiungi Port 2222 al tuo file di configurazione, apri la nuova porta nel firewall, esegui sudo systemctl daemon-reload && sudo systemctl restart ssh.socket e connettiti tramite ssh -p 2222. Su Ubuntu 24.04, ssh.socket gestisce la porta in ascolto; pertanto, un semplice reload ssh mantiene sshd sulla porta 22; è necessario riavviare il socket per applicare la nuova porta. Considera questa operazione come una misura di ordine, non di protezione.

Step 5: Aggiungere ulteriori livelli di difesa

Le chiavi SSH protette costituiscono la base; sopra di esse si aggiungono altri due livelli di sicurezza.

Fail2ban monitora i log e banna gli indirizzi che falliscono ripetutamente gli accessi. Questo riduce il rumore generato dagli scanner e blocca gli attacchi tempestivamente. Si integra perfettamente con l'autenticazione tramite sola chiave: vedi Fail2ban su Ubuntu per bloccare attacchi SSH.

Un metodo ancora più efficace consiste nel rimuovere SSH da Internet. Se si utilizza SSH tramite VPN WireGuard e si limita il firewall sulla porta 22 al solo tunnel, nessun utente esterno alla VPN può raggiungere il servizio. In questo modo, il brute-force non è solo difficile, ma diventa impossibile. Tutto ciò richiede un firewall configurato con policy default-deny, come descritto in configurazione di UFW sul VPS.

SSH è solo un passaggio di una checklist più ampia: i primi 10 minuti su un nuovo VPS elenca i passaggi in ordine cronologico, mentre aggiornamenti di sicurezza automatici su Ubuntu mantiene il sistema aggiornato nel tempo.

FAQ

Come disabilitare il login tramite password per SSH su Ubuntu 24.04?

Crea un file drop-in in /etc/ssh/sshd_config.d/00-hardening.conf (il prefisso 00 garantisce che venga elaborato prima di 50-cloud-init.conf, il cui PasswordAuthentication yes altrimenti avrebbe la precedenza, poiché sshd utilizza il primo valore letto) contenente PasswordAuthentication no e KbdInteractiveAuthentication no. Esegui sudo sshd -t per verificare la configurazione, quindi sudo systemctl reload ssh. Prima di fare affidamento sulla nuova configurazione, conferma che il login tramite chiave funzioni in una nuova sessione. Modificare un file drop-in invece di sshd_config permette di mantenere le impostazioni durante gli aggiornamenti dei pacchetti ed è facile da annullare.

È consigliabile disabilitare il login root via SSH?

Sì. Imposta PermitRootLogin no per impedire l'accesso diretto come root. Accedi con il tuo utente standard e usa sudo per i compiti di amministrazione. L'utente root è presente su ogni sistema Linux; lasciarlo accessibile fornisce a un attaccante un nome utente noto da colpire. Disabilitarlo costringe l'attaccante a conoscere il nome del tuo account e a possedere la tua chiave.

Cambiare la porta SSH aumenta la sicurezza del server?

Non in modo significativo. Spostarsi dalla porta 22 nasconde il server agli scanner automatici che interrogano solo la porta 22, riducendo il rumore nei log. Tuttavia, un attaccante reale scansiona ogni porta e la troverà comunque. L'autenticazione tramite chiave è l'unico metodo efficace per prevenire le intrusioni. Se cambi la porta, apri prima la nuova porta nel firewall e poi esegui sudo systemctl daemon-reload && sudo systemctl restart ssh.socket; su Ubuntu 24.04 il socket gestisce il listener, quindi un semplice reload lascia sshd sulla porta 22.

È necessario Fail2ban se uso le chiavi SSH?

È opzionale ma rimane utile. Con l'autenticazione tramite chiave, il brute-force delle password non può avere successo, quindi Fail2ban non è lo strumento che blocca gli attaccanti. Fail2ban limita la frequenza dei tentativi falliti da un singolo indirizzo, riducendo il rumore degli scanner nei log ed eliminando tempestivamente i trasgressori ripetuti; un attacco lento e distribuito rimane comunque sotto la soglia di ban. Utilizzalo insieme all'autenticazione tramite chiave e, idealmente, mantieni SSH dietro una VPN.

Come recuperare l'accesso se rimango bloccato fuori da SSH?

Usa la console web del tuo provider, che accede al server tramite una connessione seriale o VNC che non passa per SSH. Da lì puoi effettuare il login, correggere il file drop-in sshd e ricaricare il servizio. Questo è il motivo per cui è necessario testare una nuova configurazione SSH in una seconda sessione prima di chiudere la prima, e perché l'autenticazione tramite chiave deve essere già funzionante prima di disabilitare le password.