OpenSSH e Alpine Linux: come verificare se il tuo server è davvero vulnerabile

Un server può accettare soltanto chiavi SSH per gli accessi ordinari e, nello stesso tempo, conservare un percorso di autenticazione con password che nessuno ha realmente disabilitato. È proprio questa differenza tra intenzione e configurazione effettiva a rendere interessante il problema corretto con OpenSSH 10.6p2. Non riguarda ogni server Linux e nemmeno ogni installazione Alpine: riguarda una combinazione precisa di libreria C, compilazione di sshd, configurazione e stato degli account.

Quali sistemi sono realmente coinvolti

Il bollettino ufficiale di Alpine Linux del 5 novembre 2026 identifica una vulnerabilità di bypass dell’autenticazione password in specifici sistemi Linux che utilizzano musl libc e OpenSSH senza PAM. Perché la condizione sia sfruttabile, devono coesistere più elementi: autenticazione password abilitata in sshd, almeno un account il cui campo password in shadow contiene * e almeno un altro account con hash SHA-crypt del tipo $5$ oppure $6$. Il problema non è automaticamente presente solo perché un sistema usa Alpine.

Secondo l’avviso degli sviluppatori OpenSSH, la vulnerabilità non interessa i sistemi non Linux, i sistemi Linux con glibc e quelli che utilizzano PAM per l’autenticazione password. Questo perimetro è importante: descrivere la vicenda come una vulnerabilità di tutte le installazioni SSH produrrebbe allarme, ma non aiuterebbe a individuare i sistemi da correggere.

La trappola degli account “solo chiave”

Il fatto che un account non abbia una password utilizzabile non significa che il server SSH rifiuti globalmente i tentativi di autenticazione con password. Sono due controlli differenti: il primo riguarda lo stato della credenziale dell’utente, il secondo il metodo che sshd mette a disposizione del client. Se PasswordAuthentication rimane attivo, il server può comunque entrare nel codice di verifica delle password.

La ricerca tecnica pubblicata su sshhole.com descrive l’interazione alla base del difetto: in determinate condizioni di errore, la funzione crypt() di musl restituisce un asterisco, che può coincidere con il valore usato per indicare un account con password bloccata. Il confronto che dovrebbe negare l’accesso può così produrre un risultato inatteso. È un caso in cui due comportamenti considerati singolarmente ragionevoli si combinano in modo pericoloso al confine tra componenti.

Non è necessario riprodurre tentativi di accesso per decidere se intervenire. Su sistemi esposti a Internet la priorità è identificare le condizioni e applicare la correzione, non trasformare un server di produzione in un laboratorio di exploit.

Come fare un audit senza confondere configurazione e supposizioni

Partirei dall’inventario degli host che eseguono effettivamente sshd, non dall’elenco di tutte le immagini Alpine utilizzate in azienda. Un container Alpine che non esegue né espone un server SSH non presenta questo specifico percorso di attacco. Un host minimale con SSH accessibile, invece, merita una verifica immediata.

• Identificare sistema operativo, libc, versione e provenienza del pacchetto OpenSSH: le distribuzioni possono applicare backport di sicurezza senza adottare il numero di versione upstream più recente.
• Verificare se l’autenticazione password passa da PAM oppure da una build senza PAM.
• Controllare la configurazione effettiva di sshd, incluse direttive Include e blocchi Match, invece di leggere soltanto una riga nel file principale.
• Verificare in modo protetto lo stato degli account locali e i tipi di hash coinvolti, senza esportare né condividere il contenuto di /etc/shadow.
• Registrare se il demone è stato riavviato dopo l’installazione del pacchetto corretto.

Per un primo controllo, sshd -T mostra la configurazione risultante; con blocchi Match occorre valutare anche il contesto pertinente mediante le opzioni previste dal comando. Un risultato apparentemente rassicurante per un contesto non garantisce automaticamente che tutti gli altri siano equivalenti. Anche il controllo delle versioni deve riferirsi ai bollettini della distribuzione, non soltanto alla stringa mostrata da ssh -V, che riguarda il client.

Mitigare subito, aggiornare, riavviare

La mitigazione immediata raccomandata dagli sviluppatori è disabilitare PasswordAuthentication oppure disabilitare il servizio SSH sui sistemi interessati, se compatibile con le esigenze operative. Prima di modificare l’accesso remoto, bisogna verificare di avere un metodo alternativo funzionante, per evitare di perdere l’amministrazione del server. Il cambiamento va validato con il controllo della configurazione e con una nuova connessione, mantenendo una sessione amministrativa di recupero.

La correzione è disponibile in OpenSSH 10.6p2 e nei pacchetti corretti distribuiti da Alpine, anche tramite backport per rami precedenti. Installare un pacchetto non equivale necessariamente ad aggiornare il processo già in memoria: Alpine richiede esplicitamente di riavviare sshd dopo l’aggiornamento. Questa è una delle verifiche più semplici da dimenticare nei processi di patching automatizzato.

Il controllo finale non è soltanto “il package manager dice che è aggiornato”. Deve essere: versione corretta secondo l’advisory della distribuzione, servizio riavviato, autenticazione password disabilitata dove non serve e configurazione risultante verificata per i contesti realmente esposti.

La lezione che vale oltre Alpine

Questa vicenda non dimostra che i sistemi minimali siano intrinsecamente insicuri. Dimostra piuttosto che ridurre il numero di componenti non elimina le interazioni tra quelli rimasti. Una scelta architetturale come non utilizzare PAM cambia il percorso di autenticazione; una convenzione come l’asterisco nel database delle password può assumere significati diversi a seconda dell’implementazione sottostante.

Il criterio utile per chi gestisce infrastrutture è misurare l’esposizione reale: servizi in esecuzione, metodi abilitati, componenti collegati e processi effettivamente aggiornati. Le etichette “key-only”, “minimal” o “patched” non sono controlli di sicurezza. Lo diventano soltanto quando si traducono in verifiche ripetibili.