O email do CERT.br chegou depois que uma varredura do OpenSSH encontrou a porta 22 aberta em um servidor de laboratório da Promovaweb. A máquina usava Debian 12, estava ligada havia 721 dias e anunciava OpenSSH_9.2p1 Debian-2+deb12u2.

Eu gravei a manutenção no vídeo Como corrigir Vulnerabilidade SSH, incluindo uma primeira tentativa que falhou e a conferência do Docker no final. Os servidores de produção ficavam atrás do firewall e não apareceram no aviso, por isso o laboratório também mostrou a diferença prática criada pelo controle de acesso.

Direto ao ponto

O Debian 12 recebeu a correção da CVE-2024-6387 em 1:9.2p1-2+deb12u3, e o servidor citado ainda usava deb12u2. A manutenção atualiza os índices do APT, instala a revisão candidata do OpenSSH e reinicia somente o ssh.service, sem reboot do computador.

No Debian 13, você deve seguir a candidata oferecida pelos repositórios atuais do Trixie, pois a numeração pertence a outra linha do OpenSSH. Mantenha a sessão atual aberta, valide a configuração com sshd -t, confira KillMode=process e encerre o terminal antigo apenas depois que uma segunda conexão autenticar.

O deb12u2 do alerta ainda ficava abaixo da correção

A DSA-5724-1 do Debian descreve uma condição de corrida no tratador de sinais do sshd. Sob as condições registradas no aviso, uma conexão sem autenticação concluída dentro do LoginGraceTime pode alcançar código inseguro no processo privilegiado.

O mesmo documento fixa 1:9.2p1-2+deb12u3 como a primeira revisão corrigida para o Debian 12 Bookworm. O deb12u2 informado pelo CERT.br já trazia o ajuste da CVE-2023-48795, mas ainda não continha o patch do Debian para a regreSSHion.

Na consulta de 17 de julho de 2026, o rastreador da CVE-2024-6387 mostra 1:9.2p1-2+deb12u10 no Debian 12 e 1:10.0p1-7+deb13u4 no Debian 13. Essas revisões podem avançar, então eu instalo a candidata atual do repositório oficial em vez de procurar manualmente o mínimo publicado em 2024.

O banner OpenSSH_9.2p1 não confirma o patch

O OpenSSH corrigiu a falha na linha upstream 9.8, conforme a nota oficial da versão. O Debian preserva a versão-base e incorpora patches por backport, portanto um Bookworm corrigido ainda pode anunciar OpenSSH_9.2p1.

Verifique o trecho completo da revisão, como Debian-2+deb12u10, porque ele identifica o trabalho mantido pela distribuição. O dpkg-query mostra a versão instalada no host, e o apt-cache policy informa qual revisão o APT oferece naquele momento.

Um scanner remoto pode reconhecer apenas parte do banner e manter o host como possivelmente vulnerável depois da manutenção. A resposta técnica precisa registrar a revisão Debian completa, o horário do upgrade e uma nova conexão aceita pelo processo iniciado depois da instalação.

O laboratório exposto explica por que o CERT.br encontrou a máquina

O servidor do vídeo ficava aberto para testes e homologações, com a porta 22 visível na internet. O CERT.br conseguiu iniciar uma conexão, ler o banner e comparar a versão, enquanto os hosts de produção atrás do firewall não responderam à mesma varredura.

O firewall reduz a superfície pública, mas não substitui a atualização do software em uma máquina autorizada a receber conexões. Uma VPN ou uma lista restrita de IPs também pode retirar a porta administrativa da internet aberta, desde que o acesso de recuperação continue documentado e testado.

Confira a distribuição e a revisão do OpenSSH

Comece identificando a distribuição e comparando a revisão instalada com a candidata dos repositórios. Estes comandos não alteram o servidor e mostram se a máquina usa Debian 12 ou 13, qual revisão está no disco e qual versão o APT pretende instalar.

1
cat /etc/os-release
2
dpkg-query -W -f='${Version}\n' openssh-server
3
apt-cache policy openssh-server

No laboratório do vídeo, a revisão instalada terminava em deb12u2, abaixo do mínimo corrigido deb12u3. No Debian 13, a candidata deve pertencer à linha corrigida do Trixie e, na data desta publicação, a página do openssh-server no Debian 13 mostra 1:10.0p1-7+deb13u4.

Uma candidata ainda vulnerável indica que as fontes do APT precisam de revisão, e a instalação deve parar nesse ponto. Um arquivo .deb obtido fora da cadeia assinada cria outra exposição, enquanto bookworm-security ou trixie-security mantém a atualização ligada aos repositórios do Debian.

No teste seguinte, o próprio sshd lê a configuração sem reiniciar o serviço. A ausência de saída indica que a sintaxe foi aceita, enquanto uma mensagem de erro precisa ser corrigida com a sessão atual ainda aberta.

1
sudo sshd -t

A primeira tentativa do vídeo falhou por causa dos índices do APT

Na gravação, eu executei apt-get install --only-upgrade openssh-server, mas o APT não encontrou alguns arquivos necessários. O próprio erro apontou para índices antigos, então executei apt-get update e repeti a instalação com sucesso.

Essa cena é útil porque mostra o motivo de atualizar os índices na mesma janela da manutenção. Um apt-get update executado horas atrás ainda pode deixar a instalação sem a referência atual do repositório, e a saída do APT deve orientar a próxima ação.

No guia, eu nomeio os três componentes do OpenSSH para deixar o escopo explícito. O APT também pode atualizar o OpenSSL e bibliotecas relacionadas quando essas dependências forem necessárias para os componentes selecionados.

1
sudo apt update
2
sudo apt install --only-upgrade \
3
  openssh-server \
4
  openssh-client \
5
  openssh-sftp-server

O --only-upgrade limita a solicitação aos componentes já instalados, mas não impede o APT de atualizar dependências exigidas por eles. No vídeo, a tela também informou que outras 113 atualizações permaneceriam pendentes, pois aquela manutenção cuidava especificamente do SSH.

Reinicie somente o SSH e preserve uma saída de recuperação

A unidade padrão do SSH no Debian usa KillMode=process, opção que encerra o processo principal sem matar os processos filhos das sessões autenticadas. O manual do Debian sobre serviços Unix apresenta essa configuração, mas um override local pode alterar o comportamento efetivo.

Confira o valor, repita o teste da configuração e mantenha aberto o console web do provedor quando ele estiver disponível. Depois execute o restart do serviço e leia o estado completo, sem reinicializar a VPS.

1
sudo systemctl show ssh -p KillMode
2
sudo sshd -t
3
sudo systemctl restart ssh
4
sudo systemctl --no-pager --full status ssh

A saída esperada do primeiro comando é KillMode=process, e o estado final deve mostrar active (running). Outra configuração exige uma forma de recuperação já acessível, pois o restart pode encerrar a sessão usada para administrar a máquina.

Use systemctl restart ssh nesta manutenção remota e não execute systemctl stop ssh. O stop interrompe o serviço sem iniciá-lo novamente, o que pode retirar o acesso administrativo e obrigar você a recorrer ao console do provedor.

Teste outro login e confira o Docker

A primeira sessão fica em um prompt conhecido enquanto outro terminal abre para o teste. A segunda conexão precisa usar o mesmo endereço e a mesma porta da rotina normal, pois um teste local não atravessa a rota, o firewall nem a autenticação vistos pela rede.

Depois do login, eu confiro a revisão instalada, o horário de início do processo principal e os containers em execução. Esses registros conectam os arquivos atualizados ao serviço que aceitou a nova sessão e mostram se o Docker permaneceu ativo naquele host.

1
dpkg-query -W -f='${Version}\n' openssh-server
2
systemctl show ssh -p ExecMainStartTimestamp -p MainPID
3
docker ps

No laboratório gravado, o docker ps continuou mostrando os containers depois do restart do SSH. Essa observação vale para a manutenção registrada, mas uma atualização diferente, um hook local ou outra mudança simultânea pode produzir outro resultado e precisa ser conferida no próprio servidor.

O tmux para produtividade no terminal ajuda a preservar a sessão e o histórico durante uma investigação remota. Ele não substitui o segundo login nem o console do provedor, mas reduz a reconstrução do trabalho quando a conexão local oscila.

A correção e a investigação cumprem funções diferentes

O email do CERT.br afirma que o host está possivelmente vulnerável e explica que a entidade não testou a informação recebida dos parceiros. A revisão antiga exige atualização, mas não permite declarar que alguém executou código no servidor.

A aplicação do patch fica separada da análise de comprometimento, porque a instalação não apaga um acesso anterior. Os registros do serviço, o histórico de autenticação, os logins recentes e as chaves autorizadas oferecem uma primeira leitura defensiva do período indicado no alerta.

1
sudo journalctl -u ssh --since "2026-07-15 00:00:00"
2
sudo less /var/log/auth.log
3
last -ai
4
sudo find /root /home \
5
  -path '*/.ssh/authorized_keys' \
6
  -type f -ls

Procure autenticações desconhecidas, nomes de usuário inesperados, chaves novas e horários incompatíveis com o uso do laboratório. Um log ou uma chave suspeita deve ser preservada para análise autorizada, pois apagar arquivos ou limpar logs remove o histórico necessário para entender o alcance.

Uma confirmação de acesso indevido como root exige reinstalação a partir de uma base confiável e troca das credenciais alcançáveis pelo host. Esse trabalho pode exigir uma consultoria de infraestrutura quando a empresa não tem um profissional preparado para conduzir a resposta ao incidente.

Os 721 dias de uptime deixaram uma lição de manutenção

A máquina do vídeo era um laboratório, por isso permaneceu ligada e acumulou revisões pendentes por quase dois anos. Esse histórico explica o deb12u2, mas não serve como referência para um servidor de produção que atende clientes e precisa de uma janela recorrente de manutenção.

Na Trilha DevOps da Promovaweb, eu conecto terminal, firewall, atualização e observabilidade porque cada mudança precisa deixar uma verificação. O grupo técnico do Discord da Promovaweb também permite discutir a rotina sem publicar IP, domínio, credencial ou trecho sensível de log.

O encerramento desta correção cabe em quatro registros: revisão atual instalada, configuração aceita, ssh.service iniciado depois do upgrade e nova conexão autenticada. Com esses quatro registros, você confirma o processo novo, verifica as aplicações daquele host e mantém a investigação de possível acesso indevido em uma trilha separada.