OpenSSH 10.6p2 corrige um desvio de senha no Alpine Linux

O Alpine Linux e o projeto OpenSSH publicaram em 5 de novembro de 2026 correções para um bug que permite entrar por SSH em alguns servidores Alpine sem nenhuma senha. Quem roda o servidor SSH padrão do Alpine com login por senha ativado deve atualizá-lo e reiniciá-lo hoje.

A falha "exige uma só conexão, funciona sempre e não precisa de novas tentativas", segundo o aviso de segurança do Alpine. Quem a relatou foi Özgün Kültekin, da Wakefield. Nenhum número CVE havia sido atribuído quando o Alpine publicou o aviso, e nenhum dos dois projetos relata ataques.

Como o desvio de senha funciona

O bug fica onde o OpenSSH encontra o musl, a pequena biblioteca C que o Alpine usa no lugar da glibc. Ele só aparece quando o sshd, o servidor SSH, roda sem PAM. O PAM é o sistema de login comum usado pela maioria das distribuições Linux.

Sem PAM, o sshd calcula o hash da tentativa de senha com crypt(). Depois compara o resultado com a entrada da conta em /etc/shadow. O Alpine explica que o crypt() do musl devolve * como erro para chaves com mais de 256 bytes. Uma conta sem senha guarda esse mesmo *. Por isso, uma senha de 257 a 1.024 bytes "confere". Uma conta sem um salt utilizável pega emprestado o salt de outra conta. O salt é o texto aleatório que torna cada hash único. Por isso, uma conta local precisa ter um hash real $5$ ou $6$.

As notas de versão do OpenSSH 10.6p2 chamam a atualização de "uma solução de contorno de segurança crítica" e situam a causa "fora do sshd". Ela vem depois do OpenSSH 10.6, que saiu em outubro com assinaturas pós-quânticas.

A análise de Kültekin chama o bug de "sshhole" e o rastreia até dois commits do musl de agosto de 2012. De cerca de 17.600 logins de teste, só o musl sem PAM se comportou de outro jeito. A análise também cita OpenWrt, Buildroot e Yocto. O Alpine e o OpenSSH não os mencionam.

Quem é afetado, segundo o aviso do Alpine

Uma máquina só fica exposta quando as quatro condições valem:

• O sshd vem do pacote openssh-server, compilado sem PAM, ou do openssh-server-pam com UsePAM no.
• PasswordAuthentication está em yes, o padrão.
• Uma conta tem * no campo de senha, como root, um usuário que só usa chaves ou um usuário de diretório vindo do sssd.
• Pelo menos uma conta local tem um hash $5$ ou $6$.

Contêineres que não rodam o sshd estão seguros, assim como contas bloqueadas marcadas com !. O padrão PermitRootLogin prohibit-password bloqueia o login de root por senha. Mas ele não protege uma conta que pode virar root pelo doas. As imagens tiny-cloud do Alpine, da 3.18.11 à 3.24.3, trazem justamente um usuário alpine assim, com * e doas sem senha.

Teste: cinco imagens do Alpine e seus padrões

Em um teste da Tech AI Wire em 5 de novembro, no macOS 26.6.2 com Docker 28.4.0, as imagens oficiais alpine instalaram o openssh-server a partir dos espelhos atuais do Alpine.

Ramo	Versão da imagem (compilada)	Pacote instalado	Versão corrigida do Alpine	sshd -V
3.21	3.21.9 (21 out.)	9.9_p2-r1	9.9_p2-r1	OpenSSH_9.9p2
3.22	3.22.7 (21 out.)	10.0_p1-r11	10.0_p1-r11	OpenSSH_10.0p2
3.23	3.23.7 (21 out.)	10.2_p1-r1	10.2_p1-r1	OpenSSH_10.2p1
3.24	3.24.3 (21 out.)	10.3_p1-r2	10.3_p1-r2	OpenSSH_10.3p1
edge	3.25.0_alpha20260805 (6 ago.)	10.6_p2-r0	10.6_p2-r0	OpenSSH_10.6p2

Quatro resultados importam:

• Instalações novas recebem a correção, mas as imagens são anteriores. Cada uma informa uma versão abaixo das corrigidas 3.21.10, 3.22.8, 3.23.8 e 3.24.4. Os ramos estáveis trazem a correção dentro de versões antigas do OpenSSH. Então verifique a revisão do pacote, não o sshd -V.
• Os padrões cumprem três condições. As cinco rodam com PasswordAuthentication yes e têm root:*. No 3.24, o sshd padrão rejeitou UsePAM yes como "Unsupported option". O programa separado sshd.pam, do pacote openssh-server-pam, ainda mostrava usepam no no 3.21 e no 3.24.
• Uma imagem nova não cumpre a quarta. Nenhuma conta tem hash $5$ ou $6$ até alguém definir uma senha. Uma única chamada de chpasswd gravou um hash $6$.
• Fazer funcionar um usuário que só usa chaves cria uma conta *. No 3.24, adduser -D appuser gravou !, e o sshd recusou a chave dele: "User appuser not allowed because account is locked". O passwd -u do BusyBox deixou o ! no lugar. Depois de usermod -p '*', o login com chave funcionou.

Como verificar e corrigir um servidor Alpine

Três comandos mostram a situação de um servidor. No 3.24, o teste exibiu:

$ apk list -I "openssh-server*"
openssh-server-10.3_p1-r2 aarch64 {openssh} (SSH-OpenSSH) [installed]
openssh-server-common-10.3_p1-r2 aarch64 {openssh} (SSH-OpenSSH) [installed]
$ sshd -T | grep -i passwordauthentication
passwordauthentication yes
$ awk -F: '$2=="*" {print $1}' /etc/shadow
root

Um pacote mais antigo que a versão corrigida da tabela precisa da atualização. O Alpine também corrigiu os ramos sem suporte, do 3.16 ao 3.20. Rode apk upgrade -U -a e depois rc-service sshd restart. "Atualizar só o pacote não substitui o daemon em execução", avisa o comunicado.

Se a atualização precisar esperar, a solução de contorno do Alpine é um arquivo, /etc/ssh/sshd_config.d/00-no-passwords.conf, com PasswordAuthentication no. Confirme antes que o login com chave funciona e mantenha a sessão atual aberta. No teste, esse arquivo mudou o sshd -T de yes para no no 3.21 e no 3.24. Depois, procure em /var/log/messages linhas "Accepted password for" de uma conta sem senha.

O que isso significa para desenvolvedores

Procure openssh-server nos Dockerfiles. As imagens que rodam o sshd para runners de CI ou desenvolvimento remoto são as que importam. Reconstrua-as com docker build --pull --no-cache, para que uma camada em cache de antes de 5 de novembro não traga de volta o pacote antigo.

Torne PasswordAuthentication no o padrão em qualquer máquina Alpine que só precise de chaves. O Alpine diz que atualizar ou desligar o login por senha "fecha o buraco". O teste mostra por que esse ajuste importa: o jeito comum de dar um login que funciona a um usuário que só usa chaves cria a conta * de que esse bug precisa.

Fique de olho em um número CVE e no que OpenWrt, Buildroot e Yocto disserem sobre quais builds deles estão expostos. A equipe do OpenSSH também diz que, por enquanto, vai lançar versões com mais frequência.