Confirmação pelo Servidor

1. Definição e Contexto

No protocolo SSH, a Confirmação pelo Servidor é o estágio final e decisivo do processo de troca de chaves (Key Exchange — KEX). Após cliente e servidor realizarem os cálculos matemáticos do algoritmo Diffie-Hellman (ou ECDH), o servidor deve enviar uma prova inequívoca de que possui a identidade correta e de que o segredo compartilhado foi estabelecido com sucesso. Esta etapa encerra a fase de negociação em texto claro e "tranca" o túnel criptográfico.

Características do Estágio

• Mensagem chave: SSH_MSG_KEXDH_REPLY (RFC 4253, seção 8).
• Função: Provar identidade do servidor e integridade da negociação.
• Resultado: Transição para SSH_MSG_NEWKEYS — ativação da cifra simétrica.
• RFCs de referência: RFC 4251 (Architecture), RFC 4253 (Transport), RFC 5656 (ECDH), RFC 8731 (Curve25519 KEX).

2. O Pacote de Confirmação (SSH_MSG_KEXDH_REPLY)

A confirmação ocorre através do envio de um pacote específico. Este pacote não contém a chave de sessão em si (que nunca é enviada), mas sim três elementos cruciais:

Cálculo do Hash de Troca (H)

O hash H é calculado sobre todos os elementos da negociação (RFC 4253 seção 8):

H = HASH(V_C || V_S || I_C || I_S || K_S || e || f || K)

Onde:
- V_C, V_S: strings de identificação SSH do cliente e servidor.
- I_C, I_S: pacotes de negociação de algoritmos (kex init).
- K_S: chave pública de host do servidor.
- e, f: valores públicos DH do cliente e servidor.
- K: segredo compartilhado calculado (não transmitido).
- HASH: algoritmo negociado (SHA-256, SHA-512).

3. Verificação de Identidade pelo Cliente

Ao receber a confirmação, o cliente realiza uma verificação de segurança em duas etapas antes de aceitar o servidor:

Etapa 1: Validação Matemática

O cliente usa a chave pública do servidor para verificar a assinatura digital H. Se a assinatura for válida, isso prova que:

1. O servidor possui a chave privada correspondente (prova de identidade).
2. Os dados da negociação não foram alterados por um terceiro (integridade).

Etapa 2: Consulta ao known_hosts

O cliente compara a chave pública recebida com as chaves armazenadas em ~/.ssh/known_hosts:

Exemplo de Aviso de Mudança de Chave

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!

4. A Mensagem NEWKEYS

Uma vez que a identidade do servidor é confirmada e os cálculos do segredo compartilhado (K) batem, ambos os lados enviam a mensagem técnica SSH_MSG_NEWKEYS (RFC 4253 seção 7.3).

Sinalização de Mudança

Esta mensagem avisa à contraparte: "A partir do próximo pacote, tudo o que eu enviar será cifrado com a nova chave de sessão que acabamos de confirmar".

Ativação do Motor de Cifragem

O estado da conexão muda de "negociação" para "cifrado".

5. Algoritmos KEX Comuns

A escolha do algoritmo KEX define a robustez da confirmação:

Curva25519 (Recomendação Moderna)

Definida na RFC 8731 (2020), Curve25519 oferece:
- Chaves de 256 bits (alta entropia com baixo overhead).
- Imunidade a ataques de canais laterais (não depende de RNG de qualidade criptográfica para segurança — usa clamping).
- Performance superior a ECDH NIST em software.
- Adotada como padrão no OpenSSH desde a versão 7.4 (2017).

6. Garantia de Sigilo Direto (Forward Secrecy)

Um aspecto técnico vital da confirmação pelo servidor é que ela valida um segredo efêmero:

Propriedades

• O servidor confirma uma chave que só existirá para esta sessão específica.
• O segredo K é calculado matematicamente a partir dos valores e (cliente) e f (servidor), ambos efêmeros.
• Mesmo que um atacante obtenha a chave privada do servidor no futuro, a confirmação feita nesta sessão permanece segura, pois a chave de sessão assinada não pode ser derivada apenas da chave de host.

Comparação: Forward Secrecy vs Sem FS

A captura de tráfego hoje não pode ser decifrada amanhã, mesmo com acesso à chave privada de host. Esta é a propriedade mais importante da criptografia moderna em SSH/TLS.

7. Transição para a Autenticação de Usuário

A confirmação pelo servidor marca o fim da Camada de Transporte (RFC 4253). Com o túnel agora "confirmado" e seguro, o servidor fica em estado de prontidão para receber a próxima fase: o Processo de Autenticação de Usuário (RFC 4252).

Estado da Conexão Após Confirmação

1. Transporte: cifrado e integro (AES + HMAC ou AEAD).
2. Compressão: opcionalmente ativa.
3. Identidade do servidor: comprovada.
4. Próxima etapa: SSH_MSG_SERVICE_REQUEST para ssh-userauth.

A partir deste ponto, qualquer tentativa de espionagem mostrará apenas dados cifrados. O servidor provou quem é; agora é a vez do cliente provar quem é o usuário que deseja entrar.

8. Auditoria e Diagnóstico

# Ver algoritmos KEX oferecidos por um servidor
ssh -Q kex

# Forçar um KEX específico
ssh -o KexAlgorithms=curve25519-sha256@libssh.org usuario@host

# Depurar handshake completo (mostra confirmação)
ssh -vvv usuario@host 2>&1 | grep -i kex

# Verificar chave pública do servidor (fingerprint)
ssh-keyscan -t ed25519 host.exemplo.com | ssh-keygen -l -f -

9. Resumo Técnico

10. Conclusão

A Confirmação pelo Servidor é o ponto de virada do handshake SSH: antes dela, tudo é texto claro; após ela, tudo é cifrado. A assinatura do hash de troca com a chave privada de host prova simultaneamente a identidade do servidor e a integridade de toda a negociação. Combinada com algoritmos modernos como Curve25519 (RFC 8731), oferece forward secrecy, garantindo que tráfego capturado hoje permaneça indecifrável mesmo se a chave privada for comprometida amanhã. Para administradores, entender este estágio é essencial para diagnosticar falhas de handshake, validar trocas de chaves de host e configurar corretamente as opções KexAlgorithms no sshd_config para eliminar algoritmos legados.