Identificação Mútua (Sessão SSH)

1. Definição e Importância

A Identificação Mútua é o pilar de confiança que sustenta a segurança do protocolo SSH. Diferente de conexões web simples (HTTP), onde muitas vezes apenas o servidor prova sua identidade (via SSL/TLS), o SSH exige que ambas as partes se identifiquem e provem sua legitimidade antes que qualquer dado sensível ou shell de comando seja liberado. Este processo bidirecional impede ataques de Man-in-the-Middle (o servidor falso) e acessos não autorizados (o usuário falso).

Contexto de Padronização

• RFC 4251: Arquitetura geral do SSH.
• RFC 4252: Protocolo de autenticação.
• RFC 4253: Camada de transporte (onde ocorre a identificação do host).
• RFC 4254: Protocolo de conexão.

Comparação com TLS

2. O Conceito de Confiança Bidirecional

A identificação mútua resolve dois medos fundamentais na computação remota:

1. Medo do Cliente: "Este servidor para o qual estou enviando minha senha é realmente o meu servidor de produção ou um clone malicioso tentando roubar meus dados?"

2. Medo do Servidor: "Este usuário que solicita acesso root é realmente o administrador autorizado ou um invasor usando uma identidade forjada?"

A arquitetura do SSH responde a ambos através de um processo de verificação em etapas. Cada etapa usa criptografia assimétrica (chaves pública/privada) para provar posse sem nunca revelar o segredo.

3. Etapa 1: O Servidor se identifica (Host Authentication)

O primeiro passo da identificação mútua ocorre logo após o estabelecimento da conexão TCP. O servidor deve prover sua identidade ao cliente.

• A Chave do Host (Host Key): O servidor apresenta sua chave pública assimétrica.
• Assinatura Digital: O servidor assina um pedaço de dado da negociação de chaves com sua Chave Privada de Host. O cliente usa a chave pública para verificar a assinatura. Se a matemática bater, o servidor é autêntico.
• Conhecimento Prévio: O cliente consulta o arquivo ~/.ssh/known_hosts. Se a chave apresentada for diferente da registrada anteriormente, o SSH emite um alerta crítico de segurança, interrompendo a identificação.

TOFU (Trust On First Use)

Na primeira conexão, o cliente ainda não tem a chave do host em known_hosts. Ele pergunta ao usuário se deseja aceitar a fingerprint. A partir desse momento, qualquer mudança na chave será detectada como ataque potencial.

Tipos de Chave de Host Suportados

4. Etapa 2: O Usuário se identifica (User Authentication)

Uma vez que o cliente confia no servidor, o túnel seguro é estabelecido, e chega a vez do usuário se identificar. O SSH suporta múltiplos métodos para isso:

• Chave Pública (Recomendado): O cliente prova a posse de uma chave privada assinando um "desafio" enviado pelo servidor. O servidor verifica contra a chave pública em authorized_keys.
• Senha: O usuário envia uma string secreta. Como o túnel já está cifrado (graças à Etapa 1), a senha viaja protegida.
• Keyboard-Interactive: O servidor envia perguntas (como tokens de MFA/2FA) que o usuário deve responder.
• GSSAPI/Kerberos: Para ambientes corporativos com Active Directory ou FreeIPA.
• Certificados SSH (RFC 6187): Em vez de chaves individuais, o usuário apresenta um certificado assinado por uma CA interna (semelhante ao X.509 do TLS).

Métodos Suportados pelo OpenSSH

# /etc/ssh/sshd_config
PubkeyAuthentication yes          # Chave pública
PasswordAuthentication no         # Senha (desabilitado em ambientes hardening)
KbdInteractiveAuthentication no   # Keyboard-interactive
GSSAPIAuthentication yes          # Kerberos
AuthenticationMethods publickey,keyboard-interactive  # MFA obrigatório

5. A Prova de Posse sem Troca de Segredos

Um detalhe técnico crucial na identificação mútua via chaves é que nenhuma chave privada jamais viaja pela rede.

• A identificação é feita através de provas matemáticas de posse.
• O servidor envia um dado aleatório (nonce); o cliente o assina com a chave privada; o servidor verifica com a chave pública.
• Se o atacante interceptar a comunicação, ele verá apenas a assinatura, que é inútil para acessar outras sessões ou descobrir a chave original.

Algoritmo de Assinatura Típico

1. Servidor gera nonce aleatório de 256 bits
2. Servidor envia nonce cifrado com chave de sessão
3. Cliente decifra, assina com sua chave privada
   assinatura = Ed25519_Sign(chave_privada, nonce || session_id)
4. Cliente envia assinatura + chave pública identificadora
5. Servidor busca authorized_keys, verifica assinatura
   Ed25519_Verify(chave_publica, nonce || session_id, assinatura)
6. Se válido → usuário autenticado

6. Identificação Mútua e Agentes de Autenticação

Para facilitar a identificação mútua em ambientes complexos (como saltar de um servidor para outro), o SSH utiliza o SSH Agent Forwarding.

• O cliente identifica-se no primeiro servidor.
• Ao tentar acessar um segundo servidor a partir do primeiro, o "agente" no computador local do usuário provê a identificação necessária sem que a chave privada precise ser copiada para o servidor intermediário.
• Isso mantém a integridade da identificação mútua mesmo em múltiplos saltos (hops).

Risco do Agent Forwarding

Apesar de prático, o agent forwarding expõe o usuário a um risco: se o servidor intermediário for comprometido, um atacante root pode usar o socket SSH_AGENT para assinar desafios enquanto a sessão estiver aberta. Em ambientes críticos, prefere-se ProxyJump (ssh -J) ao Agent Forwarding.

7. Consequências da Falha de Identificação

Se qualquer um dos lados falhar em se identificar:

• Falha do Servidor: O cliente encerra a conexão com um erro de "Host Key Verification Failed", protegendo o usuário de entregar credenciais a um impostor.
• Falha do Usuário: O servidor encerra a conexão com "Permission Denied", protegendo o sistema de invasões.

A sessão só é considerada "estabelecida" quando este aperto de mão duplo e verificado é concluído com sucesso.

Mensagem Típica de Falha de Host Key

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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)!

8. Hardening da Identificação Mútua

known_hosts Estrito

# Configuração rígida em ~/.ssh/config ou /etc/ssh/ssh_config
StrictHostKeyChecking yes
HashKnownHosts yes
VisualHostKey yes

• StrictHostKeyChecking yes — Rejeita silenciosamente hosts desconhecidos.
• HashKnownHosts yes — Hash dos hostnames no arquivo para não vazar inventário.
• VisualHostKey yes — Exibe ASCII art da fingerprint para inspeção visual.

Audit Log

# Ver tentativas de autenticação
journalctl -u ssh -n 100 | grep -E "Accepted|Failed"

# Verificar chave do host
ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

9. Resumo Técnico

10. Conclusão

A identificação mútua do SSH é um dos designs mais elegantes de segurança de rede: ela resolve simultaneamente dois problemas ortogonais (cliente que não confia no servidor, servidor que não confia no cliente) usando o mesmo primitivo criptográfico (assinatura digital assimétrica). Sempre que você digita ssh user@host, cerca de 4 a 8 mensagens são trocadas apenas para que ambos os lados provem quem são — uma troca invisível que garante que cada bit subsequente trafegue apenas entre as partes corretas.