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, escolhe por predefinição uma troca de chaves híbrida pós-quântica. Assim, a chave de sessão fica protegida contra um atacante que grave 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 cada ligação SSH: os dois lados acordam um segredo partilhado, e esse segredo cifra tudo o que se segue. A troca de chaves é a parte 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. Isso é 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 informar isso. Aprenda estes comandos e deixará de depender de artigos sobre este tema, incluindo este.

Comece por verificar o que a sua compilação suporta.

ssh -V
ssh -Q kex

ssh -V mostra uma linha de versão que começa por OpenSSH_, seguida do sufixo do pacote Ubuntu e da versão do OpenSSL. ssh -Q kex mostra 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 mesmo 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 relevante: o que esta ligação vai efetivamente propor. As duas listas são diferentes, e é nessa diferença que as orientações antigas causam problemas reais.

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

ssh -G <host> apresenta a configuração efetiva do cliente para esse host, depois de aplicar ~/.ssh/config e /etc/ssh/ssh_config. sshd -T faz o mesmo para o servidor. Cada um apresenta uma única linha kexalgorithms pela ordem de preferência, e o primeiro nome dessa 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 mostra. Isto significa que o binário suporta uma troca de chaves pós-quântica, mas nenhuma ligação chega a solicitá-la.

Leia o algoritmo negociado pela sua ligação

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

Num servidor mais antigo, poderá ver:

debug1: kex: algorithm: curve25519-sha256

Esse nome não tem uma componente pós-quântica. curve25519-sha256 é Diffie-Hellman de curva elíptica por si só, e um computador quântico de grande escala consegue quebrá-lo. Essa é a razão pela qual a predefinição mudou.

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é que ponto da lista é possível avançar. Atualizar o portátil não atualiza uma sessão com um servidor que nunca ouviu falar de ML-KEM.

ssh -v é útil por mais do que esta linha, porque a mesma saída também é onde pode investigar uma falha Permission denied (publickey) quando um início de sessão é recusado diretamente.

Remova grep e ssh -v apresenta o resto da negociação, incluindo a linha abordada na secção seguinte:

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 do projeto 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 manteve-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". Foi nesta versão que a 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 segunda opção. A mesma versão atribuiu ao método anterior o nome registado pela IANA, sntrup761x25519-sha512, pelo que as compilações mais recentes o apresentam com ambas as grafias.
• 10.0, lançada em 2025-04-09, tornou mlkem768x25519-sha256 o padrão para a negociação de chaves.
• 10.1, lançada em 2025-10-06, adicionou um aviso no cliente quando uma ligação negocia uma troca de chaves sem uma componente pós-quântica. O comportamento é controlado pela opção WarnWeakCrypto em ssh_config e fica ativado por padrão.

Abril de 2022 é a data que vale a pena memorizar. Qualquer par de máquinas que execute OpenSSH 9.0 ou mais recente tem realizado uma troca de chaves pós-quântica desde então, sem configuração e sem qualquer indicação para a pessoa que escreve ssh.

Qual versão do Ubuntu o inclui

O Ubuntu fixa uma versão do OpenSSH na altura do lançamento e depois faz backport das correções de segurança sem alterar o número da versão. Por isso, a versão do Ubuntu em execução determina o algoritmo predefinido. Consulte 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:

• O 22.04 LTS inclui 1:8.9p1, anterior à predefinição da versão 9.0; por isso, uma instalação padrão negoceia curve25519-sha256.
• O 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 inclui ML-KEM.
• O 25.10 inclui 1:10.0p1, cuja predefinição é mlkem768x25519-sha256.
• O 26.04 LTS inclui 1:10.2p1, que usa mlkem768x25519-sha256 por predefinição e 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 9.6. A escolha pós-quântica seguinte do cliente que o servidor suporta é sntrup761x25519-sha512@openssh.com, e esse é o nome que ssh -v comunica. A sessão usa troca de chaves pós-quântica, contra um servidor compilado em 2024, sem qualquer configuração manual.

O caso do 22.04 funciona no sentido inverso e mostra exatamente por que motivo ssh -Q kex, por si só, pode induzir em erro. O OpenSSH 8.9 conhece o nome sntrup761x25519-sha512@openssh.com, por isso ssh -Q kex nessa máquina apresenta-o, mas a proposta predefinida exclui-o e a negociação acaba por usar curve25519-sha256. Num cliente OpenSSH 10.1 ou posterior, a ligação indica isso:

** 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-se, 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 híbrido e o que significa coletar agora e descriptografar depois

A ameaça tem uma forma simples. Um atacante que consiga observar o seu tráfego registra os bytes criptografados hoje e os armazena. Ele não consegue lê-los hoje. Mantém esses dados até existir um computador quântico grande o suficiente para quebrar o X25519 e, então, lê o conteúdo. Isso é chamado de coletar agora e descriptografar depois, ou armazenar agora e descriptografar depois. No presente, isso não exige nada sofisticado do atacante. Exige espaço em disco e paciência.

A criptografia tem esse problema, mas as assinaturas não, e essa assimetria determina todo o restante. Um texto cifrado registrado mantém o seu valor enquanto os dados contidos nele permanecerem sensíveis. Uma assinatura só precisa ser impossível de falsificar no momento em que é verificada. Quebrar um algoritmo de assinatura em 2035 permite que alguém se passe por um servidor em 2035. Isso não permite voltar no tempo e falsificar um login de 2026. Por isso, a troca de chaves precisou ser corrigida primeiro, enquanto a parte das assinaturas pode esperar.

Híbrido significa que os dois algoritmos são executados e que os dois resultados alimentam a chave de sessão. Para recuperar o segredo por trás de mlkem768x25519-sha256, um atacante precisa quebrar o ML-KEM 768 e o X25519. A combinação é intencional: o ML-KEM é muito mais recente que o 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 você 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 ficará 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 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 poderia usá-la 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á guardada e quem lhe pode aceder. Por isso, uma gestão sensata das chaves SSH reduz muito mais o seu risco real do que qualquer nome de algoritmo nesta página.

Não há nada que tenha de fazer relativamente a nenhum dos dois casos, porque ainda não existe uma alternativa para a qual possa mudar. O OpenSSH indicou 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 tem 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 é uma base de código diferente, com um calendário diferente. Atualizar o OpenSSH não altera nada nesse caso. Se estiver a usar um certificado autoassinado para um serviço privado no mesmo VPS, a assinatura e a troca de chaves são determinadas pelo OpenSSL e pelo seu servidor Web. Por isso, avalie essa pilha separadamente.

O que um operador sensato faz agora

Mantenha o OpenSSH atualizado e pare por aí. Essa é realmente toda a estratégia para este problema. sudo apt update && sudo apt upgrade mantém o sistema na versão disponibilizada pela sua versão do Ubuntu, e atualizar para uma versão mais recente do Ubuntu é o que instala uma versão mais recente do OpenSSH. Ativar atualizações de segurança automáticas faz com que essas correções sejam instaladas sem depender da sua memória. Compilar o OpenSSH a partir do código-fonte para obter um determinado nome de algoritmo é uma má troca, porque elimina as atualizações de segurança da distribuição precisamente para o serviço mais exposto do sistema. Se ainda assim transferir 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 piora a situação de forma consistente. 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 ampliar. Todos os algoritmos criados desde então ficam excluídos, e um servidor que teria negociado mlkem768x25519-sha256 por si só passa silenciosamente para o que restar da 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 versão, alguém fixou a lista.

Se tiver uma razão concreta para alterar a lista, acrescente itens em vez de a substituir. O OpenSSH interpreta um + inicial como uma operação de adição, um - inicial como uma operação de remoção e um ^ inicial como uma operação que move o item para o início.

KexAlgorithms ^mlkem768x25519-sha256

Teste o ficheiro antes de depender dele. sudo sshd -t analisa a configuração e não apresenta nada quando ela é válida. Uma linha KexAlgorithms que indique um algoritmo não incluído na compilação impede o arranque do sshd. Num sistema remoto, isso significa que não conseguirá voltar a entrar. Por isso, mantenha uma segunda sessão aberta enquanto trabalha. Quando as listas dos dois lados deixam de ter itens 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 única camada. Quando um fornecedor chama um produto de 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 é pós-quântica híbrida, enquanto as assinaturas são clássicas. Qualquer afirmação mais ampla deve ser acompanhada de um nome que possa encontrar na saída de ssh -Q kex.

Continue a tratar das partes menos interessantes. Uma troca de chaves pós-quântica não resolve nada relativamente a uma palavra-passe fácil de adivinhar nem a uma chave privada copiada para um portátil que seja roubado mais tarde. É isso que efetivamente compromete os servidores, e o hardening SSH padrão num VPS continua a ser o fator mais importante. Se as etapas de negociação descritas aqui não lhe eram familiares, o que o SSH faz quando se liga 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 disponibilize um nome pós-quântico, porque a negociação escolhe a primeira opção do cliente que o servidor também suporta. Por isso, 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 negocia nenhuma das duas. 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 chave nem de configuração da sua parte. As chaves de host e as chaves de início de sessão continuam a usar assinaturas clássicas, como Ed25519 e RSA. O projeto upstream informou que as assinaturas pós-quânticas serão disponibilizadas 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 inclui uma componente pós-quântica. O aviso refere-se ao servidor, não ao cliente, porque o cliente ofereceu um nome pós-quântico e o servidor não aceitou nenhum deles. Atualize o OpenSSH do servidor ou verifique se alguém fixou uma linha KexAlgorithms no respetivo sshd_config, excluindo os nomes modernos. Definir WarnWeakCrypto no oculta a mensagem, mas mantém a ligação exatamente tão fraca como antes.