Il 5 novembre 2026 OpenSSH ha rilasciato la versione 10.6p2, che include una correzione per un bypass dell’autenticazione con password. Su Alpine, per rendere effettiva la correzione bisogna installare la revisione corretta per il proprio ramo e riavviare sshd: l’aggiornamento del pacchetto, da solo, lascia in esecuzione il demone già avviato. OpenSSH Alpine Linux
La configurazione precisa richiesta dal bypass
L’avviso di Alpine descrive una combinazione di condizioni, non un problema che riguarda indistintamente tutte le installazioni Linux. Il server deve usare OpenSSH basato su musl senza PAM, oppure avere UsePAM no; deve inoltre consentire l’autenticazione con password, con PasswordAuthentication yes. L’account bersaglio deve avere * nel campo della password e sul sistema deve esserci almeno un altro account locale con un hash $5$ o $6$.
In questa configurazione, una password da 257 a 1.024 byte può far sì che crypt() di musl restituisca *, che corrisponde al valore presente nel campo dell’account bersaglio. Se il servizio SSH è raggiungibile, Alpine indica che basta una connessione, senza tentativi ripetuti.
Il valore * associato a un account non significa, da solo, che il server abbia disattivato l’autenticazione con password: conta anche l’impostazione effettiva di sshd. Alpine indica come non interessati dal problema i sistemi con PasswordAuthentication no, le configurazioni PAM abilitate con UsePAM yes, gli account bloccati con ! e i container senza sshd in esecuzione.
Quale pacchetto Alpine installare
Alpine ha pubblicato revisioni corrette per edge e per i rami dalla 3.16 alla 3.24. La revisione dipende dal ramo installato:
| Ramo Alpine | Revisione corretta di openssh-server |
edge | 10.6_p2-r0 |
3.24 | 10.3_p1-r2 |
3.23 | 10.2_p1-r1 |
3.22 | 10.0_p1-r11 |
3.21 | 9.9_p2-r1 |
3.20 | 9.7_p1-r6 |
3.19 | 9.6_p1-r3 |
3.18 | 9.3_p2-r4 |
3.17 | 9.1_p1-r7 |
3.16 | 9.0_p1-r6 |
Per aggiornare Alpine indica apk upgrade -U -a, seguito dal riavvio del servizio con rc-service sshd restart. Se non è possibile installare subito l’aggiornamento, la misura temporanea indicata è impostare PasswordAuthentication no e riavviare sshd.
Su Alpine, la correzione è effettiva quando è installata la revisione giusta e il demone sshd è stato riavviato.
Quando le immagini tiny-cloud possono essere esposte
Alpine indica gli artefatti ufficiali tiny-cloud, nei formati qcow2, VHD e AMI, delle versioni dalla 3.18.11 alla 3.24.3. Queste immagini includono un account alpine con * nel campo password e doas senza password; secondo Alpine sono sicure al primo avvio. Le condizioni possono presentarsi in seguito, quando sul sistema è presente un hash $6$ e ricorrono anche gli altri requisiti del bypass. In quel caso, un accesso all’account alpine può consentire di ottenere privilegi di root tramite doas.
Controllare gli accessi e la causa tecnica
Alpine consiglia di esaminare /var/log/messages alla ricerca di voci Accepted password per account che dovrebbero essere senza password. Se non si riesce a escludere un accesso non autorizzato, l’avviso raccomanda di trattare il sistema come compromesso e di controllare doas, gli account, i file e le chiavi autorizzate.
OpenSSH colloca la causa principale al di fuori di sshd, pur avendo inserito la mitigazione nel demone. Rich Felker, autore di musl, ha descritto il problema come un uso errato da parte del programma chiamante. La nota di OpenSSH e l’avviso di Felker riportano le rispettive posizioni dei progetti.
