Hardening di SSH: come proteggere l’accesso remoto al server

SSH (Secure Shell) è il modo standard per amministrare un server Linux da remoto, e per questo è uno dei servizi più attaccati: un server esposto a Internet riceve tentativi di login in continuazione, di giorno e di notte. L'hardening è l'insieme delle impostazioni che lo rendono molto più difficile da forzare, senza togliere comodità a chi lo usa legittimamente.

Perché SSH è un bersaglio

Una macchina appena creata sul cloud, con SSH aperto sulla porta 22, comincia a ricevere tentativi automatici dopo pochi minuti. Gli attaccanti usano programmi che provano nomi utente come root, admin o ubuntu con elenchi di password comuni. Se un solo accesso va a buon fine, hanno il controllo del server. Le difese sono semplici: togliere gli accessi che non servono e rendere inutili le password indovinate.

Un esempio concreto: le impostazioni che contano

Il comportamento del servizio si controlla nel file /etc/ssh/sshd_config. Ecco un estratto con le direttive più importanti:

# /etc/ssh/sshd_config (estratto)
# nessun accesso diretto come root
PermitRootLogin no
# solo chiavi, niente password
PasswordAuthentication no
PubkeyAuthentication yes
# solo questi utenti possono entrare
AllowUsers anna marco
# pochi tentativi per connessione e poco tempo per autenticarsi
MaxAuthTries 3
LoginGraceTime 30
# funzioni che non servono, spente
X11Forwarding no

• PermitRootLogin no: root esiste su ogni sistema, quindi è il primo nome che si prova. Gli amministratori entrano con il proprio utente e poi usano sudo quando serve.
• PasswordAuthentication no: senza password da indovinare, il brute force non ha più senso. Resta l'accesso con chiave: una coppia di file generata con ssh-keygen -t ed25519, dove la parte privata non lascia mai il tuo computer.
• AllowUsers: elenca chi può entrare, e chiunque altro viene respinto prima ancora di controllare la password.
• MaxAuthTries e LoginGraceTime: riducono il numero di tentativi per ogni connessione e il tempo a disposizione.
• Spegni ciò che non usi, come l'inoltro grafico (X11) o l'accesso con password vuota.

Dopo ogni modifica verifica la sintassi con sudo sshd -t e tieni aperta una seconda sessione mentre ricarichi il servizio: se sbagli una direttiva e ti chiudi fuori, la sessione già aperta ti permette di correggere.

Le altre difese

• Firewall: consenti la porta 22 solo dagli indirizzi che ne hanno bisogno, oppure fai passare tutto da un *bastion host*, un unico server di accesso molto controllato. Chiudi le porte che non servono, come descritto nel laboratorio sulle porte inutili.
• Blocco automatico degli indirizzi che sbagliano troppe volte, con strumenti come fail2ban o regole di rate limiting.
• Autenticazione a più fattori per gli accessi amministrativi, per esempio con chiavi hardware. Vedi la guida su MFA e passkey.
• Aggiornamenti: le vulnerabilità di OpenSSH vengono corrette in fretta, ma solo se applichi le patch.
• Monitoraggio dei log: /var/log/auth.log (o il journal di sistema) mostra ogni tentativo. Leggi la guida ai log di accesso per capire cosa cercare.

Cambiare la porta da 22 a un altro numero riduce il rumore nei log ma non è una protezione: chi fa una scansione la trova comunque. Usala come un extra, mai al posto delle misure sopra.

Errori comuni

• Lasciare chiavi private senza passphrase su più computer o, peggio, nei repository di codice.
• Condividere un unico utente fra più persone: in caso di incidente non si sa chi è entrato.
• Dimenticare vecchi account e chiavi autorizzate (~/.ssh/authorized_keys) di persone che hanno lasciato il progetto.