Come proteggere SSH su un VPS

Perché SSH è il primo servizio da proteggere

SSH è il metodo con cui si amministra il server. Per questo è il primo punto che ogni attaccante tenta di compromettere. Non appena un VPS è online, gli scanner iniziano a provare nomi utente e password sulla porta 22. Nei log è possibile monitorare questi tentativi già dopo pochi minuti. Proteggere SSH significa eliminare ciò che gli attaccanti possono indovinare: disabilitare completamente l’accesso con password, disabilitare l’accesso dell’account root e consentire soltanto l’autenticazione tramite chiavi crittografiche. In questo modo i tentativi continui non possono andare a buon fine, perché non esiste alcuna password da individuare.

Questa procedura presuppone che SSH sia già operativo. Se è possibile accedere, è possibile proteggerlo. Eseguire i passaggi nell’ordine indicato e mantenere aperta la sessione corrente finché una nuova sessione non funziona, così un errore non impedisce mai l’accesso al server.

Passaggio 1: assicurati prima che l'autenticazione tramite chiave funzioni

L'autenticazione tramite chiave sostituisce una password con una coppia di chiavi: una chiave privata che rimane sul tuo computer e una chiave pubblica che copi sul server. Il server verifica che possiedi la chiave privata senza che questa lasci mai il tuo computer. Prima di disabilitare le password, verifica che le chiavi funzionino. In caso contrario, potresti non riuscire più ad accedere al server.

Sul tuo computer, crea una chiave se non ne hai già una:

ssh-keygen -t ed25519

Copia la parte pubblica sul server:

ssh-copy-id user@your-server

Quindi apri una nuova sessione SSH. Se puoi accedere senza che venga richiesta una password, la chiave funziona e puoi disabilitare le password. Se l'accesso viene bloccato con Permission denied (publickey), quell'errore nasconde cinque problemi diversi e l'output di ssh -v indica quale si è verificato, prima che tu modifichi altro. Se non hai mai usato le chiavi o utilizzi più di un computer, nozioni di base sulla gestione delle chiavi SSH spiega il modello completo: una chiave per dispositivo, i permessi richiesti da sshd e come revocare una chiave quando perdi un laptop.

Passaggio 2: rafforzare 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ù ordinato, resta valido dopo gli aggiornamenti dei pacchetti ed è facile da rimuovere se qualcosa non funziona. Il nome è importante: sshd mantiene il primo valore letto per ogni impostazione e le immagini cloud di Ubuntu forniscono 50-cloud-init.conf con PasswordAuthentication yes in questa directory. Assegna al file il nome 00-, in modo che venga ordinato prima di quello e abbia effetto; un file 99- viene ignorato senza messaggi. Creane uno:

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

Inserisci quanto segue:

# 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 possibile via di accesso. PasswordAuthentication no è l'impostazione principale: con le password disabilitate, un attacco brute force non ha password da provare. KbdInteractiveAuthentication no chiude una seconda modalità di autenticazione basata sulla password. PermitRootLogin no obbliga un attaccante a conoscere il nome utente e a possedere la tua chiave, invece di prendere di mira soltanto l'unico account, root, presente su ogni sistema.

Passaggio 3: verifica la configurazione, quindi ricaricala

Verifica la configurazione per individuare gli errori prima di applicarla, così un refuso non può interrompere il servizio:

sudo sshd -t

Se non stampa nulla, la configurazione è valida. Ricarica SSH:

sudo systemctl reload ssh

Controlla quindi le impostazioni effettivamente utilizzate da sshd, così puoi individuare un drop-in che è stato ignorato a favore di un altro file:

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

Entrambi dovrebbero restituire no. Ora, senza chiudere la sessione corrente, aprine una completamente nuova da un altro terminale. Se l'accesso avviene con la tua chiave, hai terminato. Se qualcosa non funziona, la prima sessione è ancora aperta per consentirti di correggere il problema. Questa sovrapposizione è la rete di sicurezza, quindi non saltare mai questo passaggio.

Passaggio 4: la porta non standard opzionale

Spostare SSH dalla porta 22 a una porta come 2222 non lo rende più sicuro in senso sostanziale, perché un attaccante determinato esegue la scansione di tutte le porte. Riduce però il rumore nei log, perché la maggior parte degli scanner automatici prova soltanto la porta 22. Se vuoi usare questa configurazione, aggiungi Port 2222 al file drop-in, autorizza prima la nuova porta nel firewall, quindi esegui sudo systemctl daemon-reload && sudo systemctl restart ssh.socket e connettiti con ssh -p 2222. Su Ubuntu 24.04, ssh.socket gestisce la porta in ascolto, quindi un semplice reload ssh lascia sshd sulla porta 22; per applicare la nuova porta è necessario riavviare il socket. Considerala una misura di ordine, non di protezione.

Passaggio 5: aggiungere ulteriori difese

Le chiavi SSH protette sono la base, ma su di esse si aggiungono altri due livelli.

Fail2ban monitora i log e blocca gli indirizzi che continuano a fallire l'autenticazione. In questo modo riduce il rumore degli scanner e li esclude rapidamente. Si abbina naturalmente all'autenticazione tramite sole chiavi: consulta Configurare Fail2ban su Ubuntu per bloccare gli attacchi SSH.

Una protezione ancora più efficace consiste nel mantenere SSH completamente fuori da Internet pubblico. Se metti SSH dietro una VPN WireGuard e limiti la porta 22 al tunnel tramite il firewall, chiunque si trovi fuori dalla VPN non può nemmeno raggiungerla. I tentativi di forza bruta diventano quindi impossibili, non soltanto più difficili. Questa configurazione presuppone un firewall con criterio default-deny, descritto in Configurare UFW sul VPS.

SSH è solo una voce di una checklist più ampia: i primi 10 minuti su un nuovo VPS ordina i passaggi, mentre gli aggiornamenti di sicurezza automatici su Ubuntu mantengono il server aggiornato. Chiudere l'accesso SSH non protegge i servizi che si trovano dietro di esso. Se lo stesso VPS esegue un password vault, eseguire un hardening di Vaultwarden copre i due aspetti che l'autenticazione tramite chiavi non protegge: il token amministrativo e il file di backup.

FAQ

Come disabilito l'accesso con password a SSH su Ubuntu 24.04?

Create un file drop-in in /etc/ssh/sshd_config.d/00-hardening.conf. Il prefisso 00 fa sì che venga ordinato prima di 50-cloud-init.conf, il cui PasswordAuthentication yes avrebbe altrimenti la precedenza, perché sshd mantiene il primo valore letto. Inserite PasswordAuthentication no e KbdInteractiveAuthentication no, eseguite sudo sshd -t per verificarlo, quindi sudo systemctl reload ssh. Confermate che l'accesso con chiave funzioni in una nuova sessione prima di fare affidamento su questa configurazione. La modifica di un file drop-in invece di sshd_config resiste agli aggiornamenti dei pacchetti ed è facile da annullare.

Devo disabilitare l'accesso di root tramite SSH?

Sì. Impostate PermitRootLogin no, in modo che nessuno possa accedere direttamente come root. Accedete con il vostro utente normale e usate sudo per le attività amministrative. root esiste su ogni sistema Linux, quindi lasciarlo raggiungibile fornisce a un attaccante un nome utente noto da prendere di mira. Disabilitandolo, l'attaccante deve conoscere il nome del vostro account e possedere la vostra chiave.

Cambiare la porta SSH rende il server più sicuro?

Non in modo significativo. Spostarsi dalla porta 22 vi nasconde agli scanner superficiali che verificano soltanto la 22 e riduce il rumore nei log, ma un attaccante reale esegue la scansione di tutte le porte e la individua comunque. L'autenticazione basata solo su chiavi è ciò che impedisce realmente le intrusioni. Se cambiate la porta, aprite prima quella nuova nel firewall, quindi eseguite sudo systemctl daemon-reload && sudo systemctl restart ssh.socket. Su Ubuntu 24.04 è il socket a gestire l'ascolto e un semplice reload lascia sshd in ascolto sulla porta 22.

Mi serve Fail2ban se uso le chiavi SSH?

È facoltativo, ma resta utile. Con l'autenticazione basata solo su chiavi, i tentativi di indovinare la password non possono riuscire, quindi Fail2ban non è ciò che tiene fuori gli attaccanti. Limita la frequenza dei tentativi ripetuti provenienti da un singolo indirizzo, riducendo il rumore degli scanner nei log e bloccando in anticipo i responsabili delle violazioni ripetute; un attacco lento e distribuito resta comunque sotto la soglia di ban. Eseguite Fail2ban insieme all'autenticazione con chiave e, idealmente, mantenete SSH dietro una VPN.

Come posso recuperare l'accesso se mi blocco fuori da SSH?

Usate la console web del provider, che raggiunge il server tramite una connessione seriale o VNC non basata su SSH. Da lì potete accedere, correggere il file drop-in sshd e ricaricare il servizio. È esattamente per questo che dovete testare una nuova configurazione SSH in un secondo terminale prima di chiudere la prima sessione e che l'autenticazione con chiave deve già funzionare prima di disabilitare le password.