Por que Seu SSH Esta Gritando Sobre Computadores Quanticos (E Como Corrigir)

Voce faz SSH no seu servidor e ve isso:

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

Assustador. Vamos decompor isso.

A Ameaca: Armazenar Agora, Descriptografar Depois

A criptografia SSH de hoje e matematicamente forte; quebra-la levaria um computador classico milhoes de anos.

Mas computadores quanticos jogam com regras diferentes. Um computador quantico suficientemente poderoso executando o algoritmo de Shor pode quebrar a matematica que protege a maioria da criptografia de chave publica de hoje em horas, nao milhoes de anos.

Aqui esta a parte inquietante: computadores quanticos poderosos o suficiente para fazer isso ainda nao existem. Entao por que se preocupar agora?

Porque adversarios, especialmente estados-nacao, ja estao gravando trafego criptografado hoje com o plano de descriptografa-lo depois, quando o hardware quantico amadurecer. Este e o ataque "store now, decrypt later" (SNDL). Se voce esta enviando qualquer coisa sensivel por SSH que precisa permanecer secreta pelos proximos 10-20 anos, voce ja esta em risco.

Isso nao e ficcao cientifica. A NSA, CISA e NIST emitiram orientacoes sobre a migracao para criptografia pos-quantica agora.

O que e Key Exchange, Afinal?

Antes que o SSH possa criptografar sua sessao, ambos os lados precisam concordar em um segredo compartilhado, uma chave temporaria usada para criptografar todo o resto. Esta negociacao e chamada de key exchange (Kex).

Pense nisso assim: duas pessoas querem concordar em uma cor secreta sem que ninguem observando consiga descobri-la. Key exchange e a versao criptografica desse truque (pesquise Diffie-Hellman se quiser os detalhes, e uma ideia linda).

O problema: a matematica por tras da key exchange classica (Diffie-Hellman, curvas elipticas) e vulneravel a computadores quanticos.

Key Exchange Classica vs Pos-Quantica

Aqui esta um rapido tour do que o SSH suporta e onde cada algoritmo se encontra:

Classica (vulneravel a computadores quanticos)

Todos os acima sao quebrados por um computador quantico rodando o algoritmo de Shor.

Pos-Quantica (segura contra computadores quanticos)

Ambos sao algoritmos hibridos -- eles sobrepoem um algoritmo pos-quantico em cima de um classico. Isso significa:

• Se o algoritmo PQ tiver uma falha → X25519 ainda protege voce (seguranca classica).
• Se um computador quantico atacar → a camada PQ ainda protege voce.

Voce tem o melhor dos dois mundos. Hibridos sao a abordagem recomendada durante este periodo de transicao.

mlkem768x25519-sha256 e o preferido a longo prazo. ML-KEM (anteriormente Kyber) foi selecionado pelo NIST como o mecanismo padrao de encapsulamento de chave pos-quantica em 2024. Esta no OpenSSH 9.9+.

sntrup761x25519-sha512@openssh.com usa NTRU Prime, um candidato PQ mais antigo. Ainda e solido, disponivel no OpenSSH mais antigo. Use-o se voce estiver no 8.5-9.8.

Por que o Aviso Aparece

OpenSSH 8.5+ habilita PQ por padrao em sua lista integrada de KexAlgorithms. Mas se seu sshd_config tem uma linha KexAlgorithms fixa no codigo, ela substitui os padroes e, quem escreveu essa linha pode nao ter incluido algoritmos PQ.

E exatamente isso que aciona o aviso: o servidor esta anunciando apenas algoritmos classicos, entao o cliente (que prefere PQ) faz fallback para o classico.

Verifique seu servidor:
grep -i kexalgorithms /etc/ssh/sshd_config

Se voce ver uma linha com apenas algoritmos classicos (como curve25519-sha256,diffie-hellman-group-exchange-sha256), esse e o culpado.

A Correcao

Passo 1: Edite /etc/ssh/sshd_config

Adicione o algoritmo PQ na frente da lista. OpenSSH negocia em ordem; a primeira correspondencia vence.

Se voce estiver no OpenSSH 9.9+ (verifique com ssh -V):

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Se voce estiver no OpenSSH 8.5-9.8 (como o 9.6p1 incluido no Ubuntu 24.04):

KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Mantenha os algoritmos classicos como fallbacks. Alguns clientes (sistemas embarcados, hardware antigo) ainda nao suportam PQ e precisam deles para conectar.

Para ver todos os algoritmos que sua versao do OpenSSH realmente suporta: ssh -Q kex

Passo 2: Valide e Reinicie

Sempre valide antes de reiniciar -- um erro de digitacao no sshd_config pode te deixar trancado para fora: sudo sshd -t

Se nao houver erros: sudo systemctl restart sshd

Passo 3: Verifique se Funcionou

De uma maquina cliente, conecte com saida verbose e filtre pelo kex negociado: ssh -v user@yourserver 2>&1 | grep "kex_"

Procure por algo como: debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com ou do lado do servidor, verifique uma conexao ativa: sudo ss -tnp | grep :22

E o Lado do Cliente?

A mesma correcao se aplica a configuracao do seu cliente SSH (~/.ssh/config ou /etc/ssh/ssh_config). Se seu cliente tem uma linha fixa de KexAlgorithms sem PQ, ele fara fallback para o classico mesmo ao conectar a um servidor com capacidade PQ.

Para suprimir o aviso no lado do cliente enquanto voce trabalha na correcao dos servidores:

# ~/.ssh/config
Host *
    KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,diffie-hellman-group-exchange-sha256

Mas a verdadeira correcao e atualizar ambos os lados.

TL;DR

A era quantica ainda nao chegou, mas a janela para se preparar e agora. Atualizar KexAlgorithms leva dois minutos e e uma das vitorias mais faceis no hardening moderno de servidores.

Ubuntu 24.04 vem com OpenSSH 9.6p1, que suporta sntrup761x25519-sha512@openssh.com nativamente. OpenSSH 9.9+ (disponivel via PPA ou distros mais recentes) adiciona o padronizado pelo NIST mlkem768x25519-sha256.