Se você contratar hoje um servidor VPS (em provedores como Contabo, Hetzner, DigitalOcean ou Linode) com um sistema Linux recém-instalado e verificar o arquivo de log de autenticação (/var/log/auth.log no Debian/Ubuntu ou journalctl -u ssh), verá um espetáculo perturbador: em questão de minutos após a ativação do IP público, milhares de requisições de força bruta vindas de botnets do mundo inteiro começarão a bombardear a sua porta 22 tentando adivinhar senhas comuns.
O SSH (Secure Shell) é a chave mestra de administração de qualquer servidor Linux. Permitir que ele opere com configurações frouxas — como aceitar senhas simples, permitir login direto como superusuário root ou usar cifras de criptografia defasadas — é o convite perfeito para um comprometimento total da sua infraestrutura.
Neste checklist técnico avançado, você aprenderá os 7 passos essenciais de hardening para transformar o serviço SSH do seu servidor em uma fortaleza impenetrável contra ataques automatizados e explorações avançadas.
Regra de Ouro Antes de Começar: Mantenha Sempre uma Sessão Aberta!
Aviso Crítico: Antes de alterar qualquer parâmetro do arquivo de configuração do SSH, abra duas janelas de terminal conectadas ao servidor. Faça as alterações em uma janela e NUNCA feche a segunda janela até ter testado e comprovado que uma nova conexão foi estabelecida com sucesso. Isso garante que você não ficará trancado fora da máquina se cometer algum erro de digitação.
Passo 1: Gerar e Adotar Chaves Criptográficas Ed25519
O primeiro mandamento do sysadmin moderno é eliminar completamente as senhas em prol de chaves públicas/privadas. E em 2026, você não deve mais criar chaves RSA 2048: o padrão ouro da indústria é o algoritmo de curva elíptica Ed25519, que oferece maior segurança matemática, imunidade a ataques de canal lateral e tamanho de chave minúsculo.
No seu computador pessoal (cliente), gere um novo par de chaves Ed25519:
ssh-keygen -t ed25519 -a 100 -C "admin@meu-servidor"Defina uma frase-passe (passphrase) forte para proteger a sua chave privada local. Em seguida, copie a chave pública para o seu servidor remoto com o utilitário ssh-copy-id:
ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@IP_DO_SERVIDORPasso 2: Criar um Usuário com Privilégios Sudo e Banir o Login Root
Permitir que o usuário root autentique diretamente via SSH é perigoso porque o nome “root” é conhecido por qualquer invasor, facilitando ataques direcionados. Você deve utilizar um usuário padrão com privilégios de sudo.
Se ainda não tiver um usuário administrativo pessoal no servidor, crie-o agora:
sudo adduser adminuser
sudo usermod -aG sudo adminuserPasso 3: Blindar as Diretivas Principais do `sshd_config`
Em distribuições Linux modernas, as configurações modulares devem ser criadas dentro do diretório /etc/ssh/sshd_config.d/. Crie um arquivo dedicado como /etc/ssh/sshd_config.d/99-hardening.conf:
# 1. Proibir o login direto do superusuário root
PermitRootLogin no
# 2. Desativar completamente a autenticação por senha
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
# 3. Forçar apenas autenticação por chave pública
PubkeyAuthentication yes
# 4. Proibir senhas em branco e logins vazios
PermitEmptyPasswords no
# 5. Limitar o número máximo de tentativas de autenticação antes de desconectar
MaxAuthTries 3
# 6. Desconectar sessões inativas automaticamente (5 minutos)
ClientAliveInterval 300
ClientAliveCountMax 2
# 7. Desativar encaminhamento desnecessário de interface gráfica (X11)
X11Forwarding no
# 8. Permitir apenas o protocolo 2 do SSH
# (Padrão em distros recentes)Passo 4: Restringir Quais Usuários Podem Fazer Login (`AllowUsers`)
Se o seu servidor possui contas de serviços internos (como www-data, nginx, mysql ou redis), um invasor não deve conseguir abrir uma sessão shell mesmo que comprometa uma aplicação web. Adicione ao final do seu arquivo de configuração a diretiva AllowUsers:
AllowUsers adminuserDessa forma, o OpenSSH recusará conexões de qualquer outro nome de usuário que não esteja explicitamente listado nessa diretiva.
Passo 5: Alterar a Porta Padrão do SSH (Segurança por Obscuridade Eficaz)
Embora mudar a porta não corrija falhas estruturais, alterar a porta padrão de 22 para uma porta alta (como 2222 ou outra acima de 1024) reduz em mais de 95% o volume de logs inúteis gerados por bots automatizados que varrem a internet de ponta a ponta procurando exclusivamente pela porta 22.
No arquivo /etc/ssh/sshd_config.d/99-hardening.conf, defina:
Port 2222Importante: Lembre-se de liberar a nova porta no seu firewall (ex: sudo ufw allow 2222/tcp) antes de recarregar o SSH!
Passo 6: Implementar Autenticação em Dois Fatores (2FA via TOTP)
Para servidores com dados sensíveis, a camada máxima de defesa é exigir autenticação multifator: para entrar, o sysadmin precisa da chave Ed25519 E de um código numérico de 6 dígitos gerado pelo Google Authenticator ou Bitwarden no celular.
sudo apt install libpam-google-authenticator -y
google-authenticatorO comando exibirá um QR Code no terminal. Escaneie no aplicativo do seu smartphone e guarde os códigos de backup (scratch codes) em local seguro offline.
Passo 7: Testar a Sintaxe e Recarregar o Serviço
Antes de aplicar as alterações, execute o teste de sintaxe do OpenSSH:
sudo sshd -tSe o comando não retornar nenhuma saída, a sintaxe está perfeita! Recarregue o serviço com:
sudo systemctl reload sshEm uma nova janela do terminal do seu computador, teste a conexão apontando para a nova porta e chave:
ssh -p 2222 -i ~/.ssh/id_ed25519 adminuser@IP_DO_SERVIDORConclusão
Com chaves Ed25519 ativas, senhas e root desativados, limites de tentativas e auditoria estrita de usuários autorizados, o seu servidor Linux atinge o nível máximo de proteção da indústria contra invasões e sequestro de instâncias em nuvem.