ssh
Come rendere SSH più sicuro sul tuo server
Una guida semplice per rendere SSH più sicuro senza chiuderti fuori dal tuo stesso server.
La porta SSH (22) rappresenta il principale punto d'accesso amministrativo a un server Linux e costituisce il bersaglio primario di scansioni automatizzate e attacchi distribuiti su scala globale.
In breve: L'hardening del servizio SSH si basa su una strategia di protezione a livelli. Per garantire la sicurezza dell'accesso è necessario: sostituire l'autenticazione via password con l'uso di chiavi SSH cifrate, disabilitare il login diretto per l'utente root, limitare gli utenti autorizzati, applicare regole di filtraggio tramite firewall e mantenere attiva una sessione di verifica parallela durante le fasi di test. L'obiettivo non è complicare l'operatività quotidiana, ma eliminare i vettori d'attacco legati al riuso delle credenziali, agli attacchi di forza bruta (Brute-Force) e all'esposizione accidentale dei servizi.
Perché è fondamentale mettere in sicurezza SSH?
Il protocollo SSH (Secure Shell) è lo standard di fatto per l'amministrazione remota dei sistemi Linux. Rappresenta l'interfaccia di controllo privilegiata dell'intera infrastruttura server.
I botnet automatizzati scansionano costantemente gli intervalli di indirizzi IP pubblici alla ricerca del servizio SSH attivo sulla porta predefinita (22), eseguendo attacchi di dizionario su nomi utente comuni quali root, admin, ubuntu o test. L'analisi dei log di autenticazione (/var/log/auth.log o journalctl) evidenzia costantemente questo volume di traffico non autorizzato.
Il daemon OpenSSH è un software storicamente solido; tuttavia, la superficie d'attacco viene spesso ampliata da configurazioni di sistema permissive: autenticazione via password attiva, login diretto come root consentito, chiavi autorizzate obsolete o assenza di regole di filtraggio sul firewall perimetrale.
L'hardening di SSH consiste nel ridurre drasticamente i vettori di ingresso automatizzati, sostituendo meccanismi di autenticazione deboli con standard crittografici elevati ed eliminando le vulnerabilità di configurazione più evidenti.
Fasi prioritarie dell'Hardening SSH
La messa in sicurezza del servizio deve seguire un ordine di priorità ben definito, intervenendo dapprima sui fattori a più alto rischio:
- Autenticazione tramite Chiavi SSH: Sostituire le password con coppie di chiavi crittografiche (RSA a 4096 bit o Ed25519). Una password, per quanto complessa, rimane vulnerabile a tentativi di forza bruta o intercept; una chiave SSH asimmetrica consente l'accesso solo all'host in possesso della chiave privata corrispondente.
- Disattivazione del Login Diretto come Root: L'utente
rootè l'account amministrativo predefinito su ogni sistema Linux. Consentire il login diretto fornisce agli attaccanti la metà dell'equazione di autenticazione (il nome utente). La Best Practice prevede l'accesso tramite un utente con privilegi limitati, elevando le autorizzazioni tramitesudosolo quando strettamente necessario.
Pianificazione degli interventi di sicurezza:
| Intervento di Hardening | Vettore di Attacco Mitigato | Precauzioni Operative |
|---|---|---|
| Adozione di Chiavi SSH | Attacchi Brute-Force e Credential Stuffing | Verificare la presenza della chiave pubblica in ~/.ssh/authorized_keys |
**Disattivazione Password (PasswordAuthentication no)** | Intercettazione e indovinamento delle password | Mantenere una sessione SSH attiva fino alla conferma del funzionamento della chiave |
**Blocco Login Root (PermitRootLogin no)** | Privilege Escalation diretta sull'account root | Verificare che l'utente dedicato appartenga al gruppo sudo o wheel |
| Filtraggio Firewall | Scansioni di rete e tentativi di connessione non autorizzati | Assicurarsi di non bloccare il proprio IP di origine durante la riconfigurazione |
| Documentazione e Audit | Accessi orfani e chiavi autorizzate obsolete | Tracciare periodicamente gli utenti di sistema e le chiavi SSH autorizzate |
La protezione del servizio SSH deve essere integrata con una corretta segmentazione di rete. Il firewall controlla quali socket sono esposti all'esterno, mentre SSH gestisce l'autenticazione del traffico autorizzato. Per approfondire la gestione delle regole di rete, consulta la nostra guida su come configurare un firewall sul tuo server.
Gestione dei rischi: Disattivazione di password e utente Root
L'applicazione delle direttive di sicurezza nel file di configurazione /etc/ssh/sshd_config richiede un approccio metodico per prevenire il blocco accidentale degli accessi amministrativi (Lockout).
Prima di applicare le modifiche ed eseguire il reload del daemon SSH, è indispensabile validare la procedura:
- Configurazione delle Chiavi: Copiare la propria chiave pubblica sul server tramite
ssh-copy-ido inserendola manualmente nel file~/.ssh/authorized_keys. - Test della Connessione in Parallelismo: Mantenere aperta la sessione SSH corrente (che dispone già dei privilegi) e aprire un secondo terminale sul client per testare l'autenticazione via chiave. Non chiudere la sessione primaria finché non si è verificato con successo il nuovo accesso.
- Privilegi Sudo: Accertarsi che l'utente non-root sia in grado di eseguire comandi amministrativi tramite
sudo -i. - Modifica delle Direttive: Impostare
PasswordAuthentication noePermitRootLogin noall'interno di/etc/ssh/sshd_config(o in un file dedicato in/etc/ssh/sshd_config.d/). - Riavvio del Servizio: Verificare la sintassi della configurazione con
sudo sshd -tprima di riavviare il daemon consudo systemctl reload sshd.
In un'ottica di continuità operativa, l'autenticazione e l'accesso devono essere affiancati da strategie di Disaster Recovery. Per la gestione e il ripristino dei dati di sistema, fa' riferimento alla nostra guida su come configurare il backup del server.
Modifica della porta predefinita e uso di Fail2ban
Spostare il servizio SSH su una porta diversa dalla 22 (es. porta 2222 o un valore non standard alto) riduce drasticamente il volume di log generato dalle scansioni automatiche, ma non costituisce una misura di sicurezza assoluta (Security through obscurity). Un port scan completo individuerà comunque il socket SSH attivo.
La modifica della porta è un intervento utile per mantenere puliti i file di log, ma deve sempre seguire — e mai sostituire — l'autenticazione via chiave e il filtraggio del firewall.
Un'integrazione altamente efficace è rappresentata da Fail2ban, un software di prevenzione delle intrusioni (HIPS) che analizza i log di sistema in tempo reale. Quando un host remoto supera la soglia tollerabile di tentativi di autenticazione falliti (maxretry), Fail2ban aggiorna dinamicamente le regole del firewall di sistema (iptables o nftables), bloccando temporaneamente o permanentemente l'indirizzo IP responsabile dell'attacco.
Un'architettura di sicurezza SSH solida si articola su più livelli:
- Autenticazione a chiave asimmetrica: Elimina il rischio legato alle password deboli.
- Disabilitazione del login root diretto: Obbliga l'identificazione dell'operatore tramite utente dedicato.
- Firewalling e Restrizione IP: Limita l'accesso alla porta SSH ai soli indirizzi IP amministrativi (dove possibile).
- Rate Limiting e IPS (Fail2ban): Mitiga gli attacchi distribuiti bloccando gli indirizzi IP ostili.
- Auditing periodico: Verifica costante delle chiavi presenti in
authorized_keyse revisione degli accessi.
FAQ
Qual è la misura più importante per proteggere il servizio SSH? L'adozione esclusiva dell'autenticazione tramite chiavi SSH e la contestuale disattivazione dell'autenticazione via password (PasswordAuthentication no). Questa configurazione neutralizza la totalità degli attacchi Brute-Force basati su dizionario.
Perché è necessario disabilitare il login SSH diretto per l'utente root? Perché l'account root è presente su qualsiasi sistema Linux ed è il target primario degli attacchi. Richiedere l'accesso tramite un utente con privilegi limitati e il successivo passaggio a sudo aggiunge un livello di autenticazione e garantisce la tracciabilità delle azioni nei log di sistema.
La variazione della porta SSH predefinita (22) è sufficiente a garantire la sicurezza? No. La modifica della porta riduce il rumore nei log causato dai bot generici, ma non protegge da port scanner avanzati o da attacchi mirati. Deve essere considerata una misura opzionale e secondaria rispetto all'impiego delle chiavi SSH.
Come posso evitare di rimanere bloccato fuori dal server durante la configurazione? Non chiudere mai la sessione SSH attiva finché non hai aperto un secondo terminale e verificato con successo l'accesso via chiave con l'utente non-root dotato di permessi sudo.
La soluzione intermedia
Server Manager semplifica la gestione della sicurezza fornendo visibilità centralizzata sugli utenti di sistema, sulle porte di rete aperte e sulle regole di filtraggio attive sull'infrastruttura.
L'adozione di un pannello di controllo unificato previene gli errori di configurazione nei file di testo, consentendo di verificare lo stato dei servizi di protezione e mantenendo leggibile l'architettura di rete nel tempo.
L'Hardening del servizio SSH si considera completato quando l'autenticazione via password è disabilitata, il login diretto come root è inibito, l'accesso avviene esclusivamente tramite chiavi cifrate ed è attivo un sistema di monitoraggio dei log per la prevenzione delle intrusioni.