Basta alocar um IP público em qualquer VPS na AWS, DigitalOcean ou Hetzner para que, em questão de minutos, scanners automatizados comecem a bombardear a porta 22 do seu servidor com ataques de dicionário e força bruta.

Consultar o arquivo /var/log/auth.log (ou journalctl -u ssh) em servidores recém-criados revela milhares de tentativas de autenticação para usuários previsíveis como root, admin, user e postgres.

Neste guia prático de engenharia de sistemas, veremos os 4 passos obrigatórios para blindar o serviço OpenSSH, erradicar autenticação por senha e implementar detecção de intrusos com Fail2ban.

1. Por que Chaves Ed25519 em vez de RSA?

As chaves Ed25519 (baseadas na curva elíptica Curve25519) tornaram-se o padrão da indústria por motivos claros:

  • Segurança Imbatível: Oferecem segurança equivalente a chaves RSA de ~3000 bits com uma fração do tamanho do arquivo (apenas 68 caracteres);
  • Velocidade de Assinatura: O handshake SSH e a verificação criptográfica ocorrem em menos da metade do tempo;
  • Resistência a Canais Laterais: Menos suscetíveis a ataques baseados em tempo de resposta (timing attacks).

Gere sua chave localmente na sua máquina de desenvolvimento:

ssh-keygen -t ed25519 -C "seu-email@dominio.com" -f ~/.ssh/id_ed25519_servidor

Copie a chave pública para o servidor remoto:

ssh-copy-id -i ~/.ssh/id_ed25519_servidor.pub usuario@<IP-DO-SERVIDOR>

2. Configurando o /etc/ssh/sshd_config.d/99-hardening.conf

Em distribuições Linux modernas (Debian 12+, Ubuntu 22.04+), a melhor prática é não alterar o arquivo principal diretamente, mas criar um arquivo de substituição modular em /etc/ssh/sshd_config.d/:

# /etc/ssh/sshd_config.d/99-hardening.conf  # 1. Proibir login direto como superusuário (root) PermitRootLogin no # 2. Desativar completamente autenticação por senha PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no KbdInteractiveAuthentication no # 3. Forçar uso estrito de chaves públicas PubkeyAuthentication yes # 4. Limitar tentativas consecutivas de autenticação MaxAuthTries 3 MaxSessions 2 # 5. Desativar encaminhamento X11 desnecessário X11Forwarding no # 6. Desconectar sessões ociosas automaticamente (após 10 minutos) ClientAliveInterval 300 ClientAliveCountMax 2

Valide a sintaxe antes de reiniciar o daemon:

sudo sshd -t sudo systemctl restart sshd

⚠️ Atenção: Mantenha uma janela de SSH aberta enquanto testa o login em uma nova janela para evitar ficar trancado fora do servidor!

3. Instalando e Ajustando o Fail2ban

O Fail2ban inspeciona os logs do sistema operacional e cria regras dinâmicas de firewall (nftables ou iptables) para banir IPs que apresentem comportamento suspeito:

sudo apt update && sudo apt install -y fail2ban

Crie o arquivo de regras locais em /etc/fail2ban/jail.local:

# /etc/fail2ban/jail.local [DEFAULT] bantime = 24h findtime = 10m maxretry = 3 banaction = nftables-multiport [sshd] enabled = true port = ssh filter = sshd logpath = %(sshd_log)s backend = systemd

Inicie e habilite o serviço:

sudo systemctl enable --now fail2ban

Para verificar o status das jails ativas e a lista de IPs banidos:

sudo fail2ban-client status sshd

Conclusão e Recursos

A segurança de um servidor começa pela superfície de ataque mais exposta. Eliminando o login por senha e aplicando chaves Ed25519 com Fail2ban, você neutraliza mais de 99% dos scanners automatizados da internet.

Confira o guia aprofundado com auditoria de chaves físicas FIDO2 e cofres criptografados no meu blog:

👉 Guia Completo de Hardening no Vexis Sentinel

Você mantém a porta 22 padrão ou costuma alterar para uma porta alta não padrão? Qual a sua estratégia favorita?