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’algoritmoNelle 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 generazionessh-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_ed25519lasciando il nuovo campo vuoto per rimuovere la passphrase.
Backup sicuroLa 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 .sshSul server, nella home dell’utente target:mkdir -p ~/.sshchmod 700 ~/.ssh
Inserimento della chiave pubblicaUtilizzare ssh-copy-id (o metodi manuali) per copiare la chiave pubblica nel file authorized_keys:ssh-copy-id -i /.ssh/id_ed25519.pub utente@serverIn alternativa, copiare manualmente il contenuto del file .pub e appenderlo in */.ssh/authorized_keys* con:cat id_ed25519.pub >> ~/.ssh/authorized_keyschmod 600 ~/.ssh/authorized_keys
Verifica di accessoChiudere la sessione SSH corrente e tentare un nuovo accesso:ssh utente@serverIl 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 passphrasePer evitare di inserire la passphrase ad ogni sessione, usare ssh-agent:eval "$(ssh-agent -s)"ssh-add ~/.ssh/id_ed25519Questo 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 configurazionesudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
Modifiche chiave in /etc/ssh/sshd_configLe direttive da impostare (o modificare):PubkeyAuthentication yesPasswordAuthentication noChallengeResponseAuthentication noUsePAM noPermitRootLogin prohibit-passwordPubkeyAuthentication yes abilita l’autenticazione a chiavePasswordAuthentication no disabilita l’autenticazione con passwordChallengeResponseAuthentication no disabilita modalità challenge-responseUsePAM no disabilita l’uso di PAM in caso interferisca con l’autenticazionePermitRootLogin prohibit-password consente login root solo con chiave (non con password)
Si possono anche specificare policy più restrittive:AllowUsers utente1 utente2PermitEmptyPasswords no
Controllo della configurazionesudo sshd -tper verificare che non ci siano errori sintattici nella configurazione.
Riavvio del servizio SSHApplicare 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.