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 bastante o risco de comprometimento por essa via.
Este guia apresenta um conjunto prático de boas práticas de SSH hardening, com foco defensivo. Vai além do trio conhecido de chave, sem root e sem exposição: trata do endurecimento do próprio daemon, da escolha de algoritmos criptográficos, do ciclo de vida das chaves e da diferença entre reduzir o ruído de sondagem e realmente conter um acesso indevido. 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.
Tipo de chave e proteção da chave privada
Prefira chaves ed25519, que são curtas, rápidas e resistentes, ou RSA de 4096 bits quando houver exigência de compatibilidade com sistemas antigos. Evite chaves RSA menores que 2048 bits e chaves DSA, hoje desaconselhadas. A chave privada deve ter passphrase e ficar guardada apenas no dispositivo do operador, nunca em repositório, imagem de contêiner ou pasta compartilhada. Um agente SSH mantém a chave carregada durante a sessão sem gravar a passphrase em disco, o que equilibra segurança e praticidade.
Trate cada chave pública em authorized_keys como uma concessão de acesso que precisa de dono e justificativa. Uma chave sem dono conhecido é um acesso a remover, não a manter por precaução. Onde a frota é grande, o gerenciamento de authorized_keys por configuração declarativa evita chaves órfãs acumuladas em servidores esquecidos.
Endurecendo o daemon e a criptografia
Autenticação forte resolve a maior parte do risco, mas o próprio sshd tem opções que reduzem a superfície e o custo de sondagem. Limitar tentativas por conexão, encerrar sessões ociosas e desabilitar recursos que você não usa fecha caminhos secundários que atacantes exploram depois de já terem um pé dentro.
# Reduz janela e custo de força bruta
MaxAuthTries 3
LoginGraceTime 20
MaxSessions 4
# Encerra sessões ociosas e conexões mortas
ClientAliveInterval 300
ClientAliveCountMax 2
# Desabilita recursos que ampliam a superfície
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel noAjuste o encaminhamento conforme o uso real: se ninguém precisa de X11 ou de túnel TCP, desabilitar remove um vetor de abuso. Onde o encaminhamento de porta for necessário para um fluxo específico, prefira liberá-lo por usuário com um bloco Match em vez de deixá-lo aberto para todos.
Algoritmos e higiene de versão
Restringir os algoritmos de troca de chaves, cifras e MACs a um conjunto moderno impede a negociação de primitivas fracas. As versões atuais do OpenSSH já trazem padrões sensatos, então a definição explícita é mais relevante em sistemas antigos ou sob requisito de conformidade. Manter o pacote do OpenSSH atualizado é parte do hardening: falhas no próprio servidor aparecem e são corrigidas com o tempo, e uma versão defasada anula boa parte do esforço de configuração.
KexAlgorithms curve25519-sha256,[email protected]
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]Valide qualquer mudança em uma sessão paralela antes de encerrar a atual. Um sshd -t confirma a sintaxe, e manter uma conexão aberta enquanto reinicia o serviço evita o cenário clássico de se trancar para fora do próprio servidor por um erro de configuração.
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.
O que observar nos registros
A força bruta de senha faz barulho e é fácil de bloquear, mas com autenticação por chave o sinal que importa muda. Passa a valer mais acompanhar quem entrou com sucesso, de qual origem e em qual horário, e cruzar com o comportamento esperado de cada conta. Um login legítimo de uma chave conhecida a partir de um endereço e de um horário incomuns é o tipo de evento que merece atenção, porque pode indicar chave privada comprometida.
- Logins bem-sucedidos de origens ou horários fora do padrão da conta
- Uso de contas de serviço em sessões interativas inesperadas
- Alterações em authorized_keys e em arquivos de configuração do sshd
- Escalonamento via sudo logo após um login incomum
- Volume anômalo de conexões aceitas de uma mesma origem
Bloqueio de força bruta reduz o ruído; a detecção de acesso indevido depende de olhar os logins que deram certo. Encaminhe esses eventos para o mesmo destino que recebe o restante da telemetria de segurança, para que a atividade de SSH seja correlacionada com o resto do ambiente em vez de ficar isolada em cada host.
SSH em escala: certificados e alternativas à chave estática
authorized_keys funciona bem em poucos servidores, mas em uma frota grande as chaves se espalham, envelhecem e viram acesso órfão difícil de rastrear. Duas abordagens reduzem esse problema. A primeira é o certificado SSH: uma autoridade certificadora interna assina certificados de curta duração para os usuários, e os servidores confiam na CA em vez de listar chave por chave. O acesso passa a expirar sozinho, e revogar alguém é deixar de renovar o certificado, não caçar a chave em cada host.
# Em /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/user_ca.pub
# Certificados de curta duração expiram sozinhos,
# eliminando authorized_keys espalhadas pela frota.A segunda abordagem é remover a chave estática do fluxo humano com acesso intermediado, como o Session Manager em ambientes AWS ou um broker de acesso que emite credencial temporária e registra a sessão. Em ambos os casos, o ganho é o mesmo: acesso que expira por padrão, revogação em um ponto central e uma trilha de quem acessou o quê, sem depender de disciplina manual para limpar chaves antigas.
Checklist prático
- Desabilitar autenticação por senha e usar apenas chaves
- Desabilitar login direto de root
- Restringir contas de acesso com AllowUsers
- Preferir chaves ed25519 ou RSA de 4096 bits
- Proteger chaves privadas com passphrase e usar agente SSH
- Remover chaves que não são mais necessárias
- Reduzir MaxAuthTries e LoginGraceTime no sshd
- Encerrar sessões ociosas com ClientAlive e limitar sessões
- Desabilitar encaminhamento de agente, TCP e X11 quando não usados
- Restringir algoritmos a um conjunto moderno e manter o OpenSSH atualizado
- Validar mudanças com sshd -t em sessão paralela
- 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 bem-sucedidos anômalos
- Avaliar certificados SSH ou acesso intermediado em frotas grandes
Boas práticas
- Prefira chaves a senha, sempre
- Endureça o daemon além da autenticação, com limites e menos recursos ligados
- Mantenha o OpenSSH atualizado, pois configuração não cobre falha de versão
- Concentre o acesso em bastion para evitar exposição direta
- Restrinja explicitamente quem pode entrar por SSH
- Trate cada chave pública como concessão com dono e justificativa
- Preserve evidência centralizando logs de autenticação
- Monitore logins bem-sucedidos, não apenas tentativas falhas
- Adicione MFA onde o acesso for sensível
- Prefira acesso que expira, com certificados ou broker, em frotas grandes
- 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.
Encaminhamento de agente e de porta ligado sem uso
Amplia a superfície e facilita pivotar a partir de um host comprometido.
OpenSSH desatualizado
Uma falha no próprio servidor anula boa parte do hardening de configuração.
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.
Mudar a porta padrão do SSH aumenta a segurança?
Só um pouco, e não substitui os controles que importam. Rodar o SSH em uma porta diferente da 22 reduz o volume de sondagem automatizada, o que limpa os logs, mas não detém quem faz uma varredura de portas mais completa. É uma medida cosmética de redução de ruído, útil como camada extra, jamais como proteção principal. O ganho real vem de desabilitar senha, bloquear login de root, restringir contas e evitar a exposição direta.
Qual tipo de chave SSH devo usar hoje?
Ed25519 é a escolha recomendada na maioria dos casos: gera chaves curtas, é rápida e tem boa margem de segurança. RSA de 4096 bits continua válido quando há necessidade de compatibilidade com sistemas mais antigos que ainda não suportam ed25519. Evite RSA abaixo de 2048 bits e chaves DSA, hoje desaconselhadas. Em qualquer caso, proteja a chave privada com passphrase e mantenha o software SSH atualizado.
Como evito acumular chaves órfãs na frota de servidores?
Trate cada chave pública como uma concessão de acesso com dono conhecido, e não como algo permanente. Em poucos servidores, revise authorized_keys periodicamente e remova o que não tem dono. Em frotas grandes, o caminho mais sustentável é gerenciar as chaves por configuração declarativa ou adotar certificados SSH de curta duração, que expiram sozinhos. Assim a revogação vira deixar de renovar, em vez de caçar a chave em cada host.
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.