OpenSSH 10.4: otto fix di sicurezza e il debutto della firma post-quantum ML-DSA+Ed25519

Perché ogni release di OpenSSH merita attenzione

OpenSSH non è un pacchetto qualunque nell’inventario di un sistemista: è il canale attraverso cui la stragrande maggioranza degli accessi remoti a server Linux e Unix passa ogni giorno, dai deployment automatizzati alle sessioni interattive degli amministratori. Quando il progetto rilascia una nuova versione con otto correzioni di sicurezza, non è il tipo di changelog da archiviare “per dopo”: va letto, capito e pianificato subito, anche se nessuna delle falle risulta sfruttata attivamente al momento del rilascio.

Il 6 luglio 2026 è uscita OpenSSH 10.4, e oltre alle correzioni porta con sé la prima implementazione sperimentale di una firma post-quantum ibrida e un cambiamento strutturale nel motore che interpreta i pattern con wildcard. Vediamo cosa cambia davvero per chi gestisce infrastrutture in produzione.

Le correzioni di sicurezza che contano di più

Due delle otto falle sono state individuate dallo Swival Security Scanner e riguardano il trasferimento file:

sftp: un server malevolo poteva dirottare un download avviato da riga di comando (ad esempio sftp host:/percorso .) verso una destinazione diversa da quella attesa sul client.
scp: durante le copie tra due host remoti, un server compromesso poteva scrivere file nella directory padre di quella di destinazione, uscendo dal perimetro previsto.

Sul lato server (sshd) sono stati corretti altri problemi rilevanti:

l’implementazione internal-sftp troncava silenziosamente gli argomenti oltre il nono su righe di comando lunghe, con il rischio concreto di perdere un’opzione di sicurezza posizionata più avanti nella riga;
DisableForwarding=yes non disattivava correttamente il tunneling quando combinato con PermitTunnel=yes, una regressione ora risolta per allinearsi al comportamento documentato;
è stata chiusa una denial of service pre-autenticazione legata a GSSAPIAuthentication (funzione disattivata di default, ma diffusa in ambienti Active Directory);
il ritardo minimo di autenticazione — la misura che rallenta i tentativi ripetuti di indovinare una password — in alcuni casi non veniva applicato: ora viene sempre imposto.

Sul client, ssh aveva un bug use-after-free innescabile quando un server cambiava la propria host key durante un re-exchange delle chiavi. Non è uno scenario comune, ma è esattamente il tipo di corner case che un attaccante con un server sotto il proprio controllo può orchestrare deliberatamente.

Checklist di aggiornamento pratica

Verifica la versione attuale con ssh -V e sshd -V su tutti i nodi.
Prima di riavviare il servizio, testa la nuova configurazione con sudo sshd -t.
Se hai script che analizzano l’output di sshd -T o sshd -G, verifica la sensibilità al maiuscolo/minuscolo (vedi sotto).
Pianifica la finestra di manutenzione su bastion host e jump server per primi, dato il loro ruolo critico.

La firma post-quantum sperimentale: ML-DSA-44 + Ed25519

La novità più discussa di questa release è il supporto sperimentale per uno schema di firma che combina ML-DSA-44 (l’algoritmo lattice-based standardizzato da NIST) con Ed25519, seguendo la bozza IETF draft-miller-sshm-mldsa44-ed25519-composite-sigs. Le due firme vengono unite in un’unica firma composita: per validare l’autenticazione entrambi gli algoritmi devono verificare correttamente, il che significa che un attaccante dovrebbe rompere sia la crittografia classica sia quella post-quantum per falsificare una chiave.

La funzione resta disattivata di default. Per provarla su un host di test:

# Generare una nuova coppia di chiavi ibride
ssh-keygen -t mldsa44-ed25519 -f ~/.ssh/id_mldsa44_ed25519

# Abilitare l'algoritmo lato client (~/.ssh/config)
Host bastion.esempio.it
    PubkeyAcceptedAlgorithms +mldsa44-ed25519

# Abilitare l'algoritmo per le host key lato server (sshd_config)
HostKeyAlgorithms +mldsa44-ed25519
HostKey /etc/ssh/ssh_host_mldsa44_ed25519_key

Va trattata per quello che è: una funzione sperimentale. Non ha senso migrare in blocco l’infrastruttura di produzione oggi, ma vale la pena aprire un ticket interno per iniziare a testarla su ambienti non critici, perché la transizione verso algoritmi resistenti al calcolo quantistico nell’SSH arriverà — la domanda è solo quando, non se.

Un motore di pattern matching più robusto

La seconda novità tecnica è meno appariscente ma importante lato hardening: il matcher dei pattern con wildcard (usato ad esempio in AllowUsers, Match e nelle liste di host) è stato riscritto attorno a un automa a stati finiti non deterministico (NFA). Il vecchio codice poteva incorrere in un tempo di esecuzione esponenziale su pattern costruiti ad arte, un problema simile ai classici attacchi ReDoS sulle espressioni regolari. Con il nuovo matcher questo caso patologico scompare.

Modifiche che possono rompere configurazioni esistenti

Tre cambiamenti meritano un controllo esplicito prima dell’upgrade:

L’output di sshd -G ora stampa le direttive in stile misto (es. PubkeyAuthentication) invece che tutto minuscolo: se hai script di parsing con grep case-sensitive, vanno aggiornati.
Su Linux, se il sandbox seccomp non può essere attivato (o manca NO_NEW_PRIVS), l’avvio di sshd ora fallisce in modo fatale invece di degradare silenziosamente. Ambienti containerizzati con restrizioni sul syscall filtering (alcuni setup gVisor o kernel molto vecchi) vanno testati prima del rollout.
Il layer di trasporto è diventato più severo: un peer che invia messaggi non pertinenti al key exchange durante un rekey post-autenticazione viene ora disconnesso, chiudendo un vettore di esaurimento memoria.

In sintesi

OpenSSH 10.4 è un aggiornamento da programmare a breve termine, non da rimandare: le correzioni su sftp/scp toccano un vettore di attacco realistico (server malevolo o compromesso), mentre il fix sul ritardo minimo di autenticazione rafforza la resistenza al brute-force. La firma post-quantum resta un esperimento da monitorare, ma è il segnale più chiaro finora che il mondo SSH si sta muovendo verso la crittografia resistente al quantum computing. Prima di eseguire il rollout su larga scala, testate configurazione, script di automazione e ambienti containerizzati: le tre modifiche “breaking” di questa release sono piccole ma possono bloccare un deployment automatizzato se non verificate in anticipo.

Fonte: Help Net Security – OpenSSH 10.4 arrives with security fixes and a post-quantum signature option