Hardening SSH: checklist per mettere in sicurezza un VPS Linux

1. Aggiorna il sistema e attiva gli aggiornamenti di sicurezza automatici

Per prima cosa installa gli aggiornamenti in sospeso: apt update aggiorna gli elenchi dei pacchetti e apt upgrade installa le nuove versioni. [1]

sudo apt update
sudo apt upgrade

Su Ubuntu gli aggiornamenti di sicurezza si installano automaticamente tramite il pacchetto unattended-upgrades, presente di default ed eseguito una volta al giorno. Entrambi i valori in /etc/apt/apt.conf.d/20auto-upgrades devono essere «1», e una simulazione (dry run) mostra cosa verrebbe installato. [1]

cat /etc/apt/apt.conf.d/20auto-upgrades
sudo unattended-upgrade --dry-run -v

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

unattended-upgrades non riavvia il sistema da solo, perché per impostazione predefinita Unattended-Upgrade::Automatic-Reboot vale false: quando un aggiornamento lo richiede, riavvia manualmente. [1] Su Debian 12, se mancano il pacchetto o il file, installa unattended-upgrades e crea il file con le due righe qui sopra.

2. Crea un utente sudo diverso da root

Svolgi le attività di amministrazione con un utente nominativo e sudo, che chiede la password di quell’utente, non quella di root. Ai membri del gruppo sudo questo comando dà l’accesso root completo. [2]

sudo adduser deploy
sudo adduser deploy sudo

adduser chiede una password e alcuni dati facoltativi. [2] Scegli una password lunga: SSH userà le chiavi, ma sudo la chiederà comunque. Poi verifica l’account: sudo whoami deve restituire root.

su - deploy
sudo whoami

Su Debian 12, se il comando sudo non c’è, installalo prima come root con apt install sudo.

3. Genera una chiave ed25519 sul tuo computer

Crea la coppia di chiavi sul tuo computer, non sul server. Ubuntu consiglia il tipo ed25519 perché ha chiavi più corte e un costo computazionale minore, e ssh-keygen chiede una passphrase che protegge la chiave privata. [3]

ssh-keygen -t ed25519

Mantieni il nome predefinito del file. La chiave privata è ~/.ssh/id_ed25519; la chiave pubblica, quella da copiare sui server, è ~/.ssh/id_ed25519.pub. [3]

Su Windows esegui lo stesso comando in PowerShell: la coppia di chiavi viene salvata nella cartella .ssh del tuo profilo utente. Microsoft sconsiglia di lasciare vuota la passphrase e avverte che chiunque entri in possesso della chiave privata può accedere con la tua identità. [4]

ssh-keygen -t ed25519

4. Copia la chiave pubblica sul server

Su Linux e macOS, ssh-copy-id aggiunge in coda la tua chiave pubblica al file ~/.ssh/authorized_keys dell’utente sul server. [3]

ssh-copy-id deploy@203.0.113.10

Nella guida di Microsoft, invece, le chiavi si copiano con PowerShell o con scp. [4] Per un server Linux, questa riga aggiunge la tua chiave e rende la cartella e il file scrivibili solo da te:

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Prima di accettare un accesso, sshd controlla questi permessi tramite l’opzione StrictModes, attiva di default. [5] Poi esegui ssh deploy@203.0.113.10 in un nuovo terminale: dovresti entrare senza la password dell’account. Se non funziona, segui in tempo reale il log SSH del server mentre riprovi: [3]

sudo journalctl -fu ssh.service

5. Scrivi le impostazioni in un file drop-in

Su Ubuntu, /etc/ssh/sshd_config inizia con Include /etc/ssh/sshd_config.d/*.conf e, per la maggior parte delle impostazioni, OpenSSH usa il primo valore che legge: i file di quella cartella hanno quindi la precedenza sul file principale. [3] I file inclusi vengono letti in ordine lessicografico e, per ogni direttiva, vale il primo valore ottenuto da sshd, [5] quindi chiama il tuo file 00-hardening.conf.

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers deploy

Dal manuale di sshd_config:

• PermitRootLogin no impedisce a root di accedere tramite SSH. Il valore predefinito, prohibit-password, rifiuta le password per root ma accetta ancora le chiavi. [5]
• PasswordAuthentication no disattiva gli accessi con password, che di default sono consentiti. [5]
• KbdInteractiveAuthentication no disattiva gli accessi keyboard-interactive, un metodo distinto, anch’esso attivo di default; il suo vecchio nome è ChallengeResponseAuthentication. [5]
• AllowUsers deploy (opzionale) consente l’accesso solo agli utenti elencati. A differenza della maggior parte delle direttive, ogni riga AllowUsers si aggiunge all’elenco. [5] Scrivi il nome senza errori, altrimenti non entra nessuno.

Da qui in avanti tratta l’account sudo come se fosse root: secondo le note del pacchetto openssh di Ubuntu, di fronte agli attacchi esterni qualsiasi account da cui puoi ottenere i privilegi di root equivale a root. [6] Su Debian 12, verifica prima la riga Include con grep -n Include /etc/ssh/sshd_config.

6. Controlla che nessun file riattivi l’accesso con password

Visto che vale il primo valore, qualsiasi file che nell’ordinamento precede il tuo ha la meglio. Cerca nella cartella:

ls /etc/ssh/sshd_config.d/
sudo grep -riE 'passwordauthentication|kbdinteractive|permitrootlogin|allowusers' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Sulle immagini cloud, cloud-init scrive le impostazioni SSH che gestisce in /etc/ssh/sshd_config.d/50-cloud-init.conf ogni volta che sshd_config include quella cartella. [7] Se quel file contiene PasswordAuthentication yes, prevale su tutti i file che lo seguono nell’ordinamento: per questo il nome del tuo inizia con 00. Cambia il valore in no anche lì, così i file non si contraddicono.

7. Verifica la configurazione e riavvia SSH

Verifica i file prima di riavviare: un’impostazione sbagliata può impedire l’avvio di sshd, e SSH potrebbe essere il tuo unico modo per entrare nel server. [3]

sudo sshd -t
sudo systemctl restart ssh.service

Se sshd -t segnala qualcosa, correggilo prima di riavviare. Dopo il riavvio, tieni aperta la sessione e prova da un secondo terminale:

ssh deploy@203.0.113.10
ssh root@203.0.113.10

Il primo accesso deve riuscire e il secondo deve essere rifiutato. Se invece non riesci ad accedere con il tuo utente, annulla la modifica nella sessione aperta e controlla il log SSH come nel passaggio 4. [3]

8. Cambia la porta su Ubuntu 24.04 (opzionale)

Su Ubuntu 24.04 è ssh.socket a restare in ascolto sulla porta 22, tramite l’attivazione via socket di systemd. Un generatore trasforma le righe Port di sshd_config e dei suoi file drop-in in impostazioni del socket, quindi dopo un cambio di porta devi ricaricare systemd e riavviare ssh.socket. [6]

Visto che sshd accetta più righe Port, [5] tieni la 22 mentre provi la nuova porta:

Port 22
Port 2222

sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Prova la nuova porta da un secondo terminale. Poi elimina Port 22, ripeti i tre comandi e usa la porta 2222 nei passaggi 9 e 10.

ssh -p 2222 deploy@203.0.113.10

Su Debian 12, controlla prima se il socket è in uso. Se è inattivo, per applicare la modifica basta riavviare il servizio.

systemctl is-active ssh.socket
sudo systemctl restart ssh.service

9. Consenti SSH in UFW, poi attivalo

UFW viene installato disattivato e, una volta attivato, blocca per impostazione predefinita il traffico in entrata. Il suo manuale avverte che ufw enable può far cadere le connessioni SSH, quindi aggiungi prima la regola per SSH. [8]

Per SSH usa limit invece di allow. Una regola limit consente comunque le connessioni, ma blocca un indirizzo che prova ad aprirne 6 o più nell’arco di 30 secondi. Non aggiungere entrambe le regole, perché UFW applica la prima regola che corrisponde. [8]

sudo ufw limit 22/tcp
sudo ufw enable
sudo ufw status verbose

Quando lo attivi tramite SSH, UFW chiede una conferma. [8] Se hai spostato SSH, applica il limite a 2222/tcp. Su Debian 12, se il comando manca, installa prima UFW. Per non esporre affatto SSH su internet, raggiungilo solo attraverso una rete privata WireGuard. Per una protezione più a monte, consulta la nostra checklist di protezione DDoS per l’hosting VPS.

10. Aggiungi Fail2ban con la jail sshd

Su Ubuntu 24.04 il pacchetto include /etc/fail2ban/jail.d/defaults-debian.conf, che attiva la jail sshd, imposta backend = systemd e applica i ban tramite nftables. [9] Il backend systemd legge il journal di systemd, quindi la jail non ha bisogno di un file di log separato. [10]

sudo apt install fail2ban
cat /etc/fail2ban/jail.d/defaults-debian.conf

Il file jail.conf originale di Fail2ban blocca un indirizzo per 10 minuti dopo 5 tentativi falliti nell’arco di 10 minuti, e raccomanda di non modificarlo: metti le tue modifiche in jail.local. [10]

[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
ignoreip = 127.0.0.1/8 ::1 198.51.100.7

Sostituisci 198.51.100.7 con il tuo indirizzo fisso, oppure eliminalo. La jail standard usa port = ssh, quindi se hai spostato SSH aggiungi port = 2222. [10] Su Debian 12, mantieni backend = systemd in questo file e installa python3-systemd, la libreria Python di systemd che questo backend usa. [10] Poi riavvia Fail2ban e controlla che sia in esecuzione:

sudo systemctl restart fail2ban
sudo systemctl status fail2ban

11. Controlla cos’altro è in ascolto

Ogni porta aperta è un’altra via d’accesso. Il report di UFW sulle porte in ascolto mostra tutte le porte TCP in ascolto e le porte UDP aperte, ciascuna con il suo indirizzo (* indica tutte le interfacce), il programma che la usa e le regole che le si applicano. [8]

sudo ufw show listening

Un servizio in ascolto su 127.0.0.1 è raggiungibile solo dal server stesso. Con systemctl disable --now disattiva i servizi esposti all’esterno che non ti servono, come fanno le note di openssh di Ubuntu per ssh.socket. [6]

sudo systemctl disable --now SERVICE_NAME