Saltar para o conteúdo

Falha no OpenSSH em Alpine Linux: quem tem VPS ou contentores deve atualizar já

Falha no OpenSSH em Alpine permite login sem palavra-passe com uma palavra demasiado longa. Saiba se o seu VPS está afetado e como atualizar.

A 5 de novembro de 2026, o projeto OpenSSH publicou a versão 10.6p2 com um aviso de segurança crítico para sistemas Linux que usam a biblioteca musl e o servidor SSH sem PAM. No mesmo dia, a Alpine Linux — distribuição muito usada em contentores Docker, imagens cloud e alguns VPS leves — publicou um aviso oficial a pedir atualização imediata do pacote openssh e o reinício do serviço sshd.

A falha, descrita pelo investigador Özgün Kültekin da Wakefield e coberta pelo BleepingComputer, permite a um atacante que chegue à porta SSH iniciar sessão em contas que não deveriam aceitar palavra-passe — por exemplo contas só com chave SSH — enviando uma palavra-passe muito longa. Em certas imagens cloud oficiais da Alpine, isso pode chegar a acesso de administrador. Se o site, a loja ou o painel da sua empresa corre num VPS Alpine, num contentor com SSH ou numa imagem «tiny-cloud» na AWS ou no Azure, este aviso diz-lhe respeito.

O que falhou, em linguagem clara

Em Linux, as contas sem palavra-passe (só chave SSH, utilizador root na Alpine recente, utilizador alpine nas imagens cloud) guardam no ficheiro de palavras-passe o caractere *. Em condições normais, nenhuma palavra-passe deveria bater certo com esse valor.

Segundo a Alpine e a Wakefield, o OpenSSH, quando corre sem PAM, usa a função crypt() da biblioteca C para comparar a tentativa de login. Na biblioteca musl (a da Alpine), se a palavra-passe enviada tiver entre 257 e 1024 bytes, crypt() devolve exatamente * como sinal de erro. O servidor compara esse * com o * da conta e… aceita o login. Uma tentativa, sem necessidade de adivinhar a palavra-passe real.

As notas de lançamento do OpenSSH 10.6p2 descrevem o problema como um «critical security workaround» para Linux com musl e PAM desligado. A equipa OpenSSH considera que a causa de raiz está fora do sshd, mas o ataque passa pelo sshd — e foi aí que foi corrigido. No aviso da Alpine, ainda não havia identificador CVE atribuído à data da publicação.

Quem está afetado — e quem não está

Segundo a Alpine, está afetado quem cumpre todas estas condições:

  • corre o pacote openssh-server da Alpine (compilado sem PAM) ou openssh-server-pam com UsePAM no;
  • tem PasswordAuthentication yes (o valor por omissão do OpenSSH, se ninguém o alterou);
  • existe pelo menos uma conta com o campo de palavra-passe igual a * (root, utilizadores só com chave, utilizador alpine das imagens cloud, contas de diretório sem entrada em shadow);
  • existe pelo menos outra conta local com um hash de palavra-passe $5$ ou $6$ (por exemplo alguém correu passwd).

A Alpine e a Wakefield sublinham que as imagens oficiais tiny-cloud para AWS e Azure (artefactos qcow2, VHD e AMI) trazem o utilizador alpine com campo * e doas sem palavra-passe. Nessas máquinas, assim que exista um hash $6$ no sistema, um atacante que entre como alpine pode tornar-se root.

Não estão afetados, segundo as mesmas fontes: Debian, Ubuntu, Fedora e outros sistemas com biblioteca glibc; OpenSSH com PAM ativo (UsePAM yes); máquinas com PasswordAuthentication no; contentores Docker que não correm sshd; contas bloqueadas com ! no shadow; imagens cloud-init que já desativam o login por palavra-passe.

O que fazer hoje no servidor

  1. Atualize o OpenSSH e reinicie o sshd. Na Alpine, o aviso recomenda apk upgrade -U -a e depois rc-service sshd restart. Só atualizar o pacote não substitui o processo que está a correr: é obrigatório reiniciar o serviço. As versões corrigidas por ramo estão listadas no aviso da Alpine (por exemplo 10.6_p2-r0 no edge; pacotes corrigidos também para 3.16 a 3.24).
  2. Se ainda não puder atualizar: defina PasswordAuthentication no na configuração do sshd e reinicie o serviço. Antes, confirme que o login por chave SSH funciona e mantenha a sessão atual aberta até testar uma nova. Isto fecha a falha por completo, segundo a Alpine.
  3. Confirme se já foi explorada. A Alpine recomenda procurar em /var/log/messages linhas do sshd com Accepted password for em contas que não têm palavra-passe (alpine, root ou utilizadores só com chave). Se não conseguir excluir um login indevido, trate a máquina como comprometida: reveja chaves autorizadas, utilizadores novos e uso de doas.

A Wakefield disponibiliza também um script de verificação para indicar se o servidor está exposto e quais as contas em risco. Use-o apenas em máquinas suas e depois de compreender o que o script faz.

Porque é que isto importa a uma PME portuguesa

Muitos sites e lojas online em Portugal correm em VPS ou em contentores. A Alpine é frequente em imagens Docker oficiais e em «distroless» leves; as imagens tiny-cloud aparecem em tutoriais de AWS e Azure. Mesmo que o seu alojamento diga «Ubuntu» na fatura, pode ter um contentor Alpine a expor SSH por engano, ou um VPS Alpine que alguém montou para um microserviço, um painel ou um proxy.

O padrão é o mesmo de outras falhas recentes em servidores: Vghost no kernel Linux, PHP2Shell ou o outubro negro de atualizações. Uma porta SSH aberta à Internet, com autenticação por palavra-passe ainda ligada, continua a ser uma das portas de entrada mais simples. Esta falha torna o risco concreto mesmo em contas que «não tinham palavra-passe».

Se o servidor for gerido pelo fornecedor de alojamento, peça por escrito se usam Alpine (ou outra distribuição musl), se o OpenSSH já foi atualizado para um pacote com a correção de 5 de novembro e se o sshd foi reiniciado. Se o VPS for seu, a responsabilidade da atualização é sua ou de quem lhe gere a máquina.

Checklist rápido para a semana

  • Inventariar VPS, contentores e imagens cloud que possam ser Alpine, OpenWrt ou outras com musl.
  • Atualizar o OpenSSH (ou o pacote da distribuição) e reiniciar o sshd.
  • Desativar o login por palavra-passe e usar só chaves SSH, sempre que possível.
  • Rever quem tem acesso root ou doas/sudo sem palavra-passe.
  • Confirmar nos registos se houve Accepted password em contas com campo *.
  • Garantir cópias de segurança recentes e testadas — o mesmo princípio que descrevemos em cópias de segurança: como saber se o site volta.

Em resumo

A 5 de novembro de 2026, o OpenSSH 10.6p2 e a Alpine corrigiram uma falha que permite login sem conhecer a palavra-passe em contas com campo *, em sistemas musl sem PAM e com autenticação por palavra-passe ligada. Debian e Ubuntu não entram neste cenário. Quem corre Alpine em VPS ou imagens cloud deve atualizar, reiniciar o sshd e, de preferência, desligar o login por palavra-passe.

Quer uma leitura objetiva do estado do seu site ou servidor? Faça uma auditoria gratuita em audit.marcaweb.pt ou fale com a MarcaWeb para rever o acesso SSH, as atualizações e as cópias de segurança da sua empresa.

Blog

Continue a ler

Ver o serviço de cibersegurança

Gostou do artigo? Vamos falar do seu projecto.

Orçamento gratuito e proposta com preço fechado em 48 horas.