SSH hardening: configurações essenciais para servidores Linux

Em praticamente todo ambiente Linux, o SSH é a porta de entrada administrativa mais usada, e justamente por isso é também um dos serviços mais visados por tentativas automatizadas de acesso indevido. Fazer hardening de SSH não significa transformar o servidor em um bunker onde nem você mesmo consegue entrar depois de esquecer alguma configuração; significa fechar deliberadamente cada caminho que não é estritamente necessário para a administração legítima da máquina.

Antes de qualquer alteração: garanta uma via de retorno

O erro mais comum ao endurecer configurações de SSH é aplicar uma mudança arriscada e recarregar o serviço sem manter nenhuma forma alternativa de acesso. Não é pessimismo, é experiência coletiva de quem já transformou uma simples correção de segurança em uma viagem não planejada até o console do servidor. Antes de editar /etc/ssh/sshd_config, siga sempre esta sequência:

1. Mantenha a sessão SSH atual aberta durante todo o processo de alteração.
2. Sempre que possível, garanta acesso via console local, KVM ou console do provedor de nuvem, como alternativa caso o SSH pare de responder.
3. Valide a sintaxe do arquivo de configuração antes de recarregar o serviço.
4. Abra uma segunda sessão, em uma nova janela de terminal, para confirmar que o acesso continua funcionando antes de encerrar a sessão original.

sudo sshd -t
sudo systemctl reload ssh

Esse cuidado parece óbvio até o dia em que alguém pula essa etapa e passa a tarde explicando, no chamado de emergência, por que o servidor de produção só aceita visitas físicas agora.

Autenticação por chave em vez de senha

Senhas são vulneráveis a ataques de força bruta e à reutilização de credenciais vazadas em outros serviços, muitas vezes sem que o dono da senha nem saiba que ela já circula por aí. Chaves criptográficas assimétricas, por outro lado, oferecem um nível de resistência muito superior contra tentativas automatizadas de acesso.

O processo recomendado é gerar um par de chaves para cada administrador, proteger a chave privada com uma passphrase forte e, idealmente, guardá-la em um agente SSH ou token de hardware. Somente depois de confirmar que todos os administradores conseguem autenticar corretamente por chave, a autenticação por senha deve ser desabilitada:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

Desabilitar a autenticação por senha antes de validar completamente o acesso por chave é uma das formas mais populares, e mais evitáveis, de perder acesso administrativo a um servidor remoto.

Restringindo o acesso como root

Permitir login direto como root remove uma camada importante de rastreabilidade, já que ações executadas diretamente pelo usuário root não podem ser atribuídas a um administrador específico. A prática recomendada é desabilitar o login direto de root e exigir que os administradores autentiquem com contas nominais, elevando privilégios via sudo apenas quando necessário:

PermitRootLogin no
AllowUsers administrador automacao

A diretiva AllowUsers, ou alternativamente AllowGroups, permite restringir explicitamente quais contas têm permissão de autenticar via SSH, algo especialmente útil em servidores com múltiplas contas de sistema que jamais deveriam aceitar login remoto, mas que, sem essa restrição, aceitariam tranquilamente.

Reduzindo funcionalidades desnecessárias

O daemon SSH oferece diversos recursos além da simples autenticação de terminal, e nem todos são necessários em todo ambiente. Avaliar e desabilitar recursos não utilizados reduz a superfície de ataque disponível:

X11Forwarding no
AllowTcpForwarding no
PermitTunnel no
AllowAgentForwarding no

Vale avaliar cada uma dessas diretivas no contexto específico do ambiente. Algumas automações e ferramentas legítimas de administração dependem de encaminhamento de porta ou de agente SSH, então desabilitar esses recursos sem validação prévia pode quebrar fluxos de trabalho existentes, e ninguém quer ser a pessoa que derrubou a automação de deploy no meio da tarde.

Limitando tentativas e monitorando falhas

Mesmo com autenticação por chave, vale a pena limitar a taxa de tentativas de conexão e monitorar ativamente falhas de autenticação. Ferramentas como fail2ban observam os logs do sistema e bloqueiam temporariamente endereços IP com número excessivo de tentativas falhas, reduzindo o ruído constante de scanners automatizados e tentativas de força bruta:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Complementarmente, diretivas como MaxAuthTries e LoginGraceTime no próprio arquivo de configuração do SSH ajudam a limitar quantas tentativas uma única conexão pode fazer antes de ser encerrada, o que também poupa um pouco da paciência de quem lê o log depois.

Protegendo o acesso na camada de rede

Além das configurações do próprio serviço SSH, restringir o acesso à porta correspondente via firewall é uma camada adicional relevante. Sempre que possível, o SSH deveria estar acessível apenas a partir de redes de administração conhecidas, seja através de uma VPN corporativa, de um bastion host dedicado ou de uma lista explícita de endereços IP autorizados.

Trocar a porta padrão do SSH pode reduzir o volume de tentativas automatizadas feitas por scanners genéricos que só testam a porta 22, mas essa medida, isoladamente, é apenas uma redução de ruído de fundo e não substitui autenticação forte nem controle de acesso por rede.

Auditoria e revisão periódica

Hardening não é tarefa de uma vez só e depois esquecer para sempre. É recomendável revisar periodicamente:

• A lista de usuários autorizados a autenticar via SSH, removendo contas de quem já não faz parte da equipe.
• As chaves públicas cadastradas em cada servidor, eliminando chaves de dispositivos ou pessoas que não precisam mais de acesso.
• Os logs de autenticação, buscando padrões anômalos de tentativas de acesso ou horários incomuns de conexão.
• A versão do serviço SSH instalada, aplicando atualizações de segurança conforme divulgadas pelo fornecedor da distribuição.

Validação final após qualquer mudança

1. Abra uma nova sessão SSH, sem encerrar a original, e confirme que o login por chave funciona corretamente.
2. Tente autenticar com senha e como root, confirmando que ambos os métodos foram efetivamente bloqueados, caso essa tenha sido a configuração aplicada.
3. Teste o fluxo completo de elevação de privilégios via sudo com a conta nominal usada pelos administradores.
4. Revise os logs de autenticação do sistema após a mudança, confirmando que não há erros inesperados relacionados ao serviço SSH.

Perguntas frequentes

Mudar a porta padrão do SSH é suficiente para proteger o servidor?

Não. Reduz o ruído de scanners automáticos genéricos, mas não substitui autenticação por chave, restrição de acesso por rede e monitoramento ativo de tentativas de conexão.

É seguro compartilhar uma mesma chave SSH entre vários administradores?

Não é recomendado. Cada administrador deveria ter seu próprio par de chaves, permitindo rastreabilidade individual e facilitando a revogação de acesso quando alguém deixa a equipe, sem impactar os demais.

Fail2ban substitui a necessidade de firewall?

Não. Fail2ban atua reativamente, bloqueando IPs depois de um número de tentativas falhas, enquanto o firewall age preventivamente, restringindo de antemão quem nem consegue tentar se conectar à porta do SSH.

Conclusão

Hardening de SSH é um processo cumulativo de pequenas decisões: autenticação por chave, restrição de usuários, redução de funcionalidades desnecessárias, controle de acesso por rede e auditoria periódica. Nenhuma dessas medidas, isoladamente, torna um servidor invulnerável, mas juntas reduzem bastante a superfície de ataque disponível para qualquer tentativa automatizada ou direcionada, e ainda evitam que você mesmo seja o próximo a ficar trancado do lado de fora.

Regra de ouro: nunca desabilite uma forma de autenticação sem antes validar completamente a alternativa em uma segunda sessão ativa.