Hardening SSH: 5 configurações que fecham 95% dos vetores

Suba uma instância nova na AWS, DigitalOcean ou qualquer VPS com a porta 22 exposta e abra o /var/log/auth.log dez minutos depois. Você vai ver algo assim:

Jun  3 10:04:17 sshd[12884]: Failed password for invalid user admin from 45.142.212.100 port 41832 ssh2
Jun  3 10:04:19 sshd[12886]: Failed password for invalid user root from 45.142.212.100 port 41834 ssh2
Jun  3 10:04:21 sshd[12889]: Failed password for invalid user ubuntu from 185.234.219.45 port 22018 ssh2

A internet varre a faixa inteira de IPs o tempo todo. Scripts automatizados testam root, admin, ubuntu, pi, e dicionários de senhas comuns 24 horas por dia. A maioria dos administradores de servidor ignora esse ruído de fundo — até o dia em que uma senha fraca cede. Este post cobre as cinco mudanças de configuração que reduzem radicalmente a superfície de ataque do SSH sem complicar a operação do dia a dia.

Antes de qualquer mudança: crie o par de chaves Ed25519

Tudo começa aqui. Desativar autenticação por senha sem ter uma chave SSH configurada vai te trancar para fora do servidor. Faça isso primeiro, na sua máquina local:

ssh-keygen -t ed25519 -C "voce@servidor"

Por que Ed25519 e não RSA? Ed25519 usa criptografia de curva elíptica — a chave é menor, a operação mais rápida, e o nível de segurança equivale a RSA de 3000+ bits. Desde 2020, todas as distribuições Linux modernas e macOS suportam ed25519 nativamente. Se você ainda usa RSA 2048, está na hora de migrar.

Com o par de chaves gerado (~/.ssh/id_ed25519 e ~/.ssh/id_ed25519.pub), copie a chave pública para o servidor:

ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@IP_DO_SERVIDOR

Teste o acesso com chave antes de fechar a sessão atual. Abra um novo terminal e confirme que o login funciona sem pedir senha. Só então siga para o próximo passo.

As 5 mudanças no sshd_config

O arquivo de configuração fica em /etc/ssh/sshd_config. Faça backup antes de editar:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Localize e ajuste as seguintes diretivas. Se a linha estiver comentada (com # no início), descomente e edite:

1. Desativar login direto como root

PermitRootLogin no

Root é o primeiro usuário que qualquer script de brute force tenta. Sem acesso direto, o atacante precisa comprometer uma conta comum e escalar privilégios — dois passos onde antes havia um.

2. Desativar autenticação por senha

PasswordAuthentication no
KbdInteractiveAuthentication no

Esta é a mudança mais impactante. Com autenticação por chave obrigatória, brute force de senha se torna inútil — não há credencial para adivinhar. O atacante precisaria da sua chave privada, que nunca sai da sua máquina. Segundo o guia de endurecimento documentado pelo Byte Guard e confirmado pelo Hostiserver, esse par de configurações fecha o vetor de ataque mais comum de uma vez só.

3. Limitar tentativas de autenticação

MaxAuthTries 3
LoginGraceTime 30

MaxAuthTries 3 derruba a conexão após três tentativas falhas. LoginGraceTime 30 fecha sessões que ficam penduradas sem completar autenticação em 30 segundos — útil contra técnicas de conexão lenta que tentam esgotar slots disponíveis.

4. Restringir quais usuários podem conectar via SSH

AllowUsers seu_usuario

Substitua seu_usuario pelo nome real do usuário. Se precisar de mais de um, separe com espaço. Qualquer outro usuário do sistema — mesmo com senha válida — fica bloqueado no SSH. Isso limita o raio de blast de uma conta comprometida de outro serviço.

5. Desativar funcionalidades não utilizadas

X11Forwarding no
AllowTcpForwarding no
PrintMotd no

X11Forwarding abre canal para redirecionamento gráfico — desnecessário em servidor headless. AllowTcpForwarding no impede que o SSH seja usado como túnel para tráfego arbitrário, o que pode ser explorado em ataques de pivoting de rede.

Validar e aplicar as mudanças

Antes de reiniciar o daemon, teste a sintaxe do arquivo:

sudo sshd -t

Se não aparecer nenhuma saída, a configuração está válida. Só então reinicie:

sudo systemctl reload sshd
# ou, em sistemas mais antigos:
sudo service ssh restart

Regra crítica: mantenha a sessão atual aberta e teste o acesso em um segundo terminal antes de fechar qualquer coisa. Se travou, a sessão aberta te dá a chance de corrigir.

fail2ban: o porteiro automático

Mesmo com autenticação por chave, requests de conexão maliciosas continuam chegando e consumindo recursos. O fail2ban monitora os logs de autenticação e bane IPs que disparam muitas falhas em sequência:

sudo apt install fail2ban -y

Crie o arquivo de configuração local (nunca edite o jail.conf direto — ele é sobrescrito em atualizações):

sudo nano /etc/fail2ban/jail.local

Conteúdo mínimo funcional:

[sshd]
enabled  = true
port     = ssh
filter   = sshd
maxretry = 3
findtime = 600
bantime  = 3600
logpath  = %(sshd_log)s

Esse bloco bane por 1 hora qualquer IP que errar 3 vezes em 10 minutos. Ajuste bantime conforme o seu nível de paranoia — -1 bane permanentemente. Reinicie o serviço:

sudo systemctl enable fail2ban
sudo systemctl restart fail2ban

Verifique os banimentos ativos com sudo fail2ban-client status sshd.

Vale mudar a porta padrão?

Mudar a porta 22 para algo acima de 1024 é "security through obscurity" — não resolve o problema, mas elimina praticamente todo o ruído de bots automatizados que escaneiam só a porta padrão. O custo é lembrar de especificar a porta em todo comando SSH (ssh -p 2222 usuario@host) e atualizar regras de firewall.

A decisão depende do contexto: em servidor pessoal ou de homelab, vale pelo silêncio nos logs. Em produção corporativa, onde a mudança de porta pode quebrar scripts e pipelines, os cinco passos acima já são suficientes.

Vale lembrar que SSH hardening é uma camada de um sistema maior. Proteção no nível de DNS — como documentado no post sobre NextDNS e DNS criptografado — bloqueia conexões maliciosas antes que cheguem ao seu servidor. E para as contas que você acessa remotamente, entender como MFA fatigue compromete segundo fator ajuda a escolher o método certo de autenticação além do SSH. Se você também gerencia servidores Windows, o PowerShell para auditar logs de segurança cobre o equivalente ao auth.log naquele ambiente.

Checklist rápido antes de finalizar

• Chave Ed25519 copiada e testada no servidor
• PermitRootLogin no ativo
• PasswordAuthentication no e KbdInteractiveAuthentication no
• MaxAuthTries 3 e LoginGraceTime 30
• AllowUsers com lista explícita de usuários
• sshd -t sem erros
• fail2ban rodando com jail do sshd ativo
• Nova sessão SSH testada antes de fechar a antiga

Essas mudanças não exigem software pago, assinatura de serviço ou configuração complexa — são diretivas nativas do OpenSSH disponíveis em qualquer distribuição. O custo é 20 minutos de configuração; o benefício é eliminar a categoria inteira de ataques por força bruta e credencial. Se você gerencia servidores e ainda não aplicou isso, este é um bom ponto de partida.