OpenSSH e Alpine Linux: falla SSH, chi rischia e come proteggersi

Se gestisci un server Alpine Linux con accesso SSH, aggiorna subito OpenSSH e riavvia il servizio sshd. Il 5 novembre 2026 Alpine Linux e il progetto OpenSSH hanno segnalato un problema di autenticazione che, in alcune configurazioni con musl libc e PAM assente o disabilitato, può consentire accessi senza conoscere la password. Non riguarda automaticamente ogni installazione Linux: la presenza di SSH esposto, l’autenticazione via password e lo stato degli account fanno la differenza.

La comunicazione di sicurezza di Alpine Linux spiega le condizioni necessarie e indica pacchetti corretti anche per rami meno recenti. Il progetto OpenSSH ha rilasciato OpenSSH 10.6p2 con una mitigazione del problema.

Quali server sono davvero vulnerabili?

Il rischio richiede una combinazione di condizioni: un server che usa musl libc, OpenSSH senza PAM (oppure con UsePAM no), autenticazione mediante password abilitata, un account accessibile con campo password * e almeno un altro account locale con hash password compatibile. Sui sistemi Alpine il pacchetto openssh-server è compilato senza PAM; il pacchetto openssh-server-pam con UsePAM yes non ricade nel caso descritto dall’advisory.

Non risultano interessati da questo specifico difetto i sistemi Linux basati su glibc, i sistemi non Linux, le installazioni che verificano le password tramite PAM e i server con PasswordAuthentication no. Anche un container che non esegue sshd al suo interno non espone il servizio vulnerabile. Questo è importante: non basta vedere OpenSSH installato per concludere che la macchina sia sfruttabile.

Cosa fare subito su Alpine Linux

La soluzione preferibile è aggiornare i pacchetti di sistema attraverso i repository ufficiali della distribuzione. Su Alpine, da una sessione amministrativa autorizzata, il comando indicato è:

apk upgrade -U -a

Dopo l’aggiornamento riavvia sshd, altrimenti il processo già in esecuzione potrebbe continuare a usare il codice precedente:

rc-service sshd restart

Prepara una console di emergenza o mantieni una sessione amministrativa aperta se gestisci una macchina remota; verifica poi che l’accesso SSH autorizzato funzioni ancora. Per le versioni Alpine 3.24, 3.23, 3.22 e 3.21, i pacchetti corretti indicati nell’avviso ufficiale sono rispettivamente 10.3_p1-r2, 10.2_p1-r1, 10.0_p1-r11 e 9.9_p2-r1. Per edge il riferimento è 10.6_p2-r0; per i rami precedenti consulta la tabella completa pubblicata da Alpine.

Se non puoi installare subito gli aggiornamenti

Come mitigazione temporanea, disabilita gli accessi SSH mediante password impostando PasswordAuthentication no nella configurazione effettiva del demone. Prima di cambiare la configurazione verifica che l’accesso con chiave SSH funzioni, conserva la sessione corrente e assicurati di avere un accesso di recupero alla macchina.

Dopo la modifica controlla la validità della configurazione con sshd -t, riavvia il servizio con rc-service sshd restart e verifica il risultato con sshd -T: l’opzione passwordauthentication deve risultare no. Presta attenzione a file inclusi e blocchi Match, che possono cambiare la configurazione per singoli utenti. Per Alpine 3.18 e precedenti non dare per scontato che i file in sshd_config.d vengano letti: la documentazione Alpine precisa che il supporto predefinito agli include parte da 3.19.

Come capire se un server è stato esposto

Controlla quali host espongono la porta SSH, se accettano password e quali pacchetti sono installati. Verifica i log di autenticazione, inclusi eventuali eventi Accepted password for relativi ad account configurati soltanto per l’accesso con chiave. Alpine indica /var/log/messages come punto di partenza; esamina anche account creati di recente, chiavi autorizzate e attività doas anomale.

Questi controlli non equivalgono a una prova di compromissione: un server potenzialmente vulnerabile non è necessariamente stato attaccato. Se emergono accessi inspiegabili o non è possibile escludere un’intrusione, isola il sistema secondo le procedure aziendali, conserva le evidenze e avvia una risposta all’incidente.

Perché la falla non interessa tutti i sistemi OpenSSH

Il problema nasce dall’interazione fra la verifica delle password da parte di sshd senza PAM e il comportamento della funzione crypt() di musl in condizioni anomale. Il progetto OpenSSH considera la causa originale esterna a OpenSSH, ma ha pubblicato rapidamente una mitigazione nella versione 10.6p2. Evitare generalizzazioni è essenziale: distribuzione, libreria C, uso di PAM e impostazioni del server determinano l’esposizione reale.

Chi gestisce infrastrutture Linux dovrebbe associare questa verifica alle normali attività di aggiornamento e controllo accessi. Un approccio simile vale per altre falle specifiche: su Tech abbiamo già spiegato come intervenire sulle vulnerabilità di Sudo in Linux e perché, nel caso di VMware vCenter, identificare la versione interessata è il primo passo prima di applicare una patch.

In sintesi: aggiorna il pacchetto OpenSSH distribuito da Alpine, riavvia sshd e verifica che l’autenticazione mediante password non sia disponibile dove non necessaria. La priorità è proteggere gli host realmente esposti, senza attribuire a tutti i sistemi Linux una vulnerabilità che richiede condizioni specifiche.