SSH pós-quântico no Ubuntu: o que mudou

O que mudou no SSH pós-quântico

O SSH pós-quântico já está ativado para a maioria das pessoas, sem necessidade de configuração. Um cliente OpenSSH atual, ao comunicar com um servidor OpenSSH atual, seleciona por predefinição uma troca de chaves híbrida pós-quântica. Assim, a chave da sessão resiste a um atacante que registe o seu tráfego hoje e o desencripte daqui a vários anos. A proteção é real, mas é mais limitada do que a expressão "SSH seguro contra computadores quânticos" sugere.

Primeiro, dois termos. SSH (secure shell) é o protocolo usado para iniciar sessão num servidor. A troca de chaves, normalmente designada por "kex", é o primeiro passo de todas as ligações SSH: os dois lados acordam um segredo partilhado, que encripta tudo o que se segue. Foi a troca de chaves que mudou. Nada mais mudou.

Não confie nesta página; execute os comandos

Todos os nomes de algoritmos abaixo são obtidos por comandos que pode executar no seu próprio sistema. Isto é intencional. O padrão muda a cada versão do OpenSSH. Por isso, um guia escrito há dois anos pode indicar um algoritmo que a sua máquina já não prefere, sem ter como o informar. Aprenda estes comandos e deixará de depender de artigos sobre este assunto, incluindo este.

Comece pelo que a sua compilação sabe fazer.

ssh -V
ssh -Q kex

ssh -V imprime uma linha de versão que começa por OpenSSH_, seguida pelo sufixo do pacote Ubuntu e pela versão do OpenSSL. ssh -Q kex imprime um algoritmo de troca de chaves por linha. Numa compilação com suporte pós-quântico, encontrará nomes como mlkem768x25519-sha256 e sntrup761x25519-sha512@openssh.com nessa lista, junto de nomes clássicos como curve25519-sha256.

O que a sua compilação suporta não é o que ela oferece

Esta é a distinção que a maioria dos artigos ignora. ssh -Q kex responde a uma pergunta: o que este binário poderia fazer. Não responde à pergunta que interessa: o que esta ligação vai efetivamente propor. As duas listas são diferentes, e é nessa diferença que as recomendações antigas causam problemas reais.

ssh -G example.com | grep -i '^kexalgorithms'
sudo sshd -T | grep -i '^kexalgorithms'

ssh -G <host> mostra a configuração efetiva do cliente para esse host, depois de ~/.ssh/config e /etc/ssh/ssh_config serem aplicados. sshd -T faz o mesmo no servidor. Cada um mostra uma única linha kexalgorithms por ordem de preferência, e o primeiro nome nessa linha é a primeira escolha desse lado. É essa linha que é enviada pela rede.

A diferença não é teórica. O OpenSSH 8.5, lançado em 2021-03-03, adicionou sntrup761x25519-sha512@openssh.com e deixou-o deliberadamente fora da lista predefinida. Nessa versão, ssh -Q kex mostra o algoritmo, mas ssh -G não, o que significa que o binário consegue fazer uma troca de chaves pós-quântica, mas nenhuma ligação chega a solicitá-la.

Leia o algoritmo que a sua ligação negociou

ssh -v example.com 2>&1 | grep 'kex: algorithm'

Entre um cliente atual e um servidor atual, o comando apresenta:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 é um híbrido. Executa ML-KEM (mecanismo de encapsulamento de chaves baseado em reticulados, normalizado como FIPS 203) com o conjunto de parâmetros 768, em conjunto com Diffie-Hellman de curva elíptica X25519, e combina ambas as saídas na chave da sessão.

Contra um servidor mais antigo, pode ver isto:

debug1: kex: algorithm: curve25519-sha256

Esse nome não tem uma componente pós-quântica. curve25519-sha256 é apenas Diffie-Hellman de curva elíptica, e um computador quântico de grande escala consegue quebrá-lo. Essa é a razão para a alteração do padrão.

Uma regra de negociação explica por que uma única máquina antiga pode limitar uma sessão. O cliente envia a sua lista por ordem de preferência, o servidor envia a sua própria lista e o algoritmo escolhido é o primeiro nome da lista do cliente que também aparece na lista do servidor. A preferência do cliente prevalece, por isso o mais antigo dos dois extremos determina até onde se chega na lista. Atualizar o portátil não atualiza uma sessão para um servidor que nunca ouviu falar de ML-KEM.

Remova grep e ssh -v para mostrar o restante da negociação, incluindo a linha de que trata a próxima secção:

debug1: kex: host key algorithm: ssh-ed25519

Qual versão do OpenSSH tornou a troca híbrida o padrão

As notas de versão upstream mostram uma sequência clara. As datas são mais importantes do que os números das versões, porque mostram há quanto tempo isto funciona silenciosamente.

• 8.5, lançada em 2021-03-03, adicionou sntrup761x25519-sha512@openssh.com e deixou-a desativada por padrão.
• 9.0, lançada em 2022-04-08, ativou-a. As notas dizem que o OpenSSH passaria a "usar por padrão o método de troca de chaves híbrido Streamlined NTRU Prime + x25519". Esta é a versão em que uma troca de chaves pós-quântica passou a ser o comportamento normal.
• 9.9, lançada em 2024-09-19, adicionou mlkem768x25519-sha256 como uma segunda opção. A mesma versão atribuiu ao método anterior o nome registado na IANA, sntrup761x25519-sha512, pelo que as compilações mais recentes o apresentam com ambas as designações.
• 10.0, lançada em 2025-04-09, tornou mlkem768x25519-sha256 o padrão para o acordo de chaves.
• 10.1, lançada em 2025-10-06, adicionou um aviso no cliente quando uma ligação negoceia uma troca de chaves sem uma componente pós-quântica. O comportamento é controlado pela opção WarnWeakCrypto em ssh_config e está ativado por padrão.

Abril de 2022 é a data que vale a pena memorizar. Qualquer par de máquinas com OpenSSH 9.0 ou posterior faz uma troca de chaves pós-quântica desde então, sem configuração e sem aviso para a pessoa que introduz ssh.

Qual versão do Ubuntu o inclui

O Ubuntu fixa uma versão do OpenSSH em cada lançamento e depois integra nela correções de segurança sem alterar o número da versão. Portanto, o lançamento do Ubuntu em execução determina o algoritmo predefinido. Verifique a máquina que está à sua frente com ssh -V em vez de confiar numa lista. Em agosto de 2026, o arquivo contém estas versões:

• 22.04 LTS inclui 1:8.9p1, anterior à predefinição da versão 9.0; por isso, uma instalação padrão negocia curve25519-sha256.
• 24.04 LTS inclui 1:9.6p1, posterior à versão 9.0 e anterior à 9.9; por isso, a predefinição é sntrup761x25519-sha512@openssh.com e não existe ML-KEM.
• 25.10 inclui 1:10.0p1, cuja predefinição é mlkem768x25519-sha256.
• 26.04 LTS inclui 1:10.2p1, cuja predefinição é mlkem768x25519-sha256 e que avisa sobre ligações que não são pós-quânticas.

Analise um par real de máquinas. Um portátil com 26.04 liga-se a um servidor com 24.04. A primeira escolha do cliente, mlkem768x25519-sha256, não está na lista do servidor com a versão 9.6. A escolha pós-quântica seguinte do cliente que o servidor também suporta é sntrup761x25519-sha512@openssh.com, e esse é o nome que ssh -v apresenta. A troca de chaves da sessão é pós-quântica, apesar de o servidor ter sido compilado em 2024, sem qualquer configuração feita por alguém.

O caso do 22.04 funciona no sentido inverso e mostra exatamente por que razão ssh -Q kex, por si só, pode induzir em erro. O OpenSSH 8.9 conhece o nome sntrup761x25519-sha512@openssh.com, pelo que ssh -Q kex nesse sistema apresenta-o. No entanto, a proposta predefinida não o inclui, e a negociação acaba por usar curve25519-sha256. Num cliente OpenSSH 10.1 ou posterior, a ligação informa-o:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

Esse aviso é um facto sobre o servidor ao qual está a ligar, não sobre o seu cliente. A solução é atualizar o servidor. Definir WarnWeakCrypto no remove a mensagem e não altera a ligação.

Por que usar um modo híbrido e o que significa harvest now, decrypt later

A ameaça é simples. Um atacante que consiga observar o seu tráfego regista hoje os bytes cifrados e armazena-os. Hoje, não consegue lê-los. Mantém-nos guardados até existir um computador quântico suficientemente grande para quebrar X25519 e, então, lê-os. Isto é designado por harvest now, decrypt later ou store now, decrypt later. Não exige nada sofisticado do atacante no presente. Exige espaço em disco e paciência.

A cifragem tem este problema, mas as assinaturas não, e essa assimetria determina todo o resto. Um texto cifrado capturado mantém o seu valor enquanto os dados nele contidos continuarem sensíveis. Uma assinatura só tem de ser impossível de falsificar no momento em que é verificada. Quebrar um algoritmo de assinatura em 2035 permite a alguém fazer-se passar por um servidor em 2035. Não permite voltar atrás e falsificar um início de sessão de 2026. Por isso, foi necessário corrigir primeiro a troca de chaves; a parte das assinaturas pode esperar.

Híbrido significa que ambos os algoritmos são executados e que ambos os resultados alimentam a chave de sessão. Para recuperar o segredo por trás de mlkem768x25519-sha256, um atacante tem de quebrar ML-KEM 768 e X25519. A combinação é deliberada: ML-KEM é muito mais recente do que X25519 e teve muito menos tempo sob análise de criptoanalistas. Assim, uma falha descoberta no algoritmo novo não elimina a proteção que já tinha.

O que é protegido e o que não é

A troca de chaves é protegida. O segredo partilhado que cifra a sua sessão resultou de uma troca híbrida, por isso uma gravação dessa sessão feita hoje não se torna legível quando surgirem computadores quânticos.

A chave do host não é protegida. A linha debug1: kex: host key algorithm: ssh-ed25519 identifica uma assinatura clássica, tal como rsa-sha2-512 e os tipos ECDSA (algoritmo de assinatura digital de curva elíptica). Um atacante com acesso a um computador quântico funcional poderia falsificar essa assinatura e fazer-se passar pelo seu servidor, mas apenas durante uma ligação ativa nesse momento futuro, nunca contra tráfego gravado agora.

A sua chave de início de sessão também não é protegida. A chave em ~/.ssh/id_ed25519 é o mesmo tipo de assinatura clássica, e o mesmo raciocínio aplica-se a ela. O que protege essa chave este ano é o local onde está armazenada e quem pode lê-la. Por isso, uma gestão sensata das chaves SSH reduz o seu risco real muito mais do que qualquer nome de algoritmo nesta página.

Não há nada que possa fazer quanto a nenhum desses pontos, porque ainda não existe uma alternativa para a qual mudar. O OpenSSH afirmou que o suporte para assinaturas pós-quânticas chegará numa versão futura. Até essa versão ser lançada, o OpenSSH não terá nenhum tipo de chave de host pós-quântica nem nenhum tipo de chave de utilizador pós-quântica, e ssh-keygen não tem nenhuma para lhe oferecer. Um guia que lhe diga para gerar uma está a descrever software que ainda não existe.

O TLS no mesmo servidor é uma questão separada, com uma resposta diferente. TLS (segurança da camada de transporte) é o protocolo usado pelo seu servidor Web na porta 443, e corresponde a uma base de código diferente, com um calendário diferente. Atualizar o OpenSSH não altera nada nesse ponto. Se estiver a usar um certificado autoassinado para um serviço privado no mesmo VPS, a assinatura e a troca de chaves desse certificado são determinadas pelo OpenSSL e pelo seu servidor Web. Por isso, analise essa pilha separadamente.

O que um operador sensato faz agora

Mantenha o OpenSSH atualizado e fique por aí. Essa é realmente toda a estratégia para este problema. sudo apt update && sudo apt upgrade mantém-no na versão disponibilizada pela sua release do Ubuntu, e passar para uma release mais recente do Ubuntu é o que o atualiza para uma versão mais recente do OpenSSH. Ativar as atualizações de segurança automáticas faz com que essas correções sejam aplicadas sem depender da sua memória. Compilar o OpenSSH a partir do código-fonte para acompanhar o nome de um algoritmo é uma má troca, porque perde as atualizações de segurança da distribuição no serviço mais exposto do servidor. Se ainda assim obtiver o código-fonte, confirme o download com o checksum publicado antes de o compilar.

Não escreva manualmente uma linha KexAlgorithms. Esta é a única ação que, de forma consistente, piora as coisas. Um guia de hardening de 2018 fornece uma lista que estava correta em 2018, e colá-la em sshd_config substitui a lista predefinida em vez de a complementar. Todos os algoritmos criados desde então ficam excluídos, pelo que um servidor que teria negociado mlkem768x25519-sha256 sozinho passa silenciosamente para o que restar na lista fixada. Execute sudo sshd -T | grep -i '^kexalgorithms' em qualquer servidor que tenha herdado. Se essa linha for mais curta do que a de uma instalação nova da mesma release, alguém fixou a lista.

Se tiver uma razão real para alterar a lista, adicione elementos em vez de a substituir. O OpenSSH interpreta um + inicial como adicionar no fim, um - inicial como remover e um ^ inicial como mover para o início.

KexAlgorithms ^mlkem768x25519-sha256

Teste o ficheiro antes de depender dele. sudo sshd -t analisa a configuração e não imprime nada quando ela é válida. Uma linha KexAlgorithms que indique um algoritmo que a compilação não inclui impede o arranque do sshd e, num servidor remoto, isso significa que não consegue voltar a entrar. Por isso, mantenha uma segunda sessão aberta enquanto trabalha. Quando as listas dos dois lados deixam de ter elementos em comum, o cliente informa-o claramente:

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256

Interprete o marketing de "quantum-safe" como uma afirmação sobre uma camada. Quando um fabricante classifica um produto como quantum-safe, está a descrever a camada que identificou, normalmente uma troca de chaves. Peça o nome do algoritmo e o protocolo a que se aplica. Para o OpenSSH em agosto de 2026, a versão honesta da afirmação é que a troca de chaves é híbrida e pós-quântica, enquanto as assinaturas são clássicas. Qualquer afirmação mais abrangente deve vir acompanhada de um nome que possa encontrar na saída de ssh -Q kex.

Continue a tratar das partes aborrecidas. Uma troca de chaves pós-quântica não resolve uma palavra-passe fácil de adivinhar nem uma chave privada copiada para um portátil que seja roubado mais tarde. São esses fatores que efetivamente comprometem servidores, e o hardening SSH padrão num VPS continua a ser responsável por quase toda a proteção. Se as etapas de negociação aqui descritas não lhe eram familiares, o que o SSH faz quando estabelece uma ligação explica as fases que esta página pressupõe que conhece.

FAQ

A minha ligação SSH já é pós-quântica?

Execute ssh -v yourserver 2>&1 | grep 'kex: algorithm' e leia o nome apresentado. mlkem768x25519-sha256 e sntrup761x25519-sha512@openssh.com são trocas híbridas pós-quânticas. curve25519-sha256, ecdh-sha2-nistp256 e qualquer nome diffie-hellman-group são clássicos. Ambos os lados precisam de uma versão que ofereça um nome pós-quântico, porque a negociação escolhe a primeira opção do cliente que o servidor também suporta. Portanto, a máquina mais antiga define o limite.

Qual versão do OpenSSH tornou a troca de chaves pós-quântica a predefinição?

O OpenSSH 9.0, lançado em 2022-04-08, tornou sntrup761x25519-sha512@openssh.com a troca de chaves predefinida. O OpenSSH 9.9, lançado em 2024-09-19, adicionou mlkem768x25519-sha256, e o OpenSSH 10.0, lançado em 2025-04-09, tornou essa opção a predefinição. O OpenSSH 10.1, lançado em 2025-10-06, começou a emitir um aviso quando uma ligação não negoceia nenhuma das duas opções. Verifique o comportamento da sua própria compilação com ssh -Q kex e ssh -G <host>, porque a sua versão do Ubuntu determina quais destas opções estão disponíveis.

Devo gerar uma chave SSH pós-quântica?

Não, porque o OpenSSH não tem esse tipo de chave. Até agora, o trabalho pós-quântico abrange a troca de chaves, que não precisa de ficheiros de chaves nem de configuração da sua parte. As chaves do host e as chaves de autenticação continuam a usar assinaturas clássicas, como Ed25519 e RSA. O projeto upstream indicou que as assinaturas pós-quânticas serão incluídas numa versão futura. Continue a usar uma chave Ed25519 e proteja o local onde ela está armazenada.

Por que motivo o ssh avisa que a minha ligação não é pós-quântica?

O OpenSSH 10.1 e versões posteriores apresentam ** WARNING: connection is not using a post-quantum key exchange algorithm. quando a troca negociada não tem uma componente pós-quântica. O aviso diz respeito ao servidor, não ao cliente, porque o seu cliente ofereceu um nome pós-quântico e o servidor não aceitou nenhum deles. Atualize o OpenSSH do servidor ou confirme que ninguém definiu uma linha KexAlgorithms no respetivo sshd_config que exclua os nomes modernos. Definir WarnWeakCrypto no oculta a mensagem, mas mantém a ligação exatamente tão fraca como antes.