Autenticação Multifator (MFA) no SSH

A Autenticação Multifator (MFA) no SSH é uma camada de segurança avançada que exige que o usuário apresente duas ou mais provas independentes de identidade antes de obter acesso ao servidor. Em um ambiente de alta segurança, depender de apenas um fator (como uma senha que pode ser roubada ou uma chave privada que pode ser copiada de um laptop perdido) é considerado um risco. A referência normativa principal é a NIST SP 800-63B (Digital Identity Guidelines), além das RFCs 4252 (Authentication) e 4256 (keyboard-interactive).

1. Os Três Fatores de Autenticação

O MFA combina diferentes categorias de evidências, geralmente classificadas como:

• Fator 1 - Algo que você sabe: Uma senha ou frase secreta (knowledge factor).
• Fator 2 - Algo que você possui: Uma chave física (Yubikey), um smartphone (Google Authenticator) ou uma chave privada SSH (possession factor).
• Fator 3 - Algo que você é: Biometria (impressão digital ou reconhecimento facial) usada para desbloquear o dispositivo que contém a chave (inherence factor).
• Fator 4 (contextual) - Algo que você está em: Localização geográfica, horário, rede confiançada (Contextual/Adaptive factor).

Para ser considerado "Multifator", a autenticação deve combinar pelo menos dois fatores diferentes. Usar duas senhas não é MFA; usar senha + TOTP é MFA.

2. Funcionamento Técnico no SSH

O protocolo SSH-2 (RFC 4252) suporta nativamente a exigência de múltiplos métodos de autenticação em sequência. Quando o MFA está ativo, o servidor não libera o shell após o primeiro sucesso; ele envia um novo desafio até que todos os métodos requeridos sejam satisfeitos.

Fluxo de Mensagens SSH_USERAUTH

1. Cliente envia SSH_MSG_USERAUTH_REQUEST com método publickey.
2. Servidor valida a chave pública e responde SSH_MSG_USERAUTH_SUCCESS parcial OU SSH_MSG_USERAUTH_FAILURE com lista de métodos restantes (keyboard-interactive).
3. Cliente envia SSH_MSG_USERAUTH_REQUEST com keyboard-interactive.
4. Servidor envia SSH_MSG_USERAUTH_INFO_REQUEST com prompt: "Digite o código de 6 dígitos do seu autenticador:".
5. Cliente envia SSH_MSG_USERAUTH_INFO_RESPONSE com o código TOTP.
6. Servidor valida contra /etc/security/totp e libera SSH_MSG_USERAUTH_SUCCESS.

A implementação mais comum utiliza o método keyboard-interactive (RFC 4256), que permite ao servidor enviar prompts de texto genéricos para o cliente, como: "Digite o código de 6 dígitos do seu autenticador:". Esse método é mais flexível que o password tradicional, pois suporta múltiplos prompts em uma única rodada.

3. Combinações Comuns de MFA

Existem várias formas de estruturar o MFA em um servidor SSH:

Detalhes das Combinações

• Chave Pública + Senha: O usuário deve possuir a chave privada correta e, em seguida, digitar a senha do sistema. Isso protege contra o roubo da chave física e contra ataques de força bruta à senha.
• Chave Pública + TOTP (Google Authenticator/Authy): Após a validação da chave, o servidor solicita um código temporário (Time-based One-Time Password, RFC 6238) gerado por um aplicativo no celular do usuário. Janela de validade típica: 30 segundos, com tolerância de ±1 passo (configurável).
• Chave Pública + FIDO2/U2F: O padrão mais moderno, onde o SSH se comunica diretamente com uma chave de segurança física (como uma YubiKey). O usuário deve tocar fisicamente no dispositivo para autorizar a conexão. Suporte nativo a partir do OpenSSH 8.2 (fevereiro 2020).

4. Implementação via PAM e Google Authenticator

No Linux, a forma mais popular de adicionar o segundo fator é através do módulo libpam-google-authenticator (TOTP, RFC 6238), integrado ao PAM (Pluggable Authentication Modules).

Passo a Passo de Implementação

1. Instalação do módulo no servidor:

# Debian/Ubuntu
sudo apt install libpam-google-authenticator
# RHEL/CentOS/Fedora
sudo dnf install google-authenticator

2. Geração de credenciais TOTP para cada usuário (executado pelo próprio usuário):

google-authenticator -t -d -f -r 3 -R 30 -W
# -t: Time-based (TOTP)
# -d: Disallow reuse of tokens
# -f: Force (nao perguntar)
# -r 3: Max 3 tentativas por 30s
# -R 30: Janela de rate limit de 30s
# -W: Exibe QR code no terminal

3. Configuração do PAM em /etc/pam.d/sshd:

# Adicionar no topo do arquivo
auth required pam_google_authenticator.so nullok
# nullok: usuarios sem secret configurado ainda podem logar (remover em producao)

4. Ajuste do sshd_config para habilitar o keyboard-interactive e exigir múltiplos métodos:

ChallengeResponseAuthentication yes
KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

5. Reinicialização do sshd:

sudo systemctl restart sshd

5. Configuração Avançada no sshd_config

Para forçar o uso de dois fatores, utiliza-se a diretiva AuthenticationMethods:

# Exige chave publica E TOTP (PAM keyboard-interactive)
AuthenticationMethods publickey,keyboard-interactive

# Exige SOMENTE chave publica (sem segundo fator - MFA desligado)
AuthenticationMethods publickey

# Exige chave publica OU senha (nao e MFA, e fail-open)
AuthenticationMethods publickey password

# Exige tres fatores: certificado + chave + TOTP
AuthenticationMethods publickey,publickey,keyboard-interactive

Diretivas de Endurecimento Complementar

6. FIDO2/U2F via YubiKey (OpenSSH 8.2+)

A integração nativa com chaves FIDO2 é o estado da arte em MFA SSH:

# Gerar chave Ed25519 residente na YubiKey (sk-ssh-ed25519@openssh.com)
ssh-keygen -t ed25519-sk -f ~/.ssh/yubi_key -C "yubikey-mfa"
# -sk indica Security Key (FIDO2)

# Versao com PIN (ainda mais robusta)
ssh-keygen -t ed25519-sk -O resident -O verify-required -f ~/.ssh/yubi_key

# Listar chaves residentes na YubiKey
ssh-keygen -K

# Ao conectar, o servidor exige a chave publica Ed25519-sk E o toque fisico
ssh -i ~/.ssh/yubi_key user@server

Vantagens do FIDO2:
- Phishing-resistant: a chave é atrelada ao origin/hostname durante o registro.
- Não há código para digitar: o usuário apenas toca no dispositivo.
- Resistente a MITM: o desafio criptográfico é origin-bound.

7. Benefícios Críticos do MFA

• Proteção contra Credenciais Vazadas: Mesmo que um atacante obtenha sua senha e sua chave privada, ele ainda precisaria do seu dispositivo físico (celular ou token) para entrar.
• Conformidade (Compliance): Muitas normas de segurança exigem MFA para qualquer acesso administrativo a servidores que manipulem dados sensíveis.
  • PCI-DSS 4.0 (Requisito 8.4.2): MFA para todo acesso ao Cardholder Data Environment.
  • SOC 2 (CC6.1): MFA para acesso a sistemas de produção.
  • ISO 27001:2022 (Controle 8.5): Autenticação multifator para acesso remoto.
  • LGPD/GDPR: Indiretamente exigido para proteção de dados pessoais em servidores.
  • HIPAA (§164.312(d)): Autenticação robusta para PHI.
• Mitigação de Phishing: Como os códigos TOTP expiram em 30 segundos e as chaves FIDO2 são atreladas ao domínio/host, é extremamente difícil para um invasor interceptar e usar esses fatores em tempo real.
• Redução de Superfície de Ataque: Ataques de brute force e credential stuffing tornam-se inúteis, pois cada fator adicional aumenta a entropia exponencialmente.

8. Desafios e Considerações Operacionais

• Recuperação de Acesso: Se o usuário perder o dispositivo TOTP, é necessário um processo de bypass (admin recovery) documentado. Comum: backup codes (8-10 códigos de uso único impressos guardados em cofre físico).
• Sincronização de Tempo: TOTP exige que servidor e cliente estejam com relógio sincronizado (NTP). Diferença de ±30s já pode quebrar a autenticação.
• Automação/Scripts: MFA quebra automações que usem SSH non-interactive (cron, CI/CD). Solução: usar chaves SSH com from="IP" restrito para jobs automatizados, sem MFA, mas com isolamento de rede estrito.
• Latência: Cada fator adicional adiciona segundos à sessão. Em jump hosts de produção com centenas de conexões por dia, isso soma.

9. Conclusão Técnica

A Autenticação Multifator deixou de ser opcional em infraestruturas críticas. Com a evolução do SSH-2 e do PAM, implementar MFA tornou-se uma operação de configuração, não de desenvolvimento. A recomendação moderna é migrar gradualmente de TOTP para FIDO2 (YubiKey/Touch ID) por sua resistência superior a phishing. Para o administrador, o MFA não é apenas uma camada a mais de defesa: é o que separa uma invasão bem-sucedida de um ataque contido, especialmente quando credenciais SSH vazam em ataques de supply chain ou phishing direcionado a administradores.