OpenSSH 10: Fim do DSA e Chaves Pós-Quânticas por Omissão

O OpenSSH 10.0, lançado a 9 de Abril de 2025, marcou duas viragens na ferramenta de acesso remoto mais usada em servidores Linux: removeu de vez o algoritmo de assinatura DSA — fechando a depreciação iniciada em 2015 — e passou a negociar chaves com o algoritmo híbrido pós-quântico mlkem768x25519-sha256 por omissão. A série continuou com o 10.4 (sftp/scp e GSSAPI) e o 10.5 (correcção ao ssh-agent), a 11 de Agosto de 2026. Para sysadmins de PME, o trabalho prático é duplo: inventariar chaves e clientes DSA legacy antes de actualizar servidores, e perceber o que muda (e o que não muda) com a criptografia pós-quântica.

O Que Mudou no OpenSSH 10.0

A nota de release oficial do 10.0 é clara nas alterações incompatíveis: “this release removes support for the weak DSA signature algorithm, completing the deprecation process that began in 2015 (when DSA was disabled by default)”. O DSA estava desactivado por omissão desde 2015, com avisos repetidos nos últimos 12 meses — a remoção completa era o passo final anunciado.

O mesmo release trouxe a segunda mudança estrutural: o sshd deixou de ter o código de autenticação de utilizador no binário por ligação (sshd-session) e passou a separá-lo num novo binário sshd-auth. E, no lado das funcionalidades novas, o acordo de chaves passou a usar por omissão o algoritmo híbrido mlkem768x25519-sha256 (release notes do OpenSSH).

Porquê o DSA Teve de Morrer

O DSA (Digital Signature Algorithm) para SSH tem limitações estruturais: chaves limitadas a 1024 bits nas variantes clássicas, sensibilidade a má geração de números aleatórios e sem suporte para os padrões modernos de assinatura. O OpenSSH desligou-o por omissão em 2015, manteve-o opcional durante uma década com avisos, e o 10.0 removeu-o do código.

Quem ainda tem chaves DSA (ficheiros id_dsa) ou servidores que só negociam ssh-dss vai ver as ligações falharem após actualizar o cliente ou o servidor. O inventário é simples:

# Procurar chaves DSA nos directórios de utilizadores
find /home -name "id_dsa*" -o -name "*.dsa" 2>/dev/null
# No cliente, testar uma ligação forçando DSA (vai falhar contra um servidor 10.x)
ssh -i ~/.ssh/id_dsa -o HostKeyAlgorithms=+ssh-dss utilizador@servidor

A correcção é regenerar as chaves em Ed25519 (recomendado) ou RSA de 3072+ bits e instalar a chave pública nova nos servidores antes de actualizar.

Pós-Quântico por Omissão: mlkem768x25519-sha256

A partir do 10.0, o acordo de chaves usa por omissão o mlkem768x25519-sha256 — um algoritmo híbrido que combina o ML-KEM-768 (o padrão pós-quântico do NIST, antes chamado Kyber) com o clássico curve25519. A nota de release descreve o racional: é considerado seguro contra ataques por computadores quânticos, é garantido que não é mais fraco que o curve25519-sha256 popular, está normalizado pelo NIST e é consideravelmente mais rápido que o default anterior.

Dois pontos práticos para PMEs:

• Não é preciso agir. A transição é automática entre clientes e servidores OpenSSH recentes — a negociação faz fallback para os algoritmos clássicos quando o par remoto não suporta o híbrido.
• Não resolve tudo. O “harvest now, decrypt later” aplica-se sobretudo a tráfego de longa duração e à confidencialidade. A assinatura de chaves host e de utilizador continua nos algoritmos clássicos (Ed25519/RSA). O OpenSSH 10.5 acrescentou outros refinamentos pós-quânticos, mas a troca de chaves de sessão é a peça principal.

A Série 10.x: 10.1 a 10.5

A linha do tempo dos releases recentes, segundo as notas oficiais:

O 10.5 corrigiu uma interacção entre o bloqueio do agente e a extensão [email protected]: com o agente bloqueado, pedidos que deviam ficar limitados ao uso local podiam ser executados remotamente, incluindo adicionar tokens PKCS#11 (reportado por sn0x-sharma). O 10.4, um mês antes, trouxe as correcções de sftp/scp em transferências entre destinos remotos, o truncamento de argumentos no internal-sftp e um DoS pré-auth quando a autenticação GSSAPI está activa. Quem usa agent forwarding entre máquinas deve actualizar o ssh-agent.

O 10.5 merece nota adicional pelo lado do projecto: as notas reconhecem o volume de relatórios de segurança gerados com ajuda de modelos de IA e sublinham o valor dos relatórios acompanhados de análise, casos de teste e correcções propostas.

Auditoria a Chaves e Configurações Legacy

Antes de actualizar servidores para OpenSSH 10.x, o inventário mínimo:

# Tipos de chaves aceites pelo servidor actual
sshd -T | grep -iE "hostkeyalgorithms|pubkeyaccepted"

# Algoritmos negociados em uso (log de ligações recentes)
journalctl -u ssh -o cat | grep -oE "kex: [[email protected]]+" | sort | uniq -c

# Chaves de utilizadores por tipo (Ed25519/RSA/DSA/ECDSA)
for k in /home/*/.ssh/*.pub /root/.ssh/*.pub; do
  [ -f "$k" ] && head -c 20 "$k" | grep -q dsa && echo "DSA legacy: $k"
done

No servidor, definir explicitamente os algoritmos modernos no sshd_config elimina o DSA de vez, mesmo em versões anteriores ao 10.x:

# sshd_config — só algoritmos modernos
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms curve25519-sha256,[email protected]

Quem gere frotas grandes pode auditar remotamente com ssh -Q key no cliente e um varrimento de banners de versão: servidores ainda em OpenSSH 7.x/8.x merecem prioridade de actualização, não só pelo DSA mas por CVEs acumuladas.

Compatibilidade: O Que Pode Partir

• Clientes antigos com chaves DSA deixam de autenticar. Regenerar em Ed25519 e actualizar os authorized_keys antes do upgrade.
• Aparelhos de rede e appliances com SSH embutido (switches, storage, routers) que só falem ssh-dss no host key deixam de ser acessíveis por SSH a partir de clientes novos. Em muitos casos o appliance usa SSH para transferências internas (backups, syslog) — verificar antes.
• Software que compare versões por padrão tipo OpenSSH_1* pode confundir-se com o salto de 9.x para 10.0 — as notas oficiais avisam para este caso em sistemas de monitorização.
• Rigs de CI legados com imagens antigas que geram chaves DSA em tempo de build: actualizar a geração de chaves para Ed25519.

Como Planear a Migração numa PME

1. Inventariar versões de OpenSSH em todos os servidores (banner + sshd -V).
2. Inventariar chaves de utilizadores e de automação por tipo. Listar as DSA.
3. Regenerar chaves DSA em Ed25519 e distribuir as novas públicas (com sobreposição: manter as duas até validar).
4. Actualizar clientes primeiro (estações de administração), depois servidores, um grupo de cada vez.
5. Depois de cada actualização, validar a negociação: ssh -vv mostra o kex acordado — deve aparecer o mlkem768x25519-sha256 entre pares recentes.
6. Actualizar o hardening do sshd_config para os algoritmos modernos e desligar opções legacy.

Erros Comuns

• Actualizar o servidor e descobrir que as chaves de automação eram DSA. O cron job de backup via rsync/SSH falha às 3 da manhã. Inventariar antes.
• Assumir que o pós-quântico por omissão dispensa rotação de chaves. O mlkem768x25519 protege o acordo de chaves de sessão. As chaves de assinatura antigas continuam a ser o elo fraco.
• Desligar o fallback clássico antes de validar o parque. Se um appliance só fala curve25519 clássico, restringir os kex a mlkem puro quebra a ligação. Manter a lista híbrida + clássica.
• Ignorar o ssh-agent em máquina de administração. A correcção do 10.5 ao agent locking só beneficia quem actualiza. Agentes antigos em forwarding remoto mantêm a exposição.

Artigos Relacionados

• Dia 10: SSH no Linux — Chaves, Tunnels e Hardening
• Diagnóstico de Conectividade SSH: Guia Prático para Sysadmins
• Dia 27: Hardening no Linux — CIS, fail2ban, Auditd e Lynis
• Criptografia Pós-Quântica: Migrar para Algoritmos Quantum-Safe em 2026