Padrões pós-quânticos do OpenSSH e o aviso de troca de chaves não pós-quântica

Objetivo

Situação em 25 de outubro de 2026. Resolver um aviso de troca de chaves não pós-quântica verificando os pares efetivamente envolvidos e suas configurações. Antes de alterar a política, conferir novamente as orientações pós-quânticas do OpenSSH, a documentação do pacote instalado e a configuração efetiva. Os marcos de versão abaixo descrevem funcionalidades do projeto original, não o nível mais recente de correções de segurança.

As orientações do OpenSSH registram um padrão pós-quântico a partir da versão 9.0, inicialmente com o híbrido sntrup. O suporte a mlkem768x25519-sha256 chegou na versão 9.9 e tornou-se o padrão na 10.0. O OpenSSH 10.1, lançado em 6 de outubro de 2025, introduziu um aviso quando uma conexão seleciona uma troca não pós-quântica.

Pré-requisitos

Ter uma conta de teste autorizada, acesso às configurações das duas pontas e uma sessão administrativa já aberta ou um console para recuperação. O aviso diz respeito à proteção contra a decifragem futura de tráfego gravado. Por si só, ele não comprova interceptação, comprometimento nem falha na verificação da chave do host.

Passos

1. Identificar a implementação SSH real em cada endpoint, incluindo appliances e serviços Git incorporados. Executar ssh -V no cliente. Um pacote de nome semelhante ou a versão do cliente não comprova o que um serviço remoto suporta.

2. Inspecionar a capacidade local com ssh -Q kex e depois as configurações aplicadas ao destino real:

   ssh -G server.example
   

   Revisar kexalgorithms e as configurações específicas do host que se aplicam. A consulta dos algoritmos suportados não representa a lista efetiva de permissão, e nenhuma das duas corresponde ao resultado negociado.

3. Em um servidor OpenSSH, usar sshd -T com privilégios suficientes para inspecionar a configuração efetiva. Usar os parâmetros de conexão de -C quando for necessário avaliar configurações condicionais relevantes. Revisar arquivos incluídos e restrições geridas centralmente antes de editar qualquer coisa.

4. Dar preferência a atualizações suportadas pelo fornecedor e à remoção de restrições obsoletas que suprimam algoritmos híbridos. Pares mais antigos podem anunciar sntrup761x25519-sha512@openssh.com; as notas da versão 9.9 acrescentam explicitamente o nome sem qualificador sntrup761x25519-sha512. Essa informação é mais precisa que a nomenclatura abreviada da visão geral pós-quântica. Um par que use o híbrido anterior não precisa ser classificado como exclusivamente clássico só porque não tem ML-KEM. Confirmar os nomes exatos aceitos por cada compilação.

5. Validar uma configuração editada do servidor com sshd -t antes do procedimento normal de recarga da plataforma. Manter aberta a sessão de recuperação. Estabelecer uma conexão separada sem reutilizar uma sessão multiplexada:

   ssh -vv -S none server.example
   

   Ler o algoritmo de troca de chaves selecionado na saída de diagnóstico e verificar a autenticação normal do host e o login. Encerrar a sessão de teste ao terminar. Evitar publicar logs de diagnóstico sem ocultar nomes de hosts ou informações de contas.

6. Se um par antigo ainda não puder ser atualizado, documentar seu responsável, a sensibilidade dos dados e o plano de substituição. Manter o aviso visível, salvo quando for necessária uma exceção revisada e de escopo restrito. Silenciar WarnWeakCrypto altera os avisos; não melhora a criptografia.

Resultado esperado

Uma nova conexão seleciona uma troca híbrida permitida, ou permanece uma exceção legada registrada explicitamente. Os clientes existentes continuam se conectando como previsto, e a verificação da chave do host continua obrigatória.

Limites e base de verificação

Este procedimento se baseia na documentação do projeto original, não em um parque de máquinas testado. O empacotamento e as políticas das distribuições podem diferir. Não desativar verificações estritas da chave do host, remover controles de autenticação nem substituir chaves de usuários apenas para resolver um aviso de troca de chaves. Uma troca híbrida bem-sucedida é evidência sobre o acordo de chaves daquela conexão, não uma afirmação de que todos os mecanismos de autenticação sejam pós-quânticos.