04 - Camada de Autenticação

A Camada de Autenticação do SSH, padronizada na RFC 4252, é o componente responsável por validar a identidade do usuário que solicita acesso ao servidor. Operando exclusivamente após a Camada de Transporte ter estabelecido um túnel seguro e criptografado, esta camada garante que apenas indivíduos autorizados consigam interagir com o sistema operacional de destino. O SSH oferece um ecossistema flexível e extensível de métodos de autenticação, permitindo desde o uso de senhas tradicionais até esquemas de criptografia assimétrica de alta segurança e autenticação multifator (MFA).

1. O Fluxo de Prova de Identidade

Uma transação de autenticação SSH segue um protocolo rígido de mensagens:
1. Requisição de Serviço: O cliente solicita o serviço ssh-userauth.
2. Consulta de Métodos: O servidor informa quais métodos de autenticação ele aceita para aquele usuário específico (ex: publickey,password).
3. Envio de Credenciais: O cliente tenta autenticar-se utilizando um dos métodos suportados.
4. Verificação e Aceite: O servidor valida a credencial (comparando hashes de senhas ou assinaturas de chaves) e responde com SSH_MSG_USERAUTH_SUCCESS ou falha.

Tipos de Mensagens RFC 4252

A fase de autenticação só termina quando o servidor emite SSH_MSG_USERAUTH_SUCCESS. Até esse momento, nenhum canal de execução (session, shell, exec) é aberto.

2. Métodos de Autenticação Suportados

O SSH permite uma hierarquia de segurança baseada no método escolhido pelo administrador.

Autenticação por Chave Pública (publickey)

É o método de referência para segurança industrial. O servidor não armazena a chave privada do usuário, apenas a sua Chave Pública no arquivo authorized_keys.
- Mecânica: O servidor envia um desafio (Challenge) cifrado com a chave pública. Se o usuário possuir a chave privada correspondente, ele consegue assinar o desafio e provar sua identidade sem nunca transmitir nada sensível pela rede.
- Algoritmos Suportados: RSA (2048 a 4096 bits), ECDSA (P-256, P-384, P-521), Ed25519 (preferido modernamente por performance e segurança), e DSA (obsoleto desde OpenSSH 7.0).
- Vantagem: Imune a brute force pela rede, pois a chave privada de 256 bits (Ed25519) jamais transita pelo canal.

Autenticação por Senha (password)

O método mais simples e universalmente compatível, mas o menos seguro. A senha é enviada cifrada pelo túnel já estabelecido, protegendo-a contra sniffing, mas não contra ataques de Força Bruta (Brute Force) localizados.

Keyboard-Interactive (PAM)

Utilizado para integrações complexas. Permite que o servidor faça múltiplas perguntas ao usuário, sendo a base para a implementação de Autenticação Multifator (MFA) com tokens como Google Authenticator ou dispositivos YubiKey. Diferente do método password, o keyboard-interactive suporta prompts dinâmicos definidos por módulos PAM, permitindo desafios OTP (One Time Password) ou biometria server-side.

Host-Based (hostbased)

Equivalente ao .rhosts do histórico rsh, este método autentica o usuário baseado na confiança entre máquinas. Raramente habilitado em ambientes produtivos por estreitar demais a superfície de ataque. Exige configuração nos arquivos /etc/hosts.equiv e shosts.equiv.

GSSAPI (Kerberos)

Em ambientes corporativos com Active Directory ou FreeIPA, o SSH pode delegar a autenticação ao Kerberos via GSSAPI (RFC 4462). Permite single sign-on (SSO) sem necessidade de distribuir chaves públicas manualmente.

3. Perspectiva de Cyber Security e Hardening de Acesso

Para um analista de segurança, a camada de autenticação é o principal alvo de ataques automatizados de "Password Spraying" e Brute Force.

Hardening Obrigatório: Desativação de Senhas

A medida mais eficaz de endurecimento em qualquer servidor SSH é a desativação da autenticação por senha.
- Diretiva: PasswordAuthentication no. Ao forçar o uso exclusivo de chaves públicas, o administrador torna ataques de força bruta virtualmente impossíveis, pois tentar adivinhar uma chave Ed25519 ou RSA-4096 exigiria trilhões de anos de computação.

Diretivas Críticas do sshd_config

Prevenção de Enumeração de Usuários

Atacantes tentam descobrir quais nomes de usuários existem no servidor observando pequenas diferenças no tempo de resposta entre um usuário válido e um inválido.
- Defesa: Servidores SSH modernos (como as versões atuais do OpenSSH) utilizam técnicas de "Timing Delay" para garantir que o tempo de resposta seja idêntico para qualquer tentativa falha, frustrando a fase de reconhecimento do invasor.

Defesa contra Brute Force com Fail2Ban

Embora desabilitar senhas resolva o problema na raiz, servidores legados ainda expostos a password devem ser protegidos por ferramentas de análise de log como fail2ban ou sshguard, que banem IPs após N falhas consecutivas em T segundos.

4. Auditoria Técnica e Diagnóstico de Autenticação

Acompanhar as tentativas de entrada permite identificar infiltrações de rede:

# Auditando chaves autorizadas e permissoes de diretório (Crucial para o sucesso do SSH)
ls -ld ~/.ssh && ls -l ~/.ssh/authorized_keys

# Monitorando logs de tentativas falhas de login (Identificacao de Botnets)
grep "Failed password" /var/log/auth.log

# Verificando se o servidor permite login de root (Hardening Audit)
grep "PermitRootLogin" /etc/ssh/sshd_config

# Listando métodos de autenticação aceitos pelo servidor
ssh -v usuario@host 2>&1 | grep "Authentications that can continue"

# Testando especificamente a chave pública (debug)
ssh -v -i ~/.ssh/id_ed25519 usuario@host 2>&1 | grep -E "Offering|Server accepts"

Logs Característicos de Ataque

Feb 12 03:14:22 server sshd[2891]: Failed password for root from 1.2.3.4 port 51022 ssh2
Feb 12 03:14:23 server sshd[2893]: Failed password for admin from 1.2.3.4 port 51024 ssh2
Feb 12 03:14:24 server sshd[2895]: Failed password for test from 1.2.3.4 port 51026 ssh2

Esses padrões indicam password spraying distribuído por nomes de usuário comuns. A resposta operacional padrão é bloquear o IP de origem e revisar a superfície de exposição do serviço SSH à Internet pública.

5. Integração com PAM (Pluggable Authentication Modules)

O módulo UsePAM yes no sshd_config habilita a delegação da verificação de credenciais para a stack PAM do Linux. Isso permite:
- Políticas de complexidade de senha centralizadas.
- Lockout automático após N tentativas (módulo pam_faillock).
- Integração com LDAP, TACACS+ ou RADIUS via módulos dedicados.
- Logs estruturados em /var/log/secure (Red Hat) ou /var/log/auth.log (Debian).

6. Autenticação Multifator (MFA) com OATH-TOTP

A combinação mais comum para MFA em SSH moderno é:
1. Chave pública (algo que o usuário possui).
2. Código TOTP gerado por aplicativo como Google Authenticator (algo que o usuário sabe implicitamente via dispositivo).

Configuração típica envolve o pacote libpam-google-authenticator, adição de auth required pam_google_authenticator.so no stack PAM, e diretiva AuthenticationMethods publickey,keyboard-interactive no sshd_config. O resultado é um servidor SSH em que mesmo o roubo da chave privada não concede acesso sem o token temporal.

7. Conclusão: O Controle de Acesso Soberano

A Camada de Autenticação é a fronteira final que protege os ativos da organização. Sua capacidade de integrar chaves assimétricas de alta resistência e autenticação multifator faz do SSH o padrão de excelência para a gerência de identidades em rede. Domine o uso de chaves públicas Ed25519, desative o acesso por senhas em perímetros vulneráveis, habilite MFA em servidores críticos e audite constantemente os logs de autenticação para garantir que o seu sistema seja um ambiente fechado e seguro, acessível apenas por quem detém a confiança absoluta da infraestrutura.