SSH: come proteggere l’accesso al proprio server Linux 🔐

Se gestisci un VPS, un Raspberry Pi o un server Linux, probabilmente utilizzi SSH quasi ogni giorno. È uno degli strumenti più comodi per amministrare una macchina da remoto, modificare configurazioni, consultare log ed eseguire comandi senza dover essere fisicamente davanti al dispositivo.

Ma proprio perché SSH permette di controllare un sistema a distanza, merita particolare attenzione dal punto di vista della sicurezza.

Un server esposto su Internet può ricevere continuamente tentativi automatici di connessione. Non significa necessariamente che qualcuno abbia preso di mira proprio te: molti bot cercano indiscriminatamente servizi raggiungibili, credenziali deboli e configurazioni vulnerabili.

La buona notizia è che proteggere SSH non richiede necessariamente strumenti complicati. Spesso bastano alcune scelte corrette, applicate con attenzione e verificate prima di chiudere la sessione amministrativa.

Che cos’è SSH e perché è così importante?

SSH, acronimo di Secure Shell, è un protocollo che permette di stabilire connessioni remote cifrate tra un client e un server.

Viene utilizzato per amministrare sistemi Linux, trasferire file attraverso SFTP o SCP e realizzare tunnel cifrati per determinati servizi.

Un collegamento tipico può essere avviato così:

ssh [email protected]

Se la connessione è autorizzata, puoi accedere alla shell del server ed eseguire comandi secondo i permessi dell’utente.

È una funzionalità estremamente potente. Per questo non dovrebbe essere protetta soltanto da una password semplice o da una configurazione lasciata invariata per anni.

1. Utilizza chiavi SSH invece delle sole password

L’autenticazione tramite chiave pubblica è generalmente preferibile all’utilizzo di password, soprattutto per server amministrati frequentemente.

Il meccanismo si basa su una coppia di chiavi:

• Chiave privata: rimane sul dispositivo da cui ti colleghi e deve essere protetta.
• Chiave pubblica: viene installata sul server e permette di verificare l’autenticazione.

🔑 La chiave privata non deve essere caricata sul server, condivisa via email o inserita in repository Git.

Su sistemi moderni, Ed25519 è una scelta comune per generare nuove chiavi SSH, quando supportata dall’ambiente.

ssh-keygen -t ed25519 -C "accesso-server"

Durante la procedura puoi scegliere dove salvare la chiave e impostare una passphrase.

La passphrase aggiunge una protezione importante: se qualcuno entra in possesso del file della chiave privata, non dovrebbe poterlo utilizzare immediatamente senza conoscere anche la passphrase.

Per approfondire puoi consultare la documentazione ufficiale di OpenSSH.

2. Installa la chiave pubblica sul server

Su molti sistemi Linux puoi utilizzare:

ssh-copy-id [email protected]

Il comando installa la chiave pubblica nell’account remoto, secondo la configurazione del server.

Se utilizzi Windows, puoi generare e utilizzare chiavi SSH anche tramite il client OpenSSH integrato nelle versioni moderne del sistema operativo.

Dopo aver installato la chiave, prova una nuova connessione:

ssh -i ~/.ssh/id_ed25519 [email protected]

Il percorso è un esempio tipico per Linux e macOS. Su Windows, il percorso effettivo può essere diverso.

Prima di modificare le modalità di autenticazione del server, assicurati che il collegamento tramite chiave funzioni davvero.

3. Non disabilitare subito l’autenticazione con password

Questo passaggio merita una particolare attenzione.

Molte guide suggeriscono di disabilitare immediatamente l’accesso con password. La misura può essere utile, ma applicarla prima di aver verificato un metodo alternativo significa rischiare di perdere l’accesso amministrativo.

La procedura più prudente è:

1. creare una chiave SSH;
2. installare la chiave pubblica sull’account corretto;
3. aprire una seconda sessione e verificare l’accesso;
4. assicurarsi di avere un metodo di recupero, per esempio una console del provider VPS;
5. solo dopo, valutare la disabilitazione delle password.

Su OpenSSH, una configurazione possibile è:

PasswordAuthentication no

Ma attenzione: la configurazione effettiva può dipendere anche da file inclusi, impostazioni del pannello hosting e altre direttive.

Prima di applicare modifiche, verifica sempre la configurazione risultante e mantieni aperta una sessione già funzionante.

4. Limitare l’accesso diretto dell’utente root

Utilizzare direttamente root per ogni attività amministrativa aumenta il rischio di eseguire operazioni distruttive per errore.

In molti ambienti è preferibile collegarsi con un account amministrativo personale e utilizzare sudo soltanto quando necessario.

OpenSSH consente di controllare l’accesso remoto di root attraverso la direttiva:

PermitRootLogin no

Questa impostazione impedisce l’accesso SSH diretto come root, ma deve essere applicata soltanto dopo aver verificato che esista un account alternativo funzionante con i privilegi necessari.

⚠️ Su VPS gestiti tramite pannelli hosting o procedure automatiche, alcune operazioni potrebbero dipendere da configurazioni specifiche. Prima di modificare l’accesso amministrativo, controlla eventuali requisiti del provider.

5. Limitare gli utenti autorizzati

Non tutti gli account presenti su un server devono necessariamente poter accedere via SSH.

OpenSSH mette a disposizione direttive per limitare gli accessi, come:

AllowUsers amministratore

Questa configurazione consente l’autenticazione SSH soltanto agli utenti elencati, secondo le altre regole applicabili.

È utile quando sul server esistono account utilizzati da servizi o applicazioni che non devono aprire sessioni interattive.

Prima di applicare una restrizione, verifica però quali account sono utilizzati da strumenti di deploy, backup e automazione.

6. Il firewall è una protezione fondamentale

Una delle misure più efficaci consiste nel limitare chi può raggiungere la porta SSH.

Se amministri il server sempre da una rete con indirizzo IP stabile, puoi valutare di consentire l’accesso soltanto da quell’indirizzo o da una rete autorizzata.

In alternativa, puoi utilizzare una VPN o un sistema di accesso privato per evitare di esporre direttamente SSH a Internet.

Su Ubuntu, UFW è uno degli strumenti disponibili per gestire regole firewall.

Per esempio, la sintassi per consentire l’accesso da un indirizzo specifico è:

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

L’indirizzo utilizzato appartiene a un intervallo riservato alla documentazione e deve essere sostituito con un indirizzo realmente autorizzato.

⚠️ Non applicare restrizioni firewall alla cieca su un server remoto. Una regola sbagliata può interrompere la connessione e rendere necessario l’accesso tramite console di emergenza.

Se utilizzi già un firewall del provider o un pannello di gestione, considera anche le regole presenti a quei livelli.

7. Cambiare porta SSH serve davvero?

È un consiglio molto diffuso: spostare SSH dalla porta 22 a una porta meno comune per ridurre i tentativi automatici.

Può effettivamente diminuire parte del rumore prodotto dagli scanner più semplici, ma non rappresenta una misura di sicurezza sufficiente.

Un servizio SSH esposto può essere individuato anche su una porta non standard.

Cambiare porta non sostituisce autenticazione con chiavi, aggiornamenti, firewall e controllo dei permessi.

Se decidi di farlo, assicurati che la nuova porta sia consentita dal firewall e che eventuali sistemi di monitoraggio, backup e automazione utilizzino la configurazione aggiornata.

8. Fail2ban: limitare i tentativi ripetuti

Fail2ban è uno strumento che analizza determinati log e può applicare blocchi temporanei agli indirizzi IP associati a comportamenti sospetti, come numerosi tentativi di autenticazione falliti.

Può essere utile per ridurre i tentativi automatizzati e il rumore nei log.

Non bisogna però considerarlo una protezione assoluta: un attaccante può distribuire i tentativi su più indirizzi e alcune configurazioni possono provocare blocchi indesiderati.

Inoltre, Fail2ban deve essere configurato in modo coerente con il sistema di logging e con il firewall effettivamente utilizzato dal server.

Se SSH è raggiungibile soltanto attraverso una rete privata, la riduzione della superficie esposta può essere ancora più significativa rispetto al semplice blocco dei tentativi.

9. Come verificare i tentativi di accesso SSH

Per capire che cosa accade sul server, è utile consultare i log di autenticazione.

Su sistemi che utilizzano systemd, puoi provare:

sudo journalctl -u ssh --since "24 hours ago"

Il nome del servizio può variare in base alla distribuzione. Su alcuni sistemi viene utilizzato sshd.

Puoi cercare eventi come autenticazioni fallite, connessioni rifiutate e accessi riusciti.

📊 Un aumento improvviso dei tentativi falliti non significa necessariamente che il server sia stato compromesso, ma può indicare la necessità di verificare l’esposizione del servizio e l’efficacia dei controlli.

Per gli accessi riusciti, controlla anche indirizzi IP, account utilizzati e orari, confrontandoli con le attività amministrative effettivamente previste.

10. Verificare la configurazione prima di applicarla

OpenSSH mette a disposizione un comando per verificare la validità della configurazione del demone:

sudo sshd -t

Se il comando termina senza segnalare errori, la configurazione supera il controllo sintattico previsto dal programma.

Questo non significa che tutte le regole siano corrette dal punto di vista operativo: una configurazione sintatticamente valida potrebbe comunque impedire l’accesso agli utenti desiderati.

Per visualizzare la configurazione effettiva, puoi utilizzare:

sudo sshd -T

Per verificare configurazioni condizionali basate su utente, host o indirizzo, potrebbe essere necessario utilizzare anche le opzioni specifiche documentate da OpenSSH.

Dopo le modifiche, il servizio deve essere ricaricato o riavviato secondo le modalità appropriate per la distribuzione.

La precauzione più importante rimane mantenere aperta una sessione funzionante e verificare un nuovo accesso prima di chiuderla.

11. Proteggi anche il computer da cui ti colleghi

La sicurezza di SSH non dipende soltanto dal server.

Se un aggressore compromette il computer che contiene la tua chiave privata, potrebbe tentare di utilizzarla per accedere ai sistemi remoti.

Per ridurre il rischio:

• 🔑 proteggi le chiavi private con passphrase adeguate;
• 💻 mantieni aggiornato il dispositivo amministrativo;
• 🔐 utilizza la cifratura del disco quando appropriata;
• 🚫 non caricare le chiavi private su repository o servizi non autorizzati;
• 👤 utilizza chiavi distinte quando la separazione degli accessi è importante;
• 🧹 revoca le chiavi non più necessarie;
• 🛡️ valuta chiavi hardware FIDO2 quando compatibili con il tuo ambiente.

Ricorda anche di verificare l’identità del server quando il client SSH segnala che la sua chiave host è cambiata. Accettare automaticamente una nuova chiave senza controlli potrebbe esporre a rischi di intercettazione.

Checklist per mettere in sicurezza SSH

• ☐ Utilizzo chiavi SSH protette adeguatamente?
• ☐ Ho verificato un accesso alternativo prima di disabilitare le password?
• ☐ Gli account autorizzati sono limitati al necessario?
• ☐ L’accesso diretto di root è gestito secondo una politica consapevole?
• ☐ Il firewall limita l’esposizione del servizio?
• ☐ Il sistema e OpenSSH ricevono aggiornamenti di sicurezza?
• ☐ I tentativi di autenticazione vengono registrati e controllati?
• ☐ Le chiavi non più utilizzate vengono revocate?
• ☐ Dispongo di un metodo di recupero se perdo l’accesso SSH?
• ☐ Ho verificato la configurazione prima di applicare le modifiche?

Conclusione: proteggere SSH significa proteggere il server 🔒

SSH è uno strumento affidabile e fondamentale per amministrare sistemi Linux, ma deve essere configurato con attenzione.

Le misure più importanti non sono necessariamente quelle più complicate: autenticazione robusta, accessi limitati, aggiornamenti regolari e controllo dell’esposizione alla rete costituiscono una base solida.

La cosa da evitare è applicare modifiche drastiche senza una procedura di recupero. Un server molto protetto, ma al quale non riesci più ad accedere, non è esattamente il risultato desiderato. 😅

Con una configurazione ragionata e verifiche periodiche, puoi ridurre sensibilmente i rischi senza rendere inutilmente complicata l’amministrazione quotidiana.