Alpine Linux, falla in openssh-server: login senza password
Chi gestisce server, VM o immagini cloud Alpine Linux con sshd deve aggiornare openssh e riavviare il demone. Se non può aggiornare subito, deve almeno disattivare le password in SSH. Lo indica l’avviso di sicurezza di Alpine Linux del 5 novembre 2026: chi raggiunge la porta SSH può entrare senza conoscere alcuna password, con una sola connessione.
L’aggiornamento del pacchetto da solo non basta, perché non sostituisce il demone già in esecuzione. Entrambe le strade chiudono il problema.
Chi è esposto e cosa controllare
Secondo Alpine Linux, si è esposti se si verificano tutte queste condizioni:
- si usa il pacchetto
openssh-server, compilato senza PAM, oppureopenssh-server-pamconUsePAM no; conUsePAM yesnon si è interessati; PasswordAuthenticationè suyes, che è il valore predefinito di OpenSSH salvo modifiche;- esiste un account con campo password
*:root(nell’immagine base comeroot:*da circa Alpine 3.16), gli utenti solo-chiave creati conaddusersenza password o conusermod -p '*', gli utenti da directory service via musl-nscd (nslcd, winbind, sssd) e l’utentealpinedelle immagini tiny-cloud; - almeno un account locale ha un hash
$5$o$6$.
Non sono interessati i container Docker e simili che non eseguono sshd, i sistemi con PasswordAuthentication no, gli account bloccati con ! nel campo password di /etc/shadow, i sistemi senza hash in stile $ e le immagini cloud configurate con cloud-init, che scrive PasswordAuthentication no.
Sono toccate tutte le release verificate: dalla 3.21 alla 3.24, edge e le più vecchie senza aggiornamenti regolari, dalla 3.16 alla 3.20.
Cosa permette a chi attacca
L’attaccante deve conoscere il nome di un account con campo password *, cioè senza password impostata, una situazione normale per gli account solo-chiave. La macchina deve poi avere almeno un altro account con hash $5$ o $6$. A quel punto basta inviare una password molto lunga, tra 257 e 1024 byte.
Un solo utente con password rende raggiungibili tutti gli account che ne sono privi. Per root vale il PermitRootLogin prohibit-password predefinito: l’accesso diretto è possibile solo con PermitRootLogin yes. Non protegge però se un altro account che può entrare è in grado di diventare root, per esempio con doas.
Al momento della pubblicazione dell’avviso non risultava assegnato nessun CVE. I dettagli sono nelle note di rilascio di OpenSSH 10.6p2.
Versioni corrette per ramo
Le versioni 3.21.10, 3.22.8, 3.23.8 e 3.24.4 contengono il pacchetto corretto. Per aggiornare, da root:
apk upgrade -U -arc-service sshd restart
Il supporto della 3.21 è terminato il 1° novembre 2026, ma Alpine ha pubblicato pacchetti corretti per ogni release fino alla 3.16.
| Ramo | Versione openssh corretta |
|---|---|
| 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 |
Se non puoi aggiornare: disattivare le password
Prima verifica che il login con chiave funzioni e tieni aperta la sessione corrente finché non hai provato un nuovo accesso. Poi, sempre da root, imposta PasswordAuthentication no in un file /etc/ssh/sshd_config.d/00-no-passwords.conf. Alpine precisa che il sshd_config predefinito legge quella directory dalla 3.19 in poi: le release precedenti la ignorano.
Su tutte le release, comprese la 3.19 e successive, l’avviso prescrive anche un comando sed: sed -i.bak -e '1i PasswordAuthentication no' -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' /etc/ssh/sshd_config. Porta a no ogni riga PasswordAuthentication di /etc/ssh/sshd_config, anche dentro i blocchi Match, inserisce la riga in testa per il caso in cui non ce ne fosse nessuna e salva l’originale come /etc/ssh/sshd_config.bak. Poi si controlla e si riavvia:
sshd -t && rc-service sshd restartsshd -T | grep -i passwordauthentication, che deve stamparepasswordauthentication no
Per annullare, si cancella il file di drop-in e si ripristina sshd_config.bak.
Immagini cloud tiny-cloud
Le immagini ufficiali tiny-cloud (qcow2, VHD e AMI) dalla 3.18.11 alla 3.24.3 hanno un utente alpine con campo password * e doas senza password. Alla prima accensione sono sicure. Diventano sfruttabili quando sulla macchina compare un hash $6$, per esempio perché un amministratore imposta una password di console o perché user-data aggiunge un utente con hashed_passwd. L’attaccante ottiene una shell come alpine e con doas diventa root.
Le immagini costruite dalle versioni 3.21.10, 3.22.8, 3.23.8, 3.24.4 e successive includono il pacchetto corretto. Quelle di point release precedenti no: su ogni istanza in esecuzione bisogna aggiornare openssh o disattivare l’autenticazione con password.
Come verificare se c’è stato un accesso
Cerca in /var/log/messages le righe di sshd con Accepted password for riferite a un account senza password: alpine, root o un utente solo-chiave. Controlla poi l’uso di doas e gli utenti, i file e le authorized_keys creati di recente sulle macchine esposte. Se non puoi escludere un accesso, Alpine Linux indica di trattare la macchina come compromessa.
Perché succede e chi l’ha segnalato
Senza PAM, sshd verifica la password con crypt() e confronta il risultato con il campo memorizzato. Se il campo è troppo corto per contenere un salt, sshd usa quello di un altro account. La crypt() di musl restituisce la stringa * come segnale d’errore quando la chiave supera i 256 byte, e * è proprio il contenuto del campo degli account senza password: i due valori coincidono e l’accesso riesce.
OpenSSH 10.6p2 evita il problema in sshd, mentre i pacchetti dei rami stabili portano una patch per lo stesso difetto. Il problema è stato segnalato da Özgün Kültekin di Wakefield.
