SSH seguro: chaves, desabilitar root e boas práticas

Se existe uma coisa para proteger primeiro numa VPS, é o SSH. É por ele que você administra o servidor — e é o primeiro lugar onde os bots batem, testando milhares de senhas por hora. Trocar a autenticação por senha por chave e fechar algumas brechas elimina praticamente toda a força bruta. Veja como.

Por que senha é frágil e chave não

Uma senha, por mais forte que seja, pode ser adivinhada por tentativa e erro — e os bots tentam sem parar. Uma chave SSH é um par criptográfico: uma parte privada que fica só com você e uma pública que fica no servidor. Sem a chave privada, não há login — e ela é praticamente impossível de adivinhar. É a diferença entre uma tranca comum e um cofre.

Passo 1: gere seu par de chaves

Na sua máquina (não no servidor), gere a chave:

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

O tipo ed25519 é moderno, rápido e seguro. Isso cria dois arquivos: a chave privada (guarde bem, nunca compartilhe) e a pública (.pub, essa vai pro servidor). Proteja a chave com uma passphrase — assim, mesmo que roubem o arquivo, ele é inútil sem a frase.

Passo 2: instale a chave pública no servidor

O jeito mais fácil:

ssh-copy-id usuario@ip-do-servidor

Isso adiciona sua chave pública ao ~/.ssh/authorized_keys do servidor. A partir daí, você entra sem digitar senha — a chave faz o trabalho. Teste o login por chave antes de seguir para o próximo passo.

Passo 3: endureça o sshd_config

Com a chave funcionando, ajuste /etc/ssh/sshd_config para fechar as brechas:

# Desabilita login do root direto
PermitRootLogin no

# Desabilita autenticação por senha (só chave)
PasswordAuthentication no
PubkeyAuthentication yes

# Desabilita autenticacao vazia e por teclado interativo
PermitEmptyPasswords no

Depois recarregue o SSH:

sudo systemctl restart sshd

⚠️ Cuidado: só desabilite a senha depois de confirmar que o login por chave funciona — senão você se tranca para fora. Mantenha uma sessão aberta enquanto testa uma nova em outra janela.

Passo 4 (opcional): mude a porta padrão

O SSH escuta na porta 22 por padrão, onde 100% dos bots batem. Mudar para outra porta (ex.: 2222) não é segurança de verdade — é redução de ruído: some com a enxurrada de tentativas automáticas nos logs. Faça se quiser logs mais limpos, mas nunca em vez das chaves.

Port 2222

Se usar firewall (e você deve), lembre de liberar a nova porta antes de reiniciar o SSH. Veja firewall no Linux.

Boas práticas extras

• Um usuário com sudo, não o root, para o dia a dia.
• Passphrase na chave privada — protege se o arquivo vazar.
• Uma chave por dispositivo — fica fácil revogar uma sem afetar as outras.
• Fail2ban por cima, para banir quem insistir mesmo na porta certa. Veja fail2ban.
• Nunca compartilhe a chave privada nem a coloque em repositório de código.

O resultado

Com SSH por chave + root desabilitado + senha desligada, os ataques de força bruta simplesmente param de funcionar — o bot pode tentar para sempre que nunca entra. É a maior redução de risco por minuto investido em toda a segurança de um servidor.

Uma base com acesso root de verdade

Para fazer esse hardening você precisa de root — o que só uma VPS oferece. A VittHost entrega VPS com root e IP dedicado, no Brasil e no Canadá, para você configurar o SSH do seu jeito:

👉 Ver planos de VPS

Próximo passo da blindagem: o firewall.