A Cifragem e Assinatura na Troca de Chaves do SSH (frequentemente chamada de “Cifragem Dupla” em nível conceitual) é o mecanismo que une o sigilo da troca Diffie-Hellman à autenticidade da identidade do servidor. Padronizada na RFC 4253, esta fase do handshake garante que o cliente não apenas gerou um segredo compartilhado (K) com um computador qualquer, mas sim com o servidor real e legítimo. É nesta orquestra técnica que o segredo matemático encontra o certificado de identidade da máquina, blindando a conexão contra ataques de personificação (Impersonation).
1. A Geração do Hash de Troca (Exchange Hash - H)
Antes do servidor responder ao cliente, ambas as pontas devem concordar sobre um resumo (Hash) de tudo o que foi conversado até aquele momento.
- Payload do Hash: O hash H é calculado a partir das strings de versão (V_C, V_S), das mensagens KEXINIT (I_C, I_S), da Chave Pública do Servidor (K_S) e dos valores públicos do Diffie-Hellman (e, f).
- Session ID: O valor do primeiro hash H gerado em uma conexão torna-se o Session ID permanente. Ele é o “identificador digital” único daquela sessão específica.
2. A Assinatura de Host do Servidor
Para provar que o servidor é o dono da Host Key que ele enviou, ele deve assinar o Hash H.
- Operação de Assinatura: O servidor utiliza sua Chave Privada de Host (armazenada em /etc/ssh/ssh_host_*_key) para assinar digitalmente o valor de H.
- Envio ao Cliente: O servidor transmite sua chave pública (K_S), seu valor público do DH (f) e a Assinatura Digital gerada.
- Validação pelo Cliente: O cliente recebe os dados, recalcula o hash H por conta própria e utiliza a chave pública (K_S) para verificar se a assinatura enviada pelo servidor é válida. Se a verificação for bem-sucedida, o servidor provou que possui a chave privada associada e que o canal de KEX é autêntico.
3. Perspectiva de Cyber Security e Prevenção de Ataques
Para o analista de segurança, esta fase é a defesa primária contra ataques de repetição e interceptação.
Proteção contra Replay Attacks
Como o Hash H inclui valores efêmeros gerados aleatoriamente em cada conexão, a assinatura do servidor nunca será igual entre duas sessões.
- Risco: Sem o hash de troca, um atacante poderia capturar uma assinatura antiga do servidor e tentar enviá-la novamente para se passar pela máquina legítima. A inclusão de (e, f) e do Session ID no hash torna esta tática técnica impossível.
Segurança da Host Key
Este estágio ressalta por que a Chave Privada do servidor deve ser mantida com permissões rigorosas (600). Se um atacante obtiver a chave privada, ele poderá assinar qualquer Hash H, permitindo-lhe realizar ataques de Man-in-the-Middle (MitM) perfeitos, onde o cliente validará a assinatura e acreditará estar falando com o servidor real da empresa.
4. Auditoria Técnica e Diagnóstico de Assinatura
Verificar se o servidor está utilizando uma assinatura de host forte exige a depuração do handshake:
# Verificando qual tipo de chave de host $(HostKey)$ foi selecionado e validado $(-vv)$
ssh -vv user@alvo.com 2>&1 | grep "Host key"
# Validando manualmente o fingerprint da assinatura recebida contra o known_hosts
ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
5. Conclusão: O Selo da Autenticidade
A Assinatura do Hash de Troca é o selo de cera digital que garante a integridade do processo SSH. Ela amarra o segredo matemático da sessão à identidade física do servidor. Dominique a lógica da geração do Session ID, entenda a importância de proteger as chaves privadas de host e audite as assinaturas recebidas para garantir que o seu túnel administrativo seja uma construção de confiança absoluta no cenário dinâmico da web globalizada.