04 - Identificação do Usuário

A Identificação do Usuário é a fase final do processo de autenticação do SSH. Ela ocorre dentro do túnel criptografado estabelecido nas fases anteriores, garantindo que as credenciais nunca vazem.

1. O Protocolo de Autenticação (RFC 4252)

O SSH suporta vários métodos de autenticação. O servidor pode exigir um ou mais métodos simultâneos (MFA).

A RFC 4252 define o protocolo de autenticação do SSH-2. Após o túnel de transporte ser estabelecido (RFC 4253), o cliente envia o pedido de autenticação com o nome de usuário e o método desejado. O servidor responde com:

• SSH_MSG_USERAUTH_SUCCESS — Aceito.
• SSH_MSG_USERAUTH_FAILURE — Recusado, com lista de métodos que ainda podem ser tentados.
• SSH_MSG_USERAUTH_PK_OK — Desafio aceito, continue o método (em auth de chave pública).

A. Autenticação por Senha (Password)

• O cliente envia o nome de usuário e a senha.
• O servidor valida a senha no sistema de arquivos local (ex: /etc/shadow) ou via PAM (Pluggable Authentication Modules).
• Risco: Vulnerável a ataques de força bruta se a senha for fraca.

B. Autenticação por Chave Pública (Public Key)

• É o método mais seguro e recomendado.
• O servidor possui a Chave Pública do usuário (armazenada em ~/.ssh/authorized_keys).
• O cliente possui a Chave Privada correspondente.
• Processo: O servidor envia um "Desafio" (um valor aleatório) para o cliente. O cliente assina esse desafio com sua chave privada e devolve ao servidor. O servidor usa a chave pública para verificar a assinatura e permitir o acesso.
• Vantagem: A chave privada nunca é enviada pelo túnel.

Fluxo Detalhado de Public Key

1. Cliente gera par de chaves: ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519.
2. Cliente copia chave pública para servidor: ssh-copy-id usuario@servidor.
3. Servidor armazena em ~/.ssh/authorized_keys.
4. No login, cliente envia SSH_MSG_USERAUTH_REQUEST com método publickey e ID da chave.
5. Servidor responde SSH_MSG_USERAUTH_PK_OK com um desafio aleatório.
6. Cliente assina o desafio com sua chave privada e envia a assinatura.
7. Servidor valida a assinatura com a chave pública correspondente e aprova o acesso.

2. Outros Métodos de Autenticação

• Keyboard-Interactive: Uma variação do método de senha que permite que o servidor faça perguntas dinâmicas ao usuário (como um desafio de Segundo Fator - SMS, TOTP, etc.).
• GSSAPI (Kerberos): Usado em ambientes corporativos Windows/Active Directory para login único (Single Sign-On).
• Host-based: Autenticação baseada no IP e no nome do computador do cliente (hoje descontinuada por ser insegura).

Comparativo dos Métodos

3. O Arquivo authorized_keys

O arquivo ~/.ssh/authorized_keys é a lista de chaves públicas autorizadas a logar como aquele usuário. Cada linha tem o formato:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... comentario@host

Restrições por Chave

A partir da OpenSSH 7.8+, é possível adicionar restrições a cada chave pública:

# Apenas para tunnels, sem shell interativo
tunnel="0",no-pty,no-X11-forwarding ssh-ed25519 AAAA...

# Restringe origem (IP) e comando a executar
from="192.168.1.0/24",command="/usr/bin/backup.sh" ssh-ed25519 AAAA...

# Expira automaticamente
expiry-time="20251231T235959" ssh-ed25519 AAAA...

Permissões Críticas

O SSH é rigoroso quanto a permissões de arquivos. Se estiverem erradas, a chave pública é ignorada:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519       # chave privada
chmod 644 ~/.ssh/id_ed25519.pub   # chave pública

Permissões erradas são a causa mais comum de "por que minha chave SSH não funciona?" — o servidor recusa silenciosamente chaves em diretórios com permissões group/other escritas.

4. Banner de Identificação

O SSH-2 permite que o servidor envie um banner de pré-autenticação (RFC 4252, seção 5.4). Esse banner aparece antes do prompt de senha e é usado para avisos legais:

# /etc/ssh/sshd_config
Banner /etc/ssh/banner.txt

Conteúdo típico:

ATENCAO: Sistema restrito. Acesso nao autorizado e crime.
Suas atividades sao monitoradas e registradas.

Legalmente, o banner deve aparecer antes do login para que o atacante não possa alegar que não foi avisado — jurisprudência dos EUA (caso United States v. Heckenkamp, 2007).

5. Melhores Práticas de Cyber

Para garantir que a identificação do usuário seja robusta:
1. Desabilite senhas: Forçar o uso exclusivo de chaves públicas.
2. Use MFA (Multi-Factor Authentication): Exigir, além da chave pública, um código de seis dígitos (Google Authenticator) ou uma chave física (Yubikey).
3. Proteja a Chave Privada: Sempre use uma senha forte (passphrase) para proteger o arquivo da chave privada no seu computador local.
4. Use Algoritmos Fortes: Prefira chaves do tipo Ed25519 em vez do antigo RSA.
- Ex: ssh-keygen -t ed25519 -a 100 (o parâmetro -a 100 aumenta a dificuldade de um ataque de força bruta contra a passphrase da chave).

Hardening de sshd_config

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers admin deploy
PermitEmptyPasswords no
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

Hardening Adicional

• Fail2Ban: Monitora logs e bloqueia IPs com muitas tentativas falhas.
• Porta não-padrão: Mudar SSH de 22 para 22222 reduz ruído de bots em 99% (mas é obscuridade, não segurança real).
• VPN + SSH: Exigir VPN antes de chegar ao SSH, dobrando a camada de defesa.
• TOTP via PAM: Integrar Google Authenticator para 2FA em SSH.
• Cert-based SSH: Usar CA (Certificate Authority) SSH ao invés de authorized_keys por usuário, simplificando gestão em grandes ambientes.

6. SSH Certificates (CA-based)

Em ambientes grandes (centenas de servidores), gerenciar authorized_keys em cada servidor é inviável. A solução é usar SSH Certificates (OpenSSH 5.6+):

1. Admin cria uma CA SSH (par de chaves).
2. Servidores confiam na CA via TrustedUserCAKeys /etc/ssh/ca.pub.
3. Para dar acesso a um usuário, admin assina sua chave pública com a CA: ssh-keygen -s ca_key -I usuario -V +1d user_key.pub.
4. Gera-se um certificado user_key-cert.pub válido por 1 dia.
5. Usuário loga com ssh -i user_key servidor — o servidor valida a assinatura da CA, não precisa do authorized_keys.

Isso revoga acesso automaticamente após o prazo do certificado e elimina a gestão de chaves distribuídas.

7. Resumo Técnico

8. Conclusão

A identificação do usuário no SSH é o estágio mais visado por atacantes — afinal, é aqui que se prova o direito de acesso. Compreender os métodos de autenticação, as nuances do authorized_keys, as restrições por chave e os mecanismos avançados como SSH Certificates é o que separa um administrador iniciante de um engenheiro de segurança maduro. As melhores práticas modernas convergem para chaves Ed25519 com passphrase forte, MFA habilitado e gestão via CA em ambientes de escala.