SSH pós-quântico: mlkem768x25519-sha256 no OpenSSH

O OpenSSH já oferece acordo de chaves pós-quântico hoje, sem biblioteca adicional e sem patch. O método híbrido mlkem768x25519-sha256 foi adicionado no OpenSSH 9.9 (19 de setembro de 2024) e se tornou o acordo de chaves padrão no OpenSSH 10.0 (9 de abril de 2025). Este guia mostra como identificar qual método uma sessão realmente negociou, como dar preferência ao método híbrido em versões que o suportam sem usá-lo por padrão, o que significa o aviso do OpenSSH 10.1 sobre acordos de chaves não pós-quânticos e por que as chaves de host SSH continuam clássicas.

O que o mlkem768x25519-sha256 faz de fato

O nome descreve a construção. ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, um KEM ou mecanismo de encapsulamento de chaves) com o conjunto de parâmetros 768, X25519 (Diffie-Hellman de curva elíptica sobre a Curve25519) e SHA-256 como função hash. O NIST publicou o ML-KEM como FIPS 203 em 13 de agosto de 2024 (FIPS 203), e a página de referência do ML-KEM lista seus conjuntos de parâmetros e seu status.

O método é híbrido: a chave de sessão é derivada tanto do segredo compartilhado do ML-KEM quanto do segredo compartilhado do X25519. Um cliente e um servidor que o negociam permanecem protegidos enquanto pelo menos um dos dois componentes resistir. Essa é a escolha conservadora enquanto as implementações pós-quânticas ainda são recentes, e é a direção indicada pelas orientações europeias: acordo de chaves híbrido em vez de uma troca puramente pós-quântica.

O acordo de chaves é a primeira prioridade no SSH pelo mesmo motivo que no TLS. Um atacante que grava hoje uma sessão cifrada pode armazená-la e atacá-la mais tarde. É o cenário harvest now, decrypt later (HNDL), descrito no nosso artigo sobre harvest now, decrypt later. Se a troca tiver sido puramente clássica, um computador quântico suficientemente grande permitiria decifrar retroativamente o tráfego gravado. A autenticação é diferente: um atacante capaz de forjar uma assinatura de host precisa usá-la durante uma conexão ativa, então a migração das assinaturas pode vir depois sem expor as sessões passadas.

Etapa 1: verifique suas versões e o que suas sessões negociam

Quais métodos o binário suporta

ssh -V
ssh -Q kex
ssh -Q kex | grep mlkem

ssh -Q kex lista os métodos de troca de chaves compilados no binário, independentemente da configuração. Se mlkem768x25519-sha256 aparecer, a versão o suporta. As duas pontas precisam suportá-lo, então execute a mesma verificação no servidor: um cliente moderno conversando com um servidor antigo recorre ao que os dois tiverem em comum.

Qual método esta sessão usou

ssh -v user@server 2>&1 | grep -i 'kex: algorithm'

A saída detalhada vai para a saída de erro padrão, daí o redirecionamento. Uma sessão que usa o método híbrido exibe uma linha no formato debug1: kex: algorithm: mlkem768x25519-sha256. Esta é a verificação mais útil de todas, porque informa o que foi negociado, e não o que você acredita estar configurado.

Qual é a configuração efetiva

ssh -G server | grep -i kexalgorithms
sudo sshd -T | grep -i kexalgorithms

ssh -G exibe a configuração do cliente que se aplicaria a esse destino, depois de resolvidos todos os blocos Host e includes. sshd -T exibe a configuração efetiva do servidor e exige privilégios de root. Execute os dois antes de alterar qualquer coisa e guarde a saída: ela serve como evidência de inventário.

A linha do tempo das versões

Fonte: as notas de versão do OpenSSH. Leitura prática: a partir da 9.9 o método já está disponível, a partir da 10.0 ele é preferido automaticamente e, entre a 9.0 e a 9.9, você ainda tem acordo de chaves pós-quântico por meio do sntrup761x25519-sha512@openssh.com.

Etapa 2: dê preferência ao mlkem768x25519-sha256 sem quebrar pares mais antigos

A diretiva é KexAlgorithms, usada em ssh_config no lado do cliente e em sshd_config no lado do servidor. Ela aceita três prefixos: ^ insere os métodos listados no início da lista padrão embutida, + os adiciona ao final e - os remove. Inserir no início é a opção segura, porque o restante da lista padrão continua disponível como alternativa.

Cliente, em ~/.ssh/config ou em um arquivo complementar em /etc/ssh/ssh_config.d/:

Host *
    KexAlgorithms ^mlkem768x25519-sha256

Servidor, em /etc/ssh/sshd_config ou em um arquivo complementar em /etc/ssh/sshd_config.d/:

KexAlgorithms ^mlkem768x25519-sha256

Se você preferir uma lista explícita e ordenada, mantenha os métodos clássicos no final para que os pares ainda não atualizados continuem conseguindo se conectar:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org

Valide a configuração antes de recarregar e prefira recarregar em vez de reiniciar:

sudo sshd -t
# the service name varies by distribution: ssh on Debian and Ubuntu, sshd on many others
sudo systemctl reload sshd

Uma ordem de operações que evita bloqueios de acesso: teste primeiro em homologação, mantenha uma sessão privilegiada aberta durante o recarregamento, depois abra uma segunda sessão e execute novamente a verificação com ssh -v antes de fechar a primeira. Não remova métodos clássicos da lista de um servidor até que todos os clientes que se conectam a ele tenham sido inventariados: jump hosts, executores de automação, agentes de backup, sondas de monitoramento, appliances de rede e bibliotecas SSH embarcadas são a causa habitual de indisponibilidade nesse ponto.

Etapa 3: interprete corretamente o aviso do OpenSSH 10.1

O OpenSSH 10.1 (6 de outubro de 2025) emite um aviso quando uma conexão negocia um acordo de chaves não pós-quântico. A opção é WarnWeakCrypto e vem ativada por padrão. Dois pontos são importantes para a operação.

Primeiro, é um aviso, não um bloqueio: a conexão é concluída normalmente. Ele indica que é a outra ponta da conexão que precisa de atenção. Segundo, sntrup761x25519-sha512@openssh.com é, ele próprio, um híbrido pós-quântico, então uma sessão que o negocia não é o caso visado por esse aviso. Ele apenas não é baseado em um padrão do NIST, e é por isso que o ML-KEM é o caminho a seguir em termos de interoperabilidade e de requisitos de contratação.

Trate cada aviso como uma linha do inventário: qual par, qual versão, qual equipe é responsável. Se mais tarde você quiser recusar trocas puramente clássicas em vez de apenas emitir avisos, defina uma lista KexAlgorithms explícita contendo apenas métodos pós-quânticos, e faça isso somente quando suas verificações mostrarem que todos os pares os suportam.

Etapa 4: as chaves de host continuam clássicas por enquanto

No SSH, o acordo de chaves e a autenticação são negociados separadamente. As chaves de host e as chaves de usuário são algoritmos de assinatura: ssh-ed25519, rsa-sha2-256, rsa-sha2-512 e variantes de ECDSA. As versões acima mudaram o acordo de chaves, não os tipos de chave de host, então a situação realista hoje é uma troca híbrida protegendo uma sessão que ainda é autenticada com uma chave de host clássica. Você pode ver qual foi usada na mesma saída detalhada:

ssh -v user@server 2>&1 | grep -i 'host key'

Esse estado intermediário é aceitável pelo motivo apresentado anteriormente: a falsificação de assinaturas exige um ataque durante a conexão e não expõe sessões gravadas no passado. O NIST padronizou o ML-DSA como FIPS 204 em 13 de agosto de 2024 (veja a página do ML-DSA), e a migração das assinaturas no SSH depende de trabalho adicional no protocolo e nas implementações. Até lá, registre essa lacuna em vez de ocultá-la, prefira chaves de host ed25519 e, onde RSA for usado, siga as orientações de tamanho de chave aplicáveis à sua organização.

O que registrar para auditorias e inventários

O SSH costuma ficar de fora de inventários criptográficos que já cobrem bem o TLS. O requisito 12.3.3 do PCI DSS v4.0.1 exige que os cipher suites e protocolos em uso sejam documentados e revisados pelo menos a cada 12 meses, e ele é obrigatório desde 31 de março de 2025 (veja PCI DSS v4.0.1). No âmbito do DORA, o Art. 6 do Regulamento Delegado (UE) 2024/1774 da Comissão exige uma política de criptografia e de controles criptográficos que inclua disposições para atualizar ou substituir a tecnologia criptográfica com base na evolução da criptoanálise, e o Art. 7 exige a gestão de chaves ao longo de todo o seu ciclo de vida (veja a página sobre o RTS do DORA). O que esses textos exigem literalmente é a política e o inventário. O mapeamento abaixo é a nossa interpretação de como evidenciar isso para o SSH, e não a citação de nenhum requisito. Trata-se de informação, não de aconselhamento jurídico.

Próximo passo: verifique o restante da sua superfície

O SSH é um protocolo entre vários, e a mesma construção híbrida existe no TLS como X25519MLKEM768. A forma mais rápida de ver a situação dos seus serviços públicos é analisar seu domínio com o PQC Status, que informa os grupos de troca de chaves negociados, as versões de TLS e a cadeia de certificados. Combine esse resultado com as verificações de SSH acima, uma linha por host, e você terá o início de um inventário criptográfico real em vez de uma suposição.