Hardening de SSH no Linux: Checklist prático para blindar servidores contra força bruta e botnets
Se você tem qualquer servidor Linux (VPS na Hetzner, AWS, DigitalOcean ou Oracle Cloud) com a porta 22 exposta para a internet, basta rodar journalctl -u ssh -n 50 para ver milhares de tentativas de invasão por dicionário (brute-force bots) vindas do mundo inteiro a cada hora.
Deixar o SSH configurado com as opções padrão de fábrica (autenticação por senha ativa e login direto de root) é um dos maiores riscos operacionais em infraestrutura.
Abaixo está um passo a passo objetivo para blindar seu servidor SSH com chaves criptográficas modernas e proteção ativa contra ataques.
1. Adeus RSA, Bem-vindo Ed25519
O algoritmo RSA tradicional (mesmo em 4096 bits) é mais lento e suscetível a implementações vulneráveis. O padrão atual recomendado pela comunidade de segurança é a curva elíptica Ed25519: chaves muito menores (68 caracteres), matematicamente mais seguras e extremamente rápidas.
No seu computador local (máquina de onde você acessa o servidor):
# -t ed25519: Tipo da chave
# -a 100: 100 rounds de derivação KDF (dificulta ataques de força bruta se a chave privada vazar)
ssh-keygen -t ed25519 -a 100 -C "admin@sua-empresa.com"
Copie a chave pública para o servidor:
ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@seu-servidor-ip
2. A Regra Anti-Lockout (Não fique trancado para fora!)
Antes de desativar senhas ou reiniciar o SSH:
- Garanta que você tem um usuário comum com poderes de
sudo(já que vamos desativar o login direto doroot). - NUNCA feche a sessão SSH atual. Mantenha a janela atual conectada como "salva-vidas", faça as alterações e abra uma segunda janela de terminal para testar antes de deslogar.
3. Configuração Restritiva do SSH (sshd_config)
Nas distros modernas (Ubuntu 22.04+, Debian 12+, Rocky Linux), o recomendado é não editar o /etc/ssh/sshd_config principal, mas sim criar um arquivo dedicado dentro de /etc/ssh/sshd_config.d/:
Crie o arquivo /etc/ssh/sshd_config.d/99-hardening.conf:
# 1. Proibir login direto de root (obrigatório usar usuário com sudo)
PermitRootLogin no
# 2. Desativar completamente login por senha (apenas chaves SSH autorizadas)
PasswordAuthentication no
PermitEmptyPasswords no
PubkeyAuthentication yes
# 3. Limitar tentativas de autenticação antes de desconectar
MaxAuthTries 3
# 4. Desativar recursos desnecessários para reduzir superfície de ataque
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
# 5. Manter conexão ativa sem cair por inatividade
ClientAliveInterval 300
ClientAliveCountMax 2
Valide a sintaxe do arquivo antes de reiniciar o serviço:
# Se retornar em branco, a sintaxe está perfeita!
sudo sshd -t
Se o teste passou com sucesso, aplique a nova configuração:
sudo systemctl reload ssh # Em Debian/Ubuntu
# ou
sudo systemctl reload sshd # Em RHEL/CentOS/Rocky
4. Instalando o Fail2ban (Bloqueio Automático de IPs)
Mesmo sem senhas, botnets continuam inundando a porta 22 e consumindo recursos do servidor. O Fail2ban monitora os logs de falha e cria regras dinâmicas de firewall (iptables ou nftables) bloqueando o IP atacante.
# Instalação
sudo apt update && sudo apt install fail2ban -y
Crie o arquivo de configuração local /etc/fail2ban/jail.local:
[DEFAULT]
bantime = 1h # Tempo de banimento inicial (1 hora)
findtime = 10m # Janela de análise de tentativas (10 minutos)
maxretry = 3 # Máximo de tentativas com erro antes do ban
backend = systemd # Monitora logs via journald do Linux
[sshd]
enabled = true
port = ssh
mode = aggressive
Inicie e habilite o serviço:
sudo systemctl enable --now fail2ban
# Para conferir o status e a lista de IPs bloqueados:
sudo fail2ban-client status sshd
Vocês costumam alterar a porta padrão 22 nos servidores de vocês ou consideram que chave Ed25519 + Fail2ban já resolve 99% do ruído?
Guia detalhado de segurança e conectividade Linux: tecmestre.com.br/como-configurar-ssh-seguro-no-linux/