Perché le password su SSH sono ormai un rischio da eliminare

Se gestisci anche un solo server Linux esposto su Internet, i log di /var/log/auth.log te lo confermano ogni giorno: bot e botnet tentano continuamente il login SSH via password, in modalità brute-force o credential stuffing. Una password, per quanto complessa, resta un segreto condiviso che può essere intercettato, indovinato o riutilizzato da un attaccante che l’ha ottenuta altrove. L’autenticazione a chiave pubblica elimina questo vettore alla radice: il server non conosce mai un segreto trasmissibile, ma verifica solo che il client possieda la chiave privata corrispondente a una chiave pubblica già autorizzata.

Questa guida copre il flusso completo: generazione della coppia di chiavi con ssh-keygen, distribuzione della chiave pubblica, gestione di host multipli con ~/.ssh/config, uso di ssh-agent e, infine, disattivazione sicura del login via password lato server.

Generare la coppia di chiavi con ssh-keygen

Il primo passo è la scelta dell’algoritmo. Nel 2026 la raccomandazione per la quasi totalità degli scenari è Ed25519: chiavi più corte di RSA, generazione e verifica più veloci, sicurezza equivalente (o superiore) a RSA 3072/4096 bit. OpenSSH genera Ed25519 come default da ssh-keygen 9.5 (fine 2023), ma vale la pena specificarlo esplicitamente per chiarezza e portabilità degli script:

ssh-keygen -t ed25519 -C "nome@host-o-scopo-della-chiave"

Il comando chiede dove salvare la chiave (default ~/.ssh/id_ed25519) e una passphrase. Imposta sempre una passphrase: senza, chiunque copi il file della chiave privata (backup non cifrato, laptop rubato, snapshot di VM) ottiene accesso diretto ai sistemi target. Se devi supportare dispositivi legacy che non gestiscono Ed25519 (raro, ma capita con apparati di rete datati), usa RSA a 4096 bit come alternativa:

ssh-keygen -t rsa -b 4096 -C "nome@host-o-scopo-della-chiave"

Un’opzione spesso sottovalutata è l’uso di chiavi FIDO2/hardware, dove il materiale crittografico non lascia mai una security key fisica (es. YubiKey):

ssh-keygen -t ed25519-sk -C "chiave-hardware"

Per ambienti con requisiti di compliance elevati o accessi amministrativi privilegiati, vale la pena valutarla: anche in caso di compromissione totale della workstation, la chiave privata resta inaccessibile senza il dispositivo fisico.

Distribuire la chiave pubblica

Il modo più rapido è ssh-copy-id, che si occupa di creare (se assente) la directory ~/.ssh sul server remoto, con permessi corretti, e di appendere la chiave pubblica a authorized_keys:

ssh-copy-id -i ~/.ssh/id_ed25519.pub utente@server

Se ssh-copy-id non è disponibile (ad esempio da un client Windows senza WSL), il metodo manuale equivalente è:

cat ~/.ssh/id_ed25519.pub | ssh utente@server \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

I permessi contano davvero: OpenSSH lato server rifiuta silenziosamente authorized_keys se la directory .ssh è scrivibile da altri utenti o se il file ha permessi troppo aperti. Se il login a chiave “non funziona” senza errori evidenti, controlla sempre chmod 700 ~/.ssh e chmod 600 ~/.ssh/authorized_keys prima di cercare altrove.

Gestire host multipli con ~/.ssh/config

Chi amministra decine di server trae grande beneficio da un file di configurazione client centralizzato. Invece di ricordare chiave, utente e porta per ogni host, definisci alias in ~/.ssh/config:

Host prod-web01
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes

Host *.interno.lan
    User admin
    IdentityFile ~/.ssh/id_ed25519_lan
    ForwardAgent no

Da quel momento ssh prod-web01 basta e avanza. L’opzione IdentitiesOnly yes è importante quando gestisci più chiavi: senza di essa, il client SSH può offrire al server tutte le identità disponibili nell’agent, esaurendo il numero massimo di tentativi consentiti (MaxAuthTries) prima di arrivare a quella corretta.

ssh-agent: passphrase una sola volta per sessione

Con una passphrase impostata (come dovrebbe essere sempre), digitarla a ogni connessione è scomodo. ssh-agent mantiene la chiave decifrata in memoria per la durata della sessione:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Sulla maggior parte delle distribuzioni desktop l’agent è già integrato con il session manager. Evita ForwardAgent yes indiscriminato: l’agent forwarding espone la tua chiave in memoria a qualunque processo con privilegi root sul server intermedio, un rischio concreto se quel server non è pienamente fidato. Se ti serve saltare attraverso un bastion host, preferisci ProxyJump:

Host bastion
    HostName bastion.example.com
    User jump

Host target-interno
    HostName 10.0.5.20
    User admin
    ProxyJump bastion

Disabilitare l’autenticazione a password lato server

Solo dopo aver verificato che il login a chiave funziona correttamente (testalo in una sessione separata prima di chiudere quella attuale), disattiva la password lato server. Sulle distribuzioni moderne (Debian/Ubuntu recenti), il modo più pulito è un drop-in dedicato, che viene caricato prima del file principale e quindi vince sui default:

sudo mkdir -p /etc/ssh/sshd_config.d
sudo tee /etc/ssh/sshd_config.d/00-disable-password-auth.conf <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF
sudo sshd -t && sudo systemctl reload sshd

sshd -t valida la sintassi prima del reload: un errore di battitura in questo file può tagliarti fuori dal server se non hai un accesso alternativo (console cloud, iDRAC/iLO, ecc.). PermitRootLogin prohibit-password è la scelta consigliata rispetto a no secco: mantiene comunque disponibile il root via chiave per operazioni di emergenza, ma blocca il tentativo via password.

Checklist finale per un hardening solido

• Una chiave dedicata per servizio/scopo (deploy, amministrazione, CI/CD), non un’unica chiave riutilizzata ovunque.
• Passphrase sempre presente sulle chiavi memorizzate su disco non cifrato.
• Audit periodico di authorized_keys su ogni server: rimuovi le chiavi di chi ha lasciato il team o non necessita più di accesso.
• AuthorizedKeysCommand con backend centralizzato (Vault, LDAP) se gestisci decine di server e vuoi evitare la distribuzione manuale delle chiavi.
• Fail2ban o equivalente comunque attivo, come difesa in profondità anche a password disabilitate.

Conclusione

Il passaggio da password a chiavi SSH richiede pochi minuti per server, ma elimina una delle superfici di attacco più sfruttate contro sistemi Linux esposti. La combinazione di Ed25519, ~/.ssh/config ben strutturato e password disabilitate lato server è oggi lo standard minimo per qualunque infrastruttura, piccola o grande che sia.

Fonte: LinuxBlog.io.