Criptografia Híbrida no SSH

O SSH utiliza um sistema de Criptografia Híbrida, que combina o melhor dos dois mundos: a segurança da criptografia assimétrica e a velocidade da criptografia simétrica. Esse é o modelo adotado por praticamente todos os protocolos seguros modernos (TLS, IPsec, SSH, Signal).

1. Por que usar Criptografia Híbrida?

1.1 Trade-off entre os dois modelos

• Criptografia Assimétrica (Chave Pública/Privada): É segura para trocar chaves sem um segredo prévio, mas é computacionalmente cara e lenta para grandes volumes de dados.
  • Exemplo: RSA-2048 gasta ~1 ms por operação; cifra simétrica equivalente (AES-128) gasta < 1 µs por bloco — diferença de 1000×.
• Criptografia Simétrica (Chave Única): É extremamente rápida e eficiente para grandes transmissões, mas exige que ambos os lados já possuam o mesmo segredo (chave) de antemão.
  • Como entregar a chave simétrica pela rede sem que seja interceptada? Esse é o problema que a assimétrica resolve.

O SSH resolve esse dilema usando a assimétrica apenas para o Handshake inicial e a simétrica para o Túnel de Dados.

2. O Processo de Criptografia no SSH

2.1 Visão Geral das Fases

[Cliente]                                    [Servidor]
   │                                            │
   │ 1. Version exchange (SSH-2.0-OpenSSH_9.0)   │
   │ ─────────────────────────────────────────> │
   │ 2. KEXINIT (algoritmos suportados)         │
   │ <────────────────────────────────────────> │
   │ 3. Diffie-Hellman / ECDH (KEX)             │
   │ <────────────────────────────────────────> │
   │ 4. Geração da Session Key (simétrica)      │
   │ 5. Autenticação do servidor (chave pública) │
   │ 6. Autenticação do cliente (senha/pubkey)  │
   │ <────────────────────────────────────────> │
   │ 7. Túnel simétrico de dados (AES/ChaCha20) │
   │ <────────────────────────────────────────> │

Fase 1: Handshake Assimétrico (KEX)

Durante a troca de chaves (KEX — Key Exchange), o cliente e o servidor usam algoritmos assimétricos para autenticar o servidor e realizar o Diffie-Hellman.

• O servidor apresenta sua chave pública de host (em /etc/ssh/ssh_host_ed25519_key.pub).
• O cliente verifica se já confia nessa chave (em ~/.ssh/known_hosts). Se for primeira conexão, exibe fingerprint para aceitação manual.
• É executado o Diffie-Hellman (ou ECDH com Curve25519): ambas as partes geram valores efêmeros e trocam apenas o resultado intermediário, sem nunca transmitir o segredo final pela rede.
• O resultado do KEX é a Chave de Sessão simétrica idêntica em ambos os lados.

Fase 2: Túnel de Dados Simétrico

Uma vez estabelecida a chave de sessão, toda a comunicação subsequente (inclusive o envio da senha ou o tráfego do terminal) é criptografada usando algoritmos simétricos rápidos como AES (Advanced Encryption Standard) ou ChaCha20.

• Cada pacote é cifrado e acompanhado de um MAC (Message Authentication Code) para garantir integridade.
• Em modos AEAD (AES-GCM, ChaCha20-Poly1305), cifra e MAC são combinados num único passo seguro.

3. Perfect Forward Secrecy (PFS)

Como o SSH usa Diffie-Hellman efêmero (chaves geradas a cada sessão e descartadas após o uso), mesmo que a chave privada do servidor seja comprometida no futuro, sessões antigas gravadas por atacantes não podem ser decifradas. Esse princípio é chamado Perfect Forward Secrecy.

4. Algoritmos por Categoria

5. Algoritmos Recomendados Atualmente

Para um ambiente seguro, o administrador deve desabilitar cifras fracas e priorizar as modernas:

• Recomendados:

  • aes256-gcm@openssh.com (Simétrico — muito seguro e rápido com aceleração por hardware AES-NI).
  • chacha20-poly1305@openssh.com (Simétrico — ideal para dispositivos móveis ou CPUs sem aceleração AES).
  • curve25519-sha256 (Troca de Chaves — o padrão-ouro atual).
  • ssh-ed25519 (Chave de host — chaves pequenas, rápidas e resistentes a ataques quânticos moderados).

• Legados / Vulneráveis:

  • arcfour, blowfish, 3des (cifras fracas ou modos CBC suscetíveis a ataques).
  • diffie-hellman-group1-sha1 (DH pequeno, SHA-1 quebrado).
  • ssh-dss (limite de 1024 bits).

6. Hardening Prático no /etc/ssh/sshd_config

# Apenas cifras modernas
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr
MACs   hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com
KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256

# Apenas chaves de host modernas
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Desabilitar login por senha (forçar pubkey)
PasswordAuthentication no
PubkeyAuthentication yes

6.1 Verificar Cifras Suportadas

# Listar cifras, MACs e KEX suportados pelo cliente
ssh -Q cipher
ssh -Q mac
ssh -Q kex

# Verificar qual cifra foi efetivamente usada
ssh -v user@host 2>&1 | grep "cipher:"

7. Por que Híbrida é Necessária

Sem o modelo híbrido, teríamos dois cenários impossíveis:

1. Apenas simétrica: como entregar a chave para o servidor sem que ela seja interceptada? Seria necessário um canal seguro prévio — o que é inviável na Internet aberta.
2. Apenas assimétrica: cifrar todo o tráfego com RSA tornaria o SSH inviável para transferências maiores que alguns KB. Uma transferência SFTP de 1 GB poderia levar horas a mais, apenas por overhead criptográfico.

O híbrida resolve os dois: usa o lento (assimétrica) uma única vez para estabelecer um segredo compartilhado, e o rápido (simétrica) para tudo o mais.

8. Resumo Técnico

9. Conclusão

A criptografia híbrida é o que permite que o SSH seja usado para transferir arquivos de gigabytes (SFTP) com alto desempenho, enquanto mantém a segurança de nunca transmitir o segredo pela rede. Esse modelo — combinando KEX assimétrico com túnel simétrico — tornou-se o padrão para qualquer protocolo seguro de rede. Compreender quais algoritmos são modernos, quais devem ser desabilitados e como configurar hardening no sshd_config é essencial para operar servidores SSH em conformidade com as práticas de segurança atuais.