Usuário e Senha

O método de Usuário e Senha (password authentication) é a forma mais elementar de identificação de usuário no protocolo SSH. Embora seja o método menos seguro em comparação ao uso de chaves assimétricas, ele permanece como o mecanismo de contingência padrão em quase todas as distribuições Linux e sistemas Unix, permitindo o acesso inicial antes da configuração de métodos mais robustos.

1. O Fluxo de Autenticação por Senha

Diferente de protocolos inseguros como o Telnet, onde a senha viaja em texto claro, no SSH o envio da senha só ocorre após o estabelecimento do túnel cifrado.

O processo técnico segue estes passos:

1. Requisição: O cliente envia uma mensagem SSH_MSG_USERAUTH_REQUEST especificando o método "password".
2. Prompt: O cliente solicita ao usuário local que digite a senha.
3. Envio Cifrado: A senha é encapsulada em um pacote SSH, cifrada com a Chave de Sessão Simétrica (gerada no KEX) e enviada ao servidor.
4. Validação: O servidor recebe o pacote, decifra-o e compara o conteúdo com o banco de dados de autenticação do sistema.

Sequência de Mensagens

Vantagem sobre Telnet/FTP

Em Telnet, FTP e POP3 sem TLS, a senha viaja em texto claro e pode ser capturada por sniffing ou MITM. No SSH, mesmo com uma senha fraca, o atacante que intercepta o tráfego vê apenas bytes cifrados, tornando a captura inútil sem a chave de sessão.

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

Em sistemas modernos como Ubuntu, Debian ou CentOS, o servidor SSH (sshd) não verifica o arquivo /etc/shadow diretamente. Ele delega essa tarefa ao PAM.

• Flexibilidade: O PAM permite que o servidor SSH autentique o usuário contra diversas fontes: arquivos locais, servidores LDAP, Active Directory ou bancos de dados SQL.
• Controle de Acesso: Através do PAM, o sistema pode impor restrições adicionais, como proibir logins de senha para determinados usuários ou exigir que a senha seja trocada no primeiro acesso.
• Módulos Comuns: pam_unix.so, pam_ldap.so, pam_krb5.so, pam_google_authenticator.so.

Exemplo de Stack PAM para SSH

# /etc/pam.d/sshd
auth     required   pam_google_authenticator.so
auth     include    password-auth
account  required   pam_nologin.so
account  include    password-auth
session  required   pam_loginuid.so

3. Vulnerabilidades e Riscos

O uso de senhas expõe o servidor a vetores de ataque específicos:

• Brute Force (Força Bruta): Atacantes utilizam bots para tentar milhares de combinações de usuários (admin, root, user) e senhas comuns. Ferramentas como Hydra, Medusa e Ncrack rodam milhares de tentativas por minuto.
• Dictionary Attacks: Uso de listas como "RockYou" (14 milhões de senhas vazadas) ainda é eficaz em 2024.
• Credential Stuffing: Reaproveitamento de pares usuário/senha vazados em outros vazamentos (Have I Been Pwned).
• Shoulder Surfing / Keylogging: A senha pode ser capturada por observação física ou malware no computador do cliente.

Estatísticas

4. Mitigação e Hardening

Para manter o uso de senhas minimamente seguro, administradores aplicam técnicas de endurecimento:

• Fail2Ban: Um serviço que monitora os logs de erro (/var/log/auth.log) e bane temporariamente o endereço IP que exceder um número X de tentativas de senha inválidas.
• Complexidade de Senha: Uso de módulos como pam_pwquality para exigir letras maiúsculas, números e caracteres especiais.
• Desativação do Root: Configurar PermitRootLogin prohibit-password ou no no arquivo sshd_config obriga o atacante a adivinhar também o nome de um usuário comum, dobrando o esforço necessário.
• Mudança de Porta: Mover o SSH da porta 22 para 2222 elimina 90% dos bots automatizados.
• AllowUsers / AllowGroups: Restringir logins a um conjunto explícito de contas autorizadas.
• Rate Limiting via iptables: Limitar conexões novas por IP por unidade de tempo.

Exemplo Fail2Ban

# /etc/fail2ban/jail.local
[sshd]
enabled  = true
port     = 22
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
bantime  = 3600
findtime = 600

Rate Limiting com iptables

# Permite no máximo 3 conexões SSH novas a cada 60s por IP
sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --set
sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
    -m recent --update --seconds 60 --hitcount 4 -j DROP

5. Configuração no sshd_config

O comportamento deste método é controlado por diretivas específicas no servidor:

PasswordAuthentication yes       # Habilita o uso de senhas
PermitEmptyPasswords no          # Proíbe usuários sem senha (crítico!)
MaxAuthTries 3                  # Tentativas antes de derrubar a conexão
LoginGraceTime 30               # Tempo máximo para autenticar-se (segundos)
PermitRootLogin prohibit-password # Root apenas por chave pública
UsePAM yes                      # Habilita integração com PAM
AllowUsers admin devops         # Lista branca de usuários

Diretivas Complementares

Configuração Recomendada para Produção

Em ambientes modernos, recomenda-se desativar completamente o método de senha:

PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no

6. Transição para MFA (Multi-Factor Authentication)

Muitas organizações utilizam o método de senha apenas como o primeiro fator de uma autenticação interativa. Após a senha ser validada, o servidor envia um segundo desafio (via keyboard-interactive) solicitando um código OTP (One-Time Password), elevando significativamente o nível de segurança do acesso.

Implementação Típica com Google Authenticator

1. Instalar libpam-google-authenticator no servidor.
2. Configurar /etc/pam.d/sshd com auth required pam_google_authenticator.so.
3. Habilitar KbdInteractiveAuthentication yes no sshd_config.
4. Usuário executa google-authenticator para gerar o segredo TOTP.
5. Cada login agora exige senha + código de 6 dígitos do app.

7. Senhas vs Chaves: Comparativo

8. Análise de Logs de Autenticação

Em sistemas Linux, os logs do SSH ficam em /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL/CentOS):

# Login bem-sucedido
Apr 05 14:32:10 servidor sshd[12345]: Accepted password for joao from 192.168.1.50 port 49152 ssh2

# Senha incorreta
Apr 05 14:33:15 servidor sshd[12347]: Failed password for invalid user admin from 203.0.113.10 port 51022 ssh2

# Conexão encerrada por MaxAuthTries
Apr 05 14:33:25 servidor sshd[12349]: error: maximum authentication attempts exceeded for root from 203.0.113.10 port 51024 ssh2 [preauth]

Comandos Úteis

# Contar tentativas falhas por IP
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20

# Listar logins bem-sucedidos do dia
sudo grep "Accepted password" /var/log/auth.log | grep "$(date +%b\ %d)"

9. Conclusão

O método de usuário e senha no SSH é um legado histórico que ainda tem seu lugar em ambientes de desenvolvimento, recuperação de desastres e como camada inicial de identificação. No entanto, em ambientes de produção acessíveis via internet, ele deve ser substituído por chaves públicas ou complementado com MFA. Profissionais de redes que compreendem os vetores de ataque, as integrações PAM e as técnicas de hardening conseguem manter sistemas legados operacionais sem comprometer a postura de segurança da organização.