SSH hardening no Linux: 7 ajustes essenciais para proteger o acesso remoto

Um servidor Linux com SSH na porta 22 exposto à internet recebe tentativas de login em questão de minutos após ser provisionado. Não é exagero: ferramentas automatizadas varrem blocos de IP 24 horas por dia testando combinações de usuário e senha. A boa notícia é que proteger o SSH não exige semanas de estudo — basta ajustar meia dúzia de parâmetros no arquivo de configuração.

O arquivo que controla tudo

Todas as configurações do servidor SSH ficam em /etc/ssh/sshd_config. Antes de qualquer mudança, faça um backup:

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

Depois de editar o arquivo, valide a sintaxe antes de reiniciar o serviço — assim você não arrisca travar o próprio acesso remoto:

sudo sshd -t

Sem output significa configuração válida. Com o teste passando, aplique as mudanças:

sudo systemctl restart sshd

Regra de ouro: sempre mantenha uma segunda sessão SSH aberta enquanto faz alterações. Se algo der errado, você ainda consegue reverter sem precisar de acesso físico à máquina.

Os 7 ajustes essenciais

Como desativar o login direto como root via SSH?

Basta definir PermitRootLogin no no sshd_config. Isso impede que qualquer atacante force a entrada usando a conta de maior privilégio do sistema.

A maioria dos ataques automatizados tenta o usuário root primeiro porque, se conseguirem, já têm controle total da máquina. Com essa diretiva desativada, o atacante precisa adivinhar tanto o nome do usuário quanto a credencial — o que eleva significativamente o custo do ataque.

PermitRootLogin no

Para tarefas administrativas, faça login com um usuário comum e eleve privilégios com sudo.

2. Substituir senha por chave SSH

Autenticação por chave é tecnicamente superior a senhas: uma chave ed25519 tem complexidade equivalente a centenas de caracteres aleatórios. No cliente, gere o par de chaves:

ssh-keygen -t ed25519 -C "usuario@maquina"

Copie a chave pública para o servidor:

ssh-copy-id usuario@ip-do-servidor

Só depois de confirmar que o login por chave funciona, desative a autenticação por senha:

PasswordAuthentication no

3. Restringir quais usuários podem fazer login

Mesmo que uma conta exista no sistema, você pode impedir que ela use SSH. A diretiva AllowUsers cria uma lista branca explícita:

AllowUsers joao maria deploy

Qualquer conta não listada — incluindo contas de serviço criadas por pacotes instalados automaticamente — é bloqueada por padrão. Para equipes maiores, use AllowGroups sshusers e gerencie via grupo.

4. Limitar tentativas de autenticação por conexão

A diretiva MaxAuthTries define quantas tentativas são permitidas por conexão antes do servidor encerrar a sessão:

MaxAuthTries 3
MaxStartups 3:50:10

MaxStartups 3:50:10 significa: aceitar no máximo 3 conexões não autenticadas simultâneas; a partir daí, rejeitar 50% das novas tentativas até atingir 10, quando todas passam a ser rejeitadas. Isso dificulta ataques que abrem muitas conexões em paralelo.

5. Encerrar sessões inativas automaticamente

Sessões SSH abandonadas são um risco real: um terminal desbloqueado numa máquina comprometida pode ser usado por quem tiver acesso local. Configure timeout automático:

ClientAliveInterval 300
ClientAliveCountMax 2

O servidor envia um sinal a cada 300 segundos. Após 2 sinais sem resposta, a sessão é encerrada — ou seja, qualquer sessão inativa por mais de 10 minutos cai automaticamente.

6. Desativar recursos que você não usa

O OpenSSH vem com várias funcionalidades ativas por padrão que a maioria dos servidores não precisa. Cada funcionalidade ativa é uma superfície de ataque potencial:

# Interface gráfica via SSH — raramente necessário em servidores headless
X11Forwarding no

# Impede que o SSH seja usado como túnel TCP genérico
AllowTcpForwarding no

# Evita que um servidor comprometido use seu agente SSH local
AllowAgentForwarding no

7. Bloquear IPs com fail2ban

Mesmo com autenticação por chave e MaxAuthTries configurados, as tentativas de conexão continuam chegando e poluem os logs. O fail2ban automatiza o banimento de IPs que excedem um limite de tentativas falhas em janelas de tempo — é o complemento essencial para o que você configurou no sshd_config.

Verificando os logs depois dos ajustes

Após aplicar as mudanças, monitore os logs para confirmar que as tentativas estão sendo bloqueadas:

# Sistemas com journald (Ubuntu 20+, Debian 11+, Fedora)
sudo journalctl -u sshd --since "1 hour ago" | grep -i "failed\|invalid"

# Sistemas com auth.log clássico
sudo grep "Failed password\|Invalid user" /var/log/auth.log | tail -20

Se você ainda vir centenas de linhas de tentativas, configure o fail2ban — o guia mencionado acima mostra o processo completo, incluindo como ajustar os limites de ban e whitelist de IPs confiáveis.

E se o servidor já foi comprometido?

Hardening previne invasões futuras, mas não apaga rastros de comprometimentos anteriores. Se o servidor apresenta comportamento estranho — processos desconhecidos, tráfego inesperado, arquivos modificados em horários suspeitos — os mesmos indicadores do guia sobre como identificar sinais de comprometimento se aplicam a servidores. Em especial, compare os hashes de binários críticos como /usr/sbin/sshd com os pacotes originais da sua distribuição.

Para quem também gerencia ambientes Windows, o processo é diferente mas igualmente urgente: veja os 7 ajustes para proteger o RDP contra força bruta e ransomware.

Configuração completa em uma tacada

Para garantir que todos os parâmetros estão presentes e corretos no seu sshd_config:

PermitRootLogin no
PasswordAuthentication no
AllowUsers seu_usuario
MaxAuthTries 3
MaxStartups 3:50:10
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no

Valide com sudo sshd -t, reinicie com sudo systemctl restart sshd e monitore os logs nas primeiras horas. Esses 10 parâmetros cobrem a grande maioria dos vetores de ataque contra SSH — sem precisar de ferramentas externas além do fail2ban.