SSH Hardening: boas práticas para acesso administrativo seguro
SSH exposto é o alvo número um de força bruta. Veja como endurecer o acesso administrativo de forma prática.
O SSH é a principal porta de administração de servidores Linux e, por isso, um dos alvos mais visados. Qualquer endereço com a porta SSH aberta na internet recebe tentativas de força bruta continuamente. A boa notícia é que o hardening do SSH é direto e de alto impacto: poucas mudanças de configuração eliminam os ataques mais comuns e reduzem drasticamente o risco de comprometimento por essa via.
Este guia apresenta um conjunto prático de boas práticas de SSH hardening, com foco defensivo. O objetivo é tornar o acesso administrativo seguro sem inviabilizar a operação, usando autenticação forte, restrição de acesso e visibilidade.
Autenticação por chave e sem root
A mudança de maior impacto é desativar a autenticação por senha e usar apenas chaves. Chaves eliminam a força bruta de senha, que é o ataque dominante contra SSH exposto. Em paralelo, desabilite o login direto de root: o acesso deve ser feito por um usuário individual que eleva privilégio via sudo, preservando a rastreabilidade de quem fez o quê.
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy adminA diretiva AllowUsers restringe explicitamente quem pode entrar por SSH, reduzindo a superfície a um conjunto conhecido de contas. Proteja as chaves privadas com senha e remova chaves que não são mais necessárias.
Exposição, bastion e MFA
Sempre que possível, não exponha o SSH diretamente à internet. Um bastion host, ou um mecanismo como o Session Manager em ambientes AWS, concentra e controla o acesso administrativo, deixando os servidores internos sem porta SSH aberta para o mundo. Onde a exposição for inevitável, restrinja por origem e considere MFA para o acesso, adicionando um segundo fator ao login.
- Desabilitar senha e usar apenas chaves
- Desabilitar login direto de root
- Restringir contas com AllowUsers
- Evitar expor SSH diretamente; usar bastion ou Session Manager
- Restringir por origem quando a exposição for inevitável
- Considerar MFA no acesso administrativo
Logs e proteção contra força bruta
Centralize os logs de autenticação em um destino remoto, para que um host comprometido não permita apagar os próprios rastros. Ferramentas como fail2ban bloqueiam origens com muitas tentativas falhas, reduzindo o ruído de força bruta mesmo com autenticação por chave. Monitore logins bem-sucedidos de origens incomuns e horários atípicos, que podem indicar credencial comprometida.
Checklist prático
- Desabilitar autenticação por senha e usar apenas chaves
- Desabilitar login direto de root
- Restringir contas de acesso com AllowUsers
- Proteger chaves privadas com senha
- Remover chaves que não são mais necessárias
- Evitar expor SSH diretamente; usar bastion ou Session Manager
- Restringir por origem quando exposto
- Considerar MFA no acesso administrativo
- Centralizar logs de autenticação em destino remoto
- Usar fail2ban e monitorar logins anômalos
Boas práticas
- Prefira chaves a senha, sempre
- Concentre o acesso em bastion para evitar exposição direta
- Restrinja explicitamente quem pode entrar por SSH
- Preserve evidência centralizando logs de autenticação
- Adicione MFA onde o acesso for sensível
- Padronize o hardening para novos servidores
Erros comuns
SSH com senha habilitada
Alvo direto de força bruta, o ataque mais comum contra SSH.
Login direto de root permitido
Comprometimento com privilégio máximo e sem rastreabilidade.
SSH exposto diretamente à internet
Sondagem e ataque contínuos sem necessidade.
Logs apenas locais
Host comprometido permite apagar a própria trilha.
Chaves antigas nunca removidas
Acessos esquecidos permanecem válidos indefinidamente.
Quando procurar apoio especializado
Padronizar acesso administrativo seguro e eliminar exposição de SSH na frota é parte do serviço de Hardening da GUARDIASEC, que define baselines e valida as mudanças sem quebrar a operação.
Perguntas frequentes
Chave SSH é mesmo melhor que senha?
Sim, de forma significativa. Chaves eliminam a força bruta de senha, que é o ataque dominante contra SSH exposto, e são muito mais difíceis de adivinhar. O cuidado passa a ser proteger a chave privada com senha e controlar quais chaves têm acesso, removendo as que não são mais necessárias. Desativar a senha e usar apenas chaves é o passo de maior impacto.
Por que desabilitar o login de root?
Porque o login direto de root concede o privilégio máximo logo na entrada e elimina a rastreabilidade, já que todos entram como o mesmo usuário. O recomendado é cada pessoa acessar com a própria conta e elevar via sudo, que registra a ação. Assim, um comprometimento fica limitado àquela conta e há registro de quem fez o quê.
Preciso expor SSH para administrar servidores?
Não. Em ambientes AWS, o Session Manager permite acesso de shell sem abrir porta de entrada. Em outros cenários, um bastion host controlado concentra o acesso e mantém os servidores internos sem SSH exposto. Evitar a exposição direta elimina o alvo mais visado por varredura e força bruta, sem perder a capacidade de administrar.
fail2ban substitui a autenticação por chave?
Não, eles se complementam. A autenticação por chave elimina a força bruta de senha, e o fail2ban reduz o ruído bloqueando origens com muitas tentativas falhas. Mesmo com chaves, o fail2ban diminui a carga de sondagem e ajuda a conter abuso. Usá-los juntos é melhor do que depender de apenas um.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.