Blindando o servidor SSH na VPS e EC2 contra bots

Você acabou de criar uma VPS ou uma instância EC2 na AWS. Ainda nem configurou direito o servidor e, pasme, já existem bots tentando invadir. Não é exagero. Em menos de 15 minutos após ligar uma máquina na nuvem, os primeiros acessos suspeitos começam a aparecer no log do SSH.

Bots varrem a internet o tempo todo. Eles testam combinações de root, ubuntu, admin, debian com senhas fracas na esperança de encontrar uma porta aberta e mal configurada. Se você criar uma instância Ubuntu na EC2, o nome de usuário padrão é ubuntu, e os bots sabem disso. Se for um Debian, tentam admin ou debian. Eles têm listas, e elas são enormes.

A boa notícia? Com 5 configurações básicas você reduz quase que totalmente o risco de acesso indevido. Vamos a elas.

As 5 camadas de proteção

1. Criar um usuário administrador: nunca use o usuário padrão da distro.
2. Autenticação por chave SSH: sem senha, sem risco de força bruta.
3. Desabilitar login como root: o alvo favorito dos bots.
4. Desabilitar login por senha: se não aceita senha, não adianta chutar.
5. Firewall + Fail2Ban: bloqueia quem insiste.

Antes de começar: EC2 × VPS

Se for EC2 (AWS): Quando você cria a instância EC2 na AWS já gera um par de chaves (pública/privada) no console ou via AWS CLI no momento da criação da instância. Você não precisa gerar uma nova chave, mas precisa pular a etapa de gerar e copiar a chave. As demais configurações (criar usuário, desabilitar root, firewall, fail2ban) ainda são necessárias.

Se for VPS: você vai precisar gerar a chave SSH manualmente, copiá-la para o servidor e configurar tudo do zero. O artigo cobre os dois cenários.

1. Atualizar o sistema

Sempre comece com o sistema atualizado. Pacotes desatualizados podem conter brechas conhecidas.

apt update
apt upgrade -y

2. Criar um usuário administrador

O nome de usuário padrão da sua distro (ubuntu, admin, debian etc.) é público. Os bots sabem qual é. Por isso a primeira coisa é criar um usuário só seu, com um nome que só você conhece.

adduser seu-usuario
usermod -aG sudo seu-usuario

Teste se o grupo sudo foi atribuído corretamente:

groups seu-usuario

Se aparecer sudo na lista, seu usuário tem privilégios administrativos. ✅

3. Gerar e configurar chave SSH

A chave SSH é como uma chave de casa: muito mais segura que uma senha. Enquanto senhas podem ser chutadas ou descobertas, a chave criptográfica é praticamente impossível de forjar.

🔹 Gerar a chave (Windows, Linux, macOS)

ssh-keygen -t ed25519 -C "seu-email@exemplo.com"

O comando acima cria um par de chaves usando o algoritmo Ed25519 (moderno, rápido e seguro). Você pode escolher onde salvar, o padrão ~/.ssh/id_ed25519 funciona bem.

Visualizar a chave pública (Linux e macOS)

cat ~/.ssh/id_ed25519.pub

Copie o texto que aparece. É a sua chave pública — pode compartilhá-la. A privada (id_ed25519 sem .pub) jamais deve sair da sua máquina.

Copiar a chave para o servidor (VPS)

Se for uma VPS comum, use o atalho:

ssh-copy-id -i ~/.ssh/nome-da-chave.pub seu-usuario@IP_DO_SERVIDOR

Esse comando instala sua chave pública no arquivo ~/.ssh/authorized_keys do servidor, e você já consegue conectar sem digitar senha.

Conectar ao servidor

ssh seu-usuario@IP_DO_SERVIDOR

Se tudo deu certo, você entra direto, sem pedir senha. 🎉

4. Endurecer a configuração do SSH

Agora vamos ajustar o coração da segurança: o arquivo de configuração do servidor SSH.

sudo nano /etc/ssh/sshd_config

Altere ou adicione as seguintes linhas:

# Desabilita login como root (os bots adoram tentar root)
PermitRootLogin no

# Permite autenticação por chave (é o que você acabou de configurar)
PubkeyAuthentication yes

# Desabilita login por senha (força bruta depende de senha)
PasswordAuthentication no

# Desabilita interação com senha (camada extra)
KbdInteractiveAuthentication no

# Opcional: alterar a porta SSH (fugir do padrão 22)
Port 2222

💡 Atenção para EC2 e VPS: em instâncias Ubuntu da AWS e VPS, existe o arquivo /etc/ssh/sshd_config.d/50-cloud-init.conf que sobrescreve as configurações do sshd_config. Você precisa editar também esse arquivo:

sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf

E adicionar:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

Depois de salvar, reinicie o serviço SSH:

sudo systemctl restart ssh

Pronto. A partir de agora, não é mais possível fazer login com root ou com senha. Só entra quem tem a chave privada correta.

5. Firewall com UFW

O UFW (Uncomplicated Firewall) é um firewall simples e direto. Vamos liberar apenas o essencial.

sudo apt install ufw -y

# Bloquear toda conexão que entra (ninguém de fora se conecta sem sua autorização)
sudo ufw default deny incoming

# Liberar toda conexão que sai (você pode baixar pacotes, acessar sites etc.)
sudo ufw default allow outgoing

# Liberar SSH (porta padrão 22)
sudo ufw allow 22/tcp

# Se você alterou a porta SSH, libere a nova porta substituindo pela 22

# Liberar HTTP e HTTPS (para sites e APIs)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Ativar o firewall
sudo ufw enable

Verifique as regras ativas:

sudo ufw status

O UFW agora funciona na seguinte lógica: tudo que chega do exterior é bloqueado por padrão, a menos que você explicitamente libere (como fez com SSH, HTTP e HTTPS). Já tudo que sai do servidor é permitido, você consegue fazer atualizações, acessar APIs, baixar pacotes, tudo normal.

É o princípio do menor privilégio aplicado à rede: nada de fora entra sem permissão, mas o servidor pode se comunicar livremente com o mundo.

6. Fail2Ban o segurança do SSH

O Fail2Ban monitora os logs do sistema e bloqueia temporariamente (por meio do firewall) IPs que fazem muitas tentativas de login com falha. É como um segurança na porta da balada: "já errou a senha 5 vezes? Pode ir embora."

sudo apt install fail2ban -y

# Habilitar para iniciar com o sistema
sudo systemctl enable fail2ban

# Iniciar agora
sudo systemctl start fail2ban

# Verificar se está rodando

sudo systemctl status fail2ban

7. (Bônus) Atualizações automáticas de segurança

Manter o sistema atualizado é fundamental. As atualizações automáticas instalam correções de segurança sem você precisar lembrar.

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure unattended-upgrades

Na tela que aparecer, selecione Sim.

Facilitando a conexão: o arquivo de configuração do SSH

Digitar ssh usuario@IP -p 2222 toda vez é chato. Crie um atalho no arquivo ~/.ssh/config da sua máquina local:

nano ~/.ssh/config

Adicione algo como:

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes

Host vps_ou_ec2
    HostName IP_DA_SUA_VPS
    User seu-usuario
    IdentityFile ~/.ssh/id_ed25519
    Port 2222
    ServerAliveInterval 60
    ServerAliveCountMax 3

Agora, para conectar, basta digitar:

ssh vps_ou_ec2

E para testar a conexão com GitHub:

ssh -T git@github.com

Se tudo estiver certo, o GitHub responde algo como:

Hi seu-usuario! You've successfully authenticated, but GitHub does not provide shell access.

Investigando: como ver quem está tentando entrar

Quer ver os bots em ação? Esses comandos mostram em tempo real as tentativas de acesso no seu servidor:

# Ver tentativas de login em tempo real
sudo tail -f /var/log/auth.log

# Ver bloqueios do Fail2Ban
sudo tail -f /var/log/fail2ban.log

# Status detalhado do Fail2Ban para o SSH
sudo fail2ban-client status sshd

O log do auth.log vai mostrar dezenas (ou centenas) de tentativas de login vindo de IPs do mundo inteiro. O fail2ban.log vai mostrar os IPs que foram bloqueados. É assustador e ao mesmo tempo satisfatório saber que o Fail2Ban está fazendo o trabalho dele.

Testando a blindagem

Depois de aplicar todas as configurações, é hora de confirmar que está tudo funcionando. O teste é simples: tente conectar sem usar a chave SSH.

Na sua máquina local, tente conectar como root:

ssh root@IP_DO_SERVIDOR

Você deve receber algo como:

root@IP_DO_SERVIDOR: Permission denied (publickey).

Agora tente com o usuário que você criou, também sem informar a chave:

ssh seu-usuario@IP_DO_SERVIDOR

O resultado é o mesmo:

seu-usuario@IP_DO_SERVIDOR: Permission denied (publickey).

✅ Isso é bom! A mensagem Permission denied (publickey) significa que o servidor rejeitou a conexão porque você não apresentou uma chave válida. O servidor nem sequer pediu senha, porque a autenticação por senha está desabilitada. Exatamente o que queremos.

Agora faça o teste com a chave para confirmar que o acesso legítimo continua funcionando:

ssh -i ~/.ssh/sua-chave.pub seu-usuario@IP_DO_SERVIDOR

Se entrou sem pedir nada, parabéns! 🎉 Sua VPS ou EC2 está blindada contra bots, força bruta e hackers metidos a cracker.

Recapitulando

Com esses passos, seu servidor passa de "porta escancarada" para "cofre blindado". Veja o resumo:

Configuração	Protege contra
Usuário personalizado	Bots que tentam nomes de usuário padrão
Chave SSH	Força bruta de senha
Root desabilitado	Ataques direcionados ao root
Senha desabilitada	Qualquer ataque baseado em senha
UFW + Fail2Ban	Varreduras e múltiplas tentativas

Considerações finais

Configurar segurança no SSH não é frescura, é responsabilidade de quem coloca um servidor na internet. Os bots não dormem. Enquanto você lê este artigo, centenas de scripts automatizados estão escaneando IPs atrás de uma porta 22 aberta com PermitRootLogin yes e senha fraca.

Gaste 15 minutos aplicando essas configurações. Sua VPS/EC2 com seus dados, agradecem.

Feito!