L’uso di autenticazione tramite chiavi SSH (public key authentication) sostituisce l’affidamento alle password, riducendo significativamente il rischio di accessi forzati (brute force) o violazioni derivate da credenziali deboli. OpenSSH, implementazione ampiamente adottata nei sistemi Linux e Unix, supporta nativamente l’autenticazione a chiave pubblica e consente di disabilitare le password una volta che il sistema è correttamente configurato. Questa configurazione, se ben gestita, migliora la sicurezza complessiva dell’accesso remoto.

Nel 2023 è stato illustrato l’attacco “Terrapin” che consente di manipolare l’integrità del canale SSH in certe modalità cifrate, rendendo possibile un downgrade degli algoritmi di autenticazione via exploit dei numeri di sequenza di pacchetto. Questo tipo di ricerca rafforza l’importanza di configurare algoritmi moderni, aggiornare OpenSSH e ridurre la superficie di attacco attiva (es. disabilitando i metodi in chiaro).

Generazione della coppia di chiavi

Scelta dell’algoritmo
Nelle versioni moderne di OpenSSH (su Ubuntu 22.04 e successive, ad esempio), è consigliabile usare algoritmi più robusti come ed25519 o ECDSA piuttosto che RSA con lunghezze modeste (es. RSA 2048). Le versioni OpenSSH disponibili nei recenti LTS includono patch di sicurezza e aggiornamenti senza modificare la compatibilità.

Comando di generazione
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519 -C "nome_utente@host"

  • -a 100 indica iterazioni di derivazione (utile se si protegge la key con passphrase)
  • Il file .pub risultante è la chiave pubblica; il file senza estensione è la chiave privata

Protezione della chiave privata
È fortemente consigliato l’uso di una passphrase per la chiave privata. Se si desidera rimuovere successivamente la passphrase, si può usare:
ssh-keygen -p -f ~/.ssh/id_ed25519
lasciando il nuovo campo vuoto per rimuovere la passphrase.

Backup sicuro
La chiave privata, forse è inutile sottolinearlo, dev’essere conservata in un luogo sicuro (hardware sicuro, backup cifrato). La chiave pubblica può essere replicata o distribuita sui server target.

Distribuzione della chiave pubblica sul server

Preparare la cartella .ssh
Sul server, nella home dell’utente target:
mkdir -p ~/.ssh chmod 700 ~/.ssh

Inserimento della chiave pubblica
Utilizzare ssh-copy-id (o metodi manuali) per copiare la chiave pubblica nel file authorized_keys:
ssh-copy-id -i ~/.ssh/id_ed25519.pub utente@server
In alternativa, copiare manualmente il contenuto del file .pub e appenderlo in ~/.ssh/authorized_keys con:
cat id_ed25519.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys

Verifica di accessoChiudere la sessione SSH corrente e tentare un nuovo accesso:
ssh utente@server
Il client dovrebbe autenticarti tramite la chiave, senza richiedere la password dell’utente (ma potrebbe richiedere la passphrase locale della chiave).

Uso di ssh-agent / caching della passphrase
Per evitare di inserire la passphrase ad ogni sessione, usare ssh-agent:
eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519
Questo consente di generare sessioni multiple senza ridigitare la passphrase.

Configurazione del server SSH (sshd) per disabilitare le password

Una volta verificato che l’autenticazione a chiave funzioni senza problemi, è possibile modificare la configurazione del demone SSH per disabilitare l’autenticazione tramite password, riducendo il vettore d’attacco.

Backup del file di configurazione
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Modifiche chiave in /etc/ssh/sshd_config
Le direttive da impostare (o modificare):
PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no UsePAM no PermitRootLogin prohibit-password

PubkeyAuthentication yes abilita l’autenticazione a chiave
PasswordAuthentication no disabilita l’autenticazione con password
ChallengeResponseAuthentication no disabilita modalità challenge-response
UsePAM no disabilita l’uso di PAM in caso interferisca con l’autenticazione
PermitRootLogin prohibit-password consente login root solo con chiave (non con password)

Si possono anche specificare policy più restrittive:
AllowUsers utente1 utente2 PermitEmptyPasswords no

Controllo della configurazione
sudo sshd -t
per verificare che non ci siano errori sintattici nella configurazione.

Riavvio del servizio SSH
Applicare le modifiche con:
sudo systemctl restart sshd

E' necessario ricordarsi di aggiornare costantemente OpenSSH (Ubuntu fornisce aggiornamenti di sicurezza continui.) e monitorare i log (tentativi falliti). In ambienti professionali, l’adozione di politiche di rotazione delle chiavi e l’aggiornamento contro attacchi emergenti sono passi complementari indispensabili.