#!/intro

O SSH é um dos pilares da segurança na infraestrutura digital moderna. Utilizado para acesso remoto seguro, transferência protegida de ficheiros e encaminhamento cifrado de tráfego de rede, o protocolo tornou-se essencial em contextos onde a integridade e a confidencialidade das comunicações são requisitos críticos. A sua fiabilidade e versatilidade fazem dele uma ferramenta robusta para suportar operações seguras em ambientes distribuídos.

A computação quântica ameaça comprometer os fundamentos da criptografia clássica, tornando viável a quebra dos algoritmos criptográficos utilizados pelos protocolos que sustentam a segurança do SSH. Este risco, agravado exposição ao modelo de ataque store now, decrypt later, que pode já estar a ser utilizado para recolher e armazenar comunicações cifradas com vista à sua futura quebra, exige uma transição urgente para esquemas resistentes a ataques quânticos (veja também A ameaça quântica: o fim da criptografia clássica).

Neste contexto, a versão 10 do OpenSSH representa um marco significativo na evolução das comunicações seguras sobre o protocolo SSH. Pela primeira vez, esta ferramenta essencial no domínio da administração de sistemas e da automação segura adota, de forma nativa, os mecanismos criptográficos resistentes à computação quântica recentemente normalizados, alinhando-se com os esforços internacionais de modernização criptográfica.

Este avanço deve-se à inclusão do suporte oficial para ML-KEM, um esquema de encapsulamento de chaves resultante da padronização do esquema Kyber. O ML-KEM foi recentemente normalizado pelo NIST no âmbito do processo de seleção de algoritmos criptográficos pós-quânticos, assumindo-se como um componente central da próxima geração de protocolos seguros (veja também Criptografia pós-quântica: os novos algoritmos).


> mlkem768x25519-sha256

Com a versão 10.0, o OpenSSH introduz uma alteração significativa no mecanismo de troca de chaves, adotando como método preferencial o híbrido mlkem768x25519-sha256, introduzido a título experimental na versão 9.9.

Formalmente definido no rascunho do IETF intitulado “PQ/T Hybrid Key Exchange in SSH”, este método híbrido conjuga o ML-KEM com o X25519, um algoritmo de troca de chaves baseado na curva elíptica Curve25519, utilizando SHA-256 como função de derivação.

O suporte para métodos híbridos de troca de chaves já estava disponível desde a versão 8.0, com a introdução do sntrup4591761x25519-sha512, baseado no esquema NTRU Prime. No entanto, este dependia ainda de algoritmos não formalmente padronizados, mantendo assim um carácter experimental. A escolha do mlkem768x25519-sha256 como método preferencial assinala uma transição importante na arquitetura criptográfica do OpenSSH, antecipando os desafios da era quântica.

O novo método de troca de chaves híbrido permite reforçar a segurança ao aplicar ambas as componentes, clássica e pós-quântica, em simultâneo à mesma operação. Neste modelo, a informação permanece segura enquanto pelo menos um dos dois algoritmos se mantiver resistente. Durante o período de incerteza tecnológica, em que tanto a robustez dos novos algoritmos como a ameaça concreta representada por adversários com capacidades quânticas ainda estão em avaliação, este tipo de abordagens híbridas assumem um papel particularmente relevante.

A negociação do método de troca de chaves é feita automaticamente durante o handshake SSH, com preferência pelo mlkem768x25519-sha256 sempre que ambas as partes o suportem. Em ambientes legacy ou mistos, o OpenSSH mantém compatibilidade com métodos tradicionais como curve25519-sha256, ecdh-sha2-nistp256, rsa-sha2-256/512, entre outros, permitindo uma transição gradual e segura.


> derivação

No OpenSSH 10, o método híbrido mlkem768x25519-sha256 é utilizado na derivação da chave de sessão durante o handshake inicial, desde que nenhum outro método seja explicitamente solicitado. A derivação baseia-se na execução paralela de duas operações distintas: uma troca de chaves utilizando X25519 e um encapsulamento de segredo com ML-KEM-768, a variante de categoria de segurança 3 do ML-KEM. Os segredos gerados por ambos os métodos são depois concatenados e processados com SHA-256, originando a chave de sessão usada na comunicação SSH.

C l i e n t e M L X - 2 K 5 E 5 M 1 - 9 7 6 8 C C h h a a v v e e C P L Q P Q C L S H A - 2 5 6 C h a v e K
Diagrama 1: Derivação da chave de sessão com mlkem768x25519-sha256

As chaves efémeras CL (clássica) e PQ (pós-quântica) são geradas dinamicamente durante a negociação e não requerem persistência nem intervenção do utilizador. A geração de chaves para autenticação continua limitada aos pares tradicionais, como Ed25519 ou RSA, criados com o comando ssh-keygen e independentes do mecanismo híbrido. A derivação da chave de sessão K, utilizada para proteger o canal de transporte, é reforçada pelo esquema híbrido, sem afetar os fluxos tradicionais de autenticação, quer por chave pública quer por certificados.


> suporte

A verificação do suporte para algoritmos pós-quânticos no SSH deve começar pela confirmação da versão do OpenSSH instalada. Embora o suporte para o método híbrido mlkem768x25519-sha256 já estivesse disponível desde a versão 9.9, apenas a partir da versão 10.0 é ativado por omissão, sendo anteriormente necessária a sua ativação manual através de configuração explícita.

Para verificar, utilize o comando:

$ ssh -V
OpenSSH_10.0p2, OpenSSL 3.5.0 8 Apr 2025

Em seguida, confirme os métodos de troca de chaves (key exchange, ou kex) suportados pela sua instalação do SSH com o comando:

$ ssh -Q kex
...
curve25519-sha256
curve25519-sha256@libssh.org
sntrup761x25519-sha512
sntrup761x25519-sha512@openssh.com
mlkem768x25519-sha256
...

A presença do método mlkem768x25519-sha256 indica que o cliente SSH suporta o novo mecanismo de troca de chaves.


> utilização

Para verificar se o mlkem768x25519-sha256 está a ser efetivamente utilizado numa ligação SSH, pode usar o modo de depuração com o comando ssh -v. Este modo detalhado mostra todas as etapas do processo de ligação, incluindo a seleção do algoritmo de derivação de chave de sessão.

ssh -v utilizador@servidor
...
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: mlkem768x25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
...

A linha debug1: kex: algorithm: mlkem768x25519-sha256 confirma que o cliente e o servidor negociaram com sucesso a utilização do algoritmo híbrido pós-quântico. Se não aparecer, é provável que o servidor não suporte o algoritmo ou que um outro tenha sido escolhido com base na lista de preferências de ambas as partes.

Para forçar a utilização do algoritmo híbrido durante a ligação pode utilizar o comando:

ssh -o KexAlgorithms=mlkem768x25519-sha256 utilizador@servidor

Caso o servidor suporte o algoritmo híbrido a ligação será estabelecida com sucesso. Se o servidor não suportar a ligação falhará com uma mensagem de erro como:

Unable to negotiate with <IP> port 22: no matching key exchange method found...

A utilização do método mlkem768x25519-sha256 pode também ser ativada através da configuração manual do parâmetro KexAlgorithms nos ficheiros sshd_config e ssh_config.


> conclusão

A adoção de algoritmos híbridos no OpenSSH 10 representa um passo decisivo na transição para a criptografia pós-quântica.

Ao combinar mecanismos clássicos amplamente confiáveis com esquemas resistentes a ataques quânticos, o SSH passa a oferecer uma proteção mais robusta e com visão de futuro, sem comprometer a interoperabilidade com sistemas existentes.

Essa evolução prepara as infraestruturas de comunicação para cenários de longo prazo, em que a segurança de dados precisa resistir não apenas às ameaças atuais, mas também às tecnologias emergentes.

Com a versão 10, o OpenSSH destaca-se como uma ferramenta preparada para os desafios da nova era criptográfica, trazendo a segurança pós-quântica do plano teórico para a prática do dia a dia.

> referencias

IETF – Draft: draft-ietf-sshm-mlkem-hybrid-kex-02
Especificação do algoritmo de troca de chaves híbrido mlkem768x25519-sha256 para SSH.

OpenSSH – Release Notes 10.0
Notas da versão 10.0 do OpenSSH.

> status: resistant
> exit 0