Hardening de SSH: checklist para blindar seu servidor Linux

Você acabou de subir um servidor Linux. Instalou o OpenSSH, liberou a porta 22 no firewall e testou a conexão. Funcionou. Você fecha o terminal satisfeito.

Quarenta e cinco minutos depois, seu arquivo /var/log/auth.log tem mil linhas de tentativas de login que você não fez.

Isso não é exagero. É o que acontece com qualquer IP público com a porta 22 aberta. Bots varrendo a internet inteira são baratos e automatizados. A questão não é "se" vão tentar entrar. A questão é "quando" conseguem.

Este guia cobre o checklist completo para blindar o SSH no seu servidor Linux sem precisar ser especialista em segurança. Os comandos funcionam no Ubuntu, Debian, Linux Mint e derivados.

Por que o SSH é o alvo favorito dos bots

O SSH (Secure Shell) é o protocolo que permite acessar seu servidor remotamente pelo terminal. É essencial para qualquer pessoa que roda um homelab, VPS, servidor de jogos ou qualquer coisa em Linux.

A porta padrão do SSH é a 22. Todo bot, scanner e ferramenta de ataque conhece isso. É o equivalente a deixar a chave debaixo do capacho: tecnicamente funciona, mas é o primeiro lugar que todo mundo olha.

Se você já leu nosso post sobre como resolver o erro xterm-kitty no SSH, sabe que o SSH é uma ferramenta do dia a dia de quem trabalha com Linux. Agora vamos garantir que ela seja também uma ferramenta segura.

Antes de começar: faça backup da sua sessão

Regra de ouro: nunca feche a sessão SSH atual antes de testar as alterações em uma nova janela.

Se você cometer um erro na configuração e perder o acesso, você vai precisar de acesso físico ao servidor (ou ao console VPS do seu provedor) para corrigir.

Abra duas janelas de terminal. Mantenha a sessão atual aberta durante todo o processo.

Passo 1: Atualize tudo antes de começar

sudo apt update && sudo apt upgrade -y

Vulnerabilidades corrigidas em versões antigas do OpenSSH são uma das formas mais comuns de invasão. Comece com o sistema atualizado.

Passo 2: Troque a porta padrão 22

O arquivo de configuração do SSH fica em /etc/ssh/sshd_config. Vamos editar ele:

sudo nano /etc/ssh/sshd_config

Encontre a linha:

#Port 22

Descomente e mude para qualquer número entre 1024 e 65535 que você preferir (ex: 2222, 4522, 7743):

Port 4522

Isso não é segurança por obscuridade completa, mas elimina a maioria dos scanners de baixa qualidade que só tentam a porta 22. Na prática, reduz o volume de tentativas em mais de 90%.

Se você usa UFW (firewall padrão do Ubuntu), atualize a regra:

sudo ufw allow 4522/tcp
sudo ufw delete allow 22/tcp

Passo 3: Desabilite o login do root

O usuário root existe em todos os servidores Linux. É o primeiro usuário que bots tentam. Proibir o login direto como root força qualquer atacante a primeiro descobrir um nome de usuário válido, o que já é uma barreira enorme.

No sshd_config, encontre e configure:

PermitRootLogin no

A partir de agora, mesmo que alguém descubra a senha do root, não consegue entrar via SSH com esse usuário.

Passo 4: Use chave SSH em vez de senha

Essa é a mudança mais importante do checklist. Senhas podem ser adivinhadas por força bruta. Chaves SSH, não.

No seu computador local, gere um par de chaves:

ssh-keygen -t ed25519 -C "[email protected]"

O algoritmo ed25519 é moderno, seguro e gera chaves menores que o RSA clássico. Salve no caminho padrão e defina uma passphrase (opcional, mas recomendado).

Copie a chave pública para o servidor:

ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 4522 usuario@ip-do-servidor

Teste a conexão com a chave antes de continuar:

ssh -i ~/.ssh/id_ed25519 -p 4522 usuario@ip-do-servidor

Funcionou? Agora desabilite o login por senha no servidor, no sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes

A partir de agora, só quem tem a chave privada pode entrar. Brute force de senha vira irrelevante.

Passo 5: Restrinja quais usuários podem usar SSH

Adicione ao final do sshd_config:

AllowUsers seu_usuario_aqui

Mesmo que um atacante descubra ou crie outro usuário no sistema, ele não conseguirá fazer login via SSH.

Passo 6: Configure timeouts de conexão

Adicione ou ajuste essas linhas no sshd_config:

ClientAliveInterval 300
ClientAliveCountMax 2
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 5

O que cada uma faz:

• ClientAliveInterval 300: envia um sinal a cada 5 minutos para checar se o cliente ainda está conectado
• ClientAliveCountMax 2: fecha a conexão se o cliente não responder 2 vezes
• LoginGraceTime 30: dá 30 segundos para autenticar antes de fechar a tentativa
• MaxAuthTries 3: máximo de 3 tentativas de autenticação por conexão
• MaxSessions 5: limita o número de sessões abertas simultaneamente

Passo 7: Instale o Fail2Ban

O Fail2Ban monitora os logs do sistema e bane automaticamente IPs que fazem muitas tentativas de login falhas. É a camada de defesa ativa.

sudo apt install fail2ban -y

Crie um arquivo de configuração local (o arquivo .local sobrescreve o padrão sem risco de perder as configs na atualização):

sudo nano /etc/fail2ban/jail.local

Cole o seguinte:

[sshd]
enabled = true
port = 4522
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

Isso bane por 1 hora qualquer IP que errar a autenticação 3 vezes em 10 minutos. Ative e inicie o serviço:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Para checar IPs banidos:

sudo fail2ban-client status sshd

Passo 8: Aplique as configurações e reinicie o SSH

Depois de salvar o sshd_config, teste a sintaxe antes de reiniciar:

sudo sshd -t

Se não aparecer nenhum erro, reinicie o serviço:

sudo systemctl restart sshd

Com a sessão atual ainda aberta, abra uma nova janela de terminal e teste a conexão com as novas configurações (nova porta, nova chave). Só feche a sessão antiga depois de confirmar que funciona.

Checklist rápido para revisar

Próximos passos opcionais

Se você quer ir além do essencial, considere:

2FA no SSH: Adicionar autenticação de dois fatores com o libpam-google-authenticator cria uma segunda camada mesmo para quem tem a chave privada.

Port Knocking: Técnica que mantém a porta SSH invisível até que uma sequência específica de conexões seja feita em outras portas. Complexo de configurar, mas eficaz.

Wireguard ou Tailscale: A solução mais radical é não expor o SSH diretamente para a internet. Usando uma VPN como o Tailscale, o SSH fica disponível apenas dentro da sua rede privada virtual, invisível para qualquer scanner externo.

Conclusão

Segurança não é um produto que você compra e instala. É uma série de decisões que você toma, cada uma fechando uma janela que um atacante poderia usar.

Os passos acima não tornam seu servidor impenetrável (nada torna). Mas eles eliminam as categorias de ataque mais comuns e automatizadas, que respondem pela esmagadora maioria das invasões bem-sucedidas em servidores domésticos e VPS.

Se você roda um homelab ou um servidor de jogos, aplique esse checklist hoje. Seus logs vão agradecer.

Se você ainda está no começo da jornada com Linux e servidores, veja também nosso guia sobre o que é self-host e por que você deveria se importar para entender o ecossistema maior em que o SSH se encaixa.

Fontes:

• Erro ao usar SSH: xterm-kitty (Flateek)
• O que é Tailscale (Flateek)
• O que é Self-Host (Flateek)

Gostou? Assine a newsletter do Flateek para receber os próximos artigos direto no seu e-mail.