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:

1. Garanta que você tem um usuário comum com poderes de sudo (já que vamos desativar o login direto do root).
2. 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 noPermitEmptyPasswords noPubkeyAuthentication yes# 3. Limitar tentativas de autenticação antes de desconectarMaxAuthTries 3# 4. Desativar recursos desnecessários para reduzir superfície de ataqueX11Forwarding noAllowAgentForwarding noAllowTcpForwarding no# 5. Manter conexão ativa sem cair por inatividadeClientAliveInterval 300ClientAliveCountMax 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# ousudo 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çãosudo 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 banbackend = systemd # Monitora logs via journald do Linux[sshd]enabled = trueport = sshmode = 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/

Source