Hardening SSH Linux: Guida Completa 2026 (10 Impostazioni Critiche)

La sicurezza dei server Linux è una priorità assoluta per qualsiasi professionista IT. In un panorama di minacce in continua evoluzione, un singolo punto debole può trasformarsi in un disastro operativo. SSH (Secure Shell) è la spina dorsale dell’amministrazione remota, ma una configurazione predefinita o mal gestita è un invito aperto per gli attaccanti. Negli ultimi anni, ho visto troppe infrastrutture esposte a rischi inutili a causa di configurazioni SSH deboli. Questo articolo ti guiderà attraverso dieci impostazioni essenziali per blindare i tuoi server Linux, riducendo drasticamente la superficie d’attacco e aumentando la resilienza contro tentativi di intrusione. Implementando queste pratiche, potrai proteggere i tuoi 2.000 endpoint e oltre 300 VM VMware da accessi non autorizzati, garantendo un controllo robusto e proattivo sull’infrastruttura.

Prerequisiti / Ambiente di test

Per seguire questa guida, avrai bisogno di un server Linux (preferibilmente una distribuzione recente come Ubuntu Server 22.04 LTS o CentOS Stream 9) con accesso sudo. Tutti i comandi saranno eseguiti da terminale. Prima di apportare qualsiasi modifica alla configurazione SSH, è fondamentale creare un backup del file sshd_config originale. Questo ti permetterà di ripristinare la configurazione precedente in caso di problemi, evitando di bloccarti fuori dal server. La keyword principale, hardening ssh linux, è il nostro focus per garantire la massima sicurezza.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Cambiare la porta SSH di default

La porta SSH predefinita (22) è il bersaglio principale per gli attacchi automatizzati e i tentativi di scansione. Cambiarla a un valore non standard non offre una sicurezza intrinseca (un attaccante determinato può sempre scansionare tutte le porte), ma riduce in modo significativo il “rumore di fondo” e i tentativi di brute-force automatici. Scegli una porta elevata e non utilizzata da altri servizi.

Nel file /etc/ssh/sshd_config, cerca la riga Port 22 e modificala:

#Port 22
Port 2222

Assicurati di aprire la nuova porta nel firewall del server (es. sudo ufw allow 2222/tcp per UFW o sudo firewall-cmd --permanent --add-port=2222/tcp --zone=public && sudo firewall-cmd --reload per Firewalld).

Disabilitare il login come root

Consentire l’accesso diretto come utente root via SSH è una pratica rischiosa. Se un attaccante riuscisse a indovinare la password di root, avrebbe il controllo completo del sistema. È molto più sicuro accedere con un utente standard e poi elevare i privilegi tramite sudo quando necessario. Questo aggiunge un ulteriore strato di protezione.

Nel file /etc/ssh/sshd_config, imposta:

PermitRootLogin no

Usare solo l’autenticazione a chiave pubblica

L’autenticazione tramite password è vulnerabile ad attacchi brute-force e dictionary attack. L’autenticazione a chiave pubblica, basata su coppie di chiavi crittografiche (una pubblica sul server, una privata sul client), è nettamente più sicura e raccomandata per ambienti di produzione. Richiede che la chiave privata sia custodita in modo sicuro sul client.

Nel file /etc/ssh/sshd_config, imposta:

PasswordAuthentication no
PubkeyAuthentication yes

Assicurati di aver già configurato l’accesso tramite chiave SSH prima di disabilitare l’autenticazione con password, altrimenti potresti bloccarti fuori dal server.

Limitare gli utenti che possono accedere via SSH

Non tutti gli utenti del sistema devono avere la possibilità di accedere via SSH. Limita l’accesso solo agli account strettamente necessari. Questo restringe ulteriormente la superficie d’attacco e riduce il rischio che account compromessi possano essere usati per l’accesso remoto.

Nel file /etc/ssh/sshd_config, aggiungi o modifica:

AllowUsers nomeutente

Puoi specificare più utenti separati da spazi: AllowUsers utente1 utente2.

Abilitare il timeout di sessione inattiva

Le sessioni SSH lasciate aperte e inattive rappresentano un rischio di sicurezza. Se un utente si allontana dal terminale senza bloccarlo, un malintenzionato potrebbe sfruttare la sessione attiva. Configurare un timeout automatico per le sessioni inattive aiuta a mitigare questo rischio.

Nel file /etc/ssh/sshd_config, aggiungi:

ClientAliveInterval 300
ClientAliveCountMax 2

ClientAliveInterval 300 indica che il server invierà un messaggio “keep-alive” al client ogni 300 secondi (5 minuti). ClientAliveCountMax 2 significa che se il client non risponde a 2 di questi messaggi, la sessione verrà terminata. In questo esempio, una sessione inattiva verrà chiusa dopo 10 minuti (300 secondi * 2 tentativi = 600 secondi).

Disabilitare i protocolli SSH obsoleti

Le versioni più vecchie del protocollo SSH (in particolare SSHv1) contengono vulnerabilità note. Assicurati che il tuo server utilizzi solo la versione più recente e sicura, ovvero SSHv2. Questo è solitamente il default nelle distribuzioni moderne, ma è sempre bene verificarlo esplicitamente.

Nel file /etc/ssh/sshd_config, imposta:

Protocol 2

Limitare i tentativi di login (MaxAuthTries)

Per contrastare gli attacchi brute-force, puoi limitare il numero di tentativi di autenticazione permessi per ogni connessione. Dopo aver superato questo limite, la connessione SSH verrà terminata.

Nel file /etc/ssh/sshd_config, aggiungi o modifica:

MaxAuthTries 3

Questo imposta il numero massimo di tentativi a 3. Un valore troppo basso potrebbe essere fastidioso per gli utenti, mentre uno troppo alto rende inefficace la protezione.

Usare AllowUsers e DenyUsers

Oltre a AllowUsers, puoi usare DenyUsers per specificare gli utenti a cui è esplicitamente negato l’accesso SSH. AllowGroups e DenyGroups funzionano in modo simile per interi gruppi. È buona pratica usare AllowUsers o AllowGroups per un controllo più restrittivo, whitelistando solo chi deve accedere, piuttosto che blacklistare chi non deve.

Esempio di AllowUsers (già visto) e DenyUsers:

AllowUsers alice bob
DenyUsers guest

Abilitare il log verboso

Per facilitare il troubleshooting e il monitoraggio della sicurezza, è utile abilitare un livello di logging più dettagliato per il servizio SSH. Questo fornisce maggiori informazioni sugli eventi di login, tentativi falliti e altre attività, essenziali per un SIEM (Security Information and Event Management) o un EDR (Endpoint Detection and Response) come Wazuh per rilevare anomalie.

Nel file /etc/ssh/sshd_config, imposta:

LogLevel VERBOSE

Verificare la configurazione con sshd -t

Prima di riavviare il servizio SSH, è cruciale verificare la sintassi del file di configurazione. Un errore può bloccarti fuori dal server. Il comando sshd -t esegue un test sintattico senza applicare le modifiche.

sudo sshd -t

Se non viene visualizzato alcun output, la sintassi è corretta. In caso di errori, verranno mostrati messaggi indicando il problema e la riga del file.

Test finale e riavvio del servizio

Dopo aver verificato la configurazione, puoi riavviare il servizio SSH. È altamente consigliato mantenere una sessione SSH aperta mentre testi la nuova configurazione da un’altra sessione. In questo modo, se la nuova configurazione ha problemi, non rimarrai bloccato e potrai tornare alla configurazione precedente.

sudo systemctl restart sshd

Connettiti da un nuovo terminale usando la nuova porta e le nuove impostazioni (es. ssh -p 2222 nomeutente@indirizzo_ip). Se la connessione ha successo, puoi chiudere la vecchia sessione.

Errori comuni e troubleshooting

• Bloccato fuori dal server: Il problema più comune. Se non riesci più ad accedere via SSH, la prima cosa da fare è accedere tramite console diretta (es. VMware vSphere Console, OCI Console, KVM) e ripristinare il file /etc/ssh/sshd_config.bak che avevi creato. Riavvia sshd e riprova.
• Problemi di firewall: Se hai cambiato la porta SSH ma non l’hai aperta nel firewall, le connessioni verranno bloccate. Verifica le regole del firewall (sudo ufw status o sudo firewall-cmd --list-all).
• Permessi delle chiavi SSH: Le chiavi private devono avere permessi 600 (chmod 600 ~/.ssh/id_rsa) e la directory .ssh permessi 700 (chmod 700 ~/.ssh). Sul server, il file ~/.ssh/authorized_keys deve avere permessi 600.
• sshd -t segnala errori: Leggi attentamente l’output del comando. Spesso indica la riga esatta del file sshd_config dove si trova l’errore di sintassi.

[Leggi anche: Hardening SSH su Linux: Guida Pratica 2026]

Conclusioni con takeaway operativi

L’hardening SSH su Linux non è un’opzione, ma una necessità. Implementare queste dieci impostazioni essenziali ti darà un controllo molto più stretto sull’accesso ai tuoi server, riducendo significativamente il rischio di compromissione. La disabilitazione del login root, l’uso esclusivo dell’autenticazione a chiave pubblica e il cambio della porta predefinita sono modifiche che offrono un ritorno sulla sicurezza immediato con uno sforzo minimo. Ogni server Linux esposto su internet dovrebbe avere queste configurazioni attive. Per approfondire ulteriormente le opzioni di configurazione, consulta la pagina man di sshd_config.

Ricorda sempre di testare le modifiche in un ambiente di staging prima di applicarle alla produzione e di avere un piano di rollback. La sicurezza è un processo continuo, e l’aggiornamento costante delle best practice è fondamentale per mantenere l’integrità delle tue infrastrutture.