Processo de Autenticação

O Processo de Autenticação no SSH é a fase crítica que ocorre imediatamente após o estabelecimento do túnel cifrado (Camada de Transporte). O objetivo técnico desta etapa é provar ao servidor que o cliente possui o direito de acessar a conta solicitada. No SSH-2 (especificado pela RFC 4252), a autenticação é flexível e multi-método, permitindo que uma única sessão exija múltiplas provas de identidade antes de liberar o acesso ao shell.

1. Pré-requisitos: O Túnel Seguro

Antes de qualquer dado de autenticação (como uma senha) ser enviado, o cliente e o servidor já completaram a troca de chaves Diffie-Hellman.

• Confidencialidade: Todas as mensagens de autenticação são enviadas dentro do túnel cifrado simetricamente (AES-256-GCM, ChaCha20-Poly1305).
• Identidade do Servidor: O cliente já validou a Host Key do servidor. O processo de autenticação de usuário só começa se o cliente confiar que o servidor não é um impostor (Trust On First Use — TOFU — ou via known_hosts pré-populado).
• Forward Secrecy: Como o KEX DH efêmero descarta as chaves privadas temporárias após o NEWKEYS, a captura posterior do tráfego cifrado não compromete senhas transmitidas nesta sessão.

Sequência de Estados até Autenticação

1. TCP connect (porta 22)
2. Version exchange (SSH-2.0-OpenSSH_9.6p1)
3. SSH_MSG_KEXINIT (algoritmos)
4. SSH_MSG_KEXDH_INIT/REPLY (Diffie-Hellman)
5. SSH_MSG_NEWKEYS (início da cifragem simétrica)
6. SSH_MSG_SERVICE_REQUEST "ssh-userauth"   <-- INÍCIO da autenticação
7. SSH_MSG_USERAUTH_REQUEST (método)
8. SSH_MSG_USERAUTH_SUCCESS / FAILURE       <-- FIM da autenticação

2. O Protocolo de Autenticação (ssh-userauth)

O processo segue um modelo de requisição e resposta estruturado:

1. Requisição de Serviço: O cliente envia uma mensagem SSH_MSG_SERVICE_REQUEST para o serviço ssh-userauth (RFC 4254 §4).
2. Lista de Métodos: O servidor responde com SSH_MSG_SERVICE_ACCEPT e, na primeira tentativa de autenticação, devolve SSH_MSG_USERAUTH_FAILURE com a lista de métodos aceitos (ex: publickey,password,keyboard-interactive).
3. Tentativa de Autenticação: O cliente escolhe um método e envia uma mensagem SSH_MSG_USERAUTH_REQUEST especificando method name, parâmetros específicos do método e o nome de usuário alvo.

Anatomia da Mensagem USERAUTH_REQUEST

byte      SSH_MSG_USERAUTH_REQUEST (50)
string    user name (ex: "admin")
string    service name ("ssh-connection")
string    method name ("publickey"|"password"|"keyboard-interactive")
...       method-specific fields

3. Métodos Comuns de Autenticação

A. Senha (Password — RFC 4252 §8)

O método mais simples, onde o cliente envia a senha em texto claro dentro do túnel cifrado. O servidor valida a senha contra o banco de dados local (ex: /etc/shadow via PAM).

• Risco: Vulnerável a ataques de força bruta se o servidor estiver exposto à internet sem proteções como Fail2Ban ou rate limiting.
• Diretiva sshd_config: PasswordAuthentication yes|no.

B. Chave Pública (Public Key — RFC 4252 §7)

O método mais seguro. O cliente prova a posse de uma chave privada sem nunca enviá-la.

1. O cliente envia a chave pública e o algoritmo (ssh-ed25519, rsa-sha2-256, ecdsa-sha2-nistp256).
2. O servidor verifica se a chave pública está em ~/.ssh/authorized_keys.
3. Se estiver, o servidor envia um "nonce" (número aleatório) como desafio.
4. O cliente assina o nonce com sua chave privada e devolve a assinatura.
5. O servidor verifica a assinatura com a chave pública — se válida, autenticação confirmada.

• Diretiva sshd_config: PubkeyAuthentication yes.
• Vantagem: Imune a brute force (2²⁵⁶ combinações Ed25519); nada além da assinatura transita pela rede.

C. Interativo por Teclado (Keyboard-Interactive — RFC 4256)

Um método genérico onde o servidor envia prompts de texto ao usuário via SSH_MSG_USERAUTH_INFO_REQUEST. É comumente utilizado para implementar a Autenticação de Dois Fatores (2FA/MFA), como códigos do Google Authenticator ou tokens SMS.

• Diretiva sshd_config: KbdInteractiveAuthentication yes (renomeado de ChallengeResponseAuthentication em OpenSSH 8.2+).
• Cenário Típico: Senha → OTP TOTP → biometria (3 fatores sequenciais).

Comparativo dos Métodos

4. Ordem e Persistência

O servidor SSH pode ser configurado para exigir uma ordem específica ou múltiplos métodos em cascata (RFC 4252 §5.1):

• MFA Obrigatório: O servidor pode ser configurado para aceitar a publickey, mas ainda assim exigir o keyboard-interactive logo em seguida. Diretiva: AuthenticationMethods publickey,keyboard-interactive.
• Tentativas Limitadas: O parâmetro MaxAuthTries no arquivo sshd_config define quantas vezes o cliente pode falhar antes que o servidor encerre a conexão TCP por segurança. Padrão: 6.
• Métodos Opcionais (none probe): Alguns clientes enviam primeiro uma requisição com método "none" apenas para descobrir quais métodos o servidor aceita — probe de capacidades.

Exemplo de Configuração Multi-fator

# /etc/ssh/sshd_config — exigir chave + OTP
PubkeyAuthentication yes
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

# /etc/pam.d/sshd — adicionar TOTP após autenticação de chave
auth required pam_google_authenticator.so

5. Finalização do Processo

• Sucesso: O servidor envia uma mensagem SSH_MSG_USERAUTH_SUCCESS. O cliente então solicita a abertura de um canal de sessão (SSH_MSG_CHANNEL_OPEN "session", RFC 4254) e o shell interativo começa.
• Falha: O servidor envia SSH_MSG_USERAUTH_FAILURE. Ele pode listar quais métodos ainda restam para o cliente tentar. Se o cliente esgotar as tentativas (MaxAuthTries atingido), ocorre o "Permission denied (publickey,password)" e a conexão TCP é encerrada.
• Disconnect por Falhas: Após MaxAuthTries, o servidor envia SSH_MSG_DISCONNECT com reason code SSH_DISCONNECT_BY_APPLICATION e fecha o socket TCP.

Tabela de Reason Codes Comuns (RFC 4250 §4.2.2)

6. Segurança: O Papel do PAM (Pluggable Authentication Modules)

No Linux, o processo de autenticação do SSH frequentemente delega a decisão final para o PAM. Isso permite que o SSH se integre a diretórios centrais como LDAP (via pam_ldap), Active Directory (via sssd/pbis), Kerberos 5 (via pam_krb5) ou utilize módulos complexos de conformidade de senha (pam_cracklib, pam_pwquality) sem precisar alterar o código-fonte do servidor SSH.

Auditoria do Processo de Autenticação

# Log em tempo real de tentativas
sudo journalctl -u ssh -f

# Filtrar apenas autenticações bem-sucedidas
sudo grep 'Accepted' /var/log/auth.log

# Contar tentativas falhas por IP (últimas 24h)
sudo journalctl -u ssh --since "24h ago" | \
  grep -E 'Failed password|Invalid user' | \
  awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -10

# Verificar sessões atualmente ativas
who
ss -tnp | grep ':22' | grep ESTAB

# Rastrear comandos executados por usuário em sessão SSH (via auditd)
sudo auditctl -a always,exit -F arch=b64 -F euid=0 -S execve -k ssh_cmd
sudo ausearch -k ssh_cmd --start today

7. Resumo Técnico

8. Conclusão

O processo de autenticação SSH é a fronteira final entre o acesso legítimo e a invasão. Sua arquitetura multi-método — combinável em cascata via AuthenticationMethods — permite implementar políticas que vão desde o simples "chave pública OU senha" até "chave pública E TOTP E biometria", atendendo requisitos de compliance como PCI-DSS 4.0 (Requirement 8.4) e ISO 27001:2022 (A.5.17). A integração com PAM desacopla a decisão de autenticação do código do sshd, permitindo que organizações consolidem identidade via LDAP/AD/Kerberos sem recompilar o daemon. A maturidade de um ambiente SSH mede-se pelo rigor em logs, monitoramento (Fail2Ban/CrowdSec + SIEM) e adoção progressiva de FIDO2 (ed25519-sk) como substituto definitivo de senhas.