---
title: "Proteger servidor Linux contra brute force em SSH"
description: "Defesa prática contra brute force SSH: fail2ban, chaves ED25519, UFW, hardening do sshd_config e operação segura em VPS e servidores dedicados no Brasil."
url: "https://streethosting.com.br/guias/infraestrutura/proteger-servidor-linux-ssh-brute-force"
category: "infraestrutura"
slug: "proteger-servidor-linux-ssh-brute-force"
datePublished: "2026-06-11"
dateModified: "2026-06-11"
author: "Equipe StreetHosting"
difficulty: "intermediario"
language: "pt-BR"
keywords:
  - "proteger ssh brute force"
  - "fail2ban linux"
  - "ssh seguro servidor"
  - "hardening ssh linux"
---

# Proteger servidor Linux contra brute force em SSH

Minutos após publicar um IP, bots começam a testar root e senhas vazadas no SSH. Este guia mostra camadas de defesa que funcionam em produção sem trancar sua equipe fora do servidor.

> **Resposta rápida**
>
> Para **proteger Linux contra brute force SSH** use chave **ED25519**, desative login por senha no `sshd_config`, proíba root direto, configure **fail2ban** com limites conservadores e firewall coerente. Valide login em segunda sessão antes de fechar acesso atual. Teste console de recuperação do provedor antes de precisar dele.

## O que é brute force em SSH

Brute force em SSH é tentativa automatizada de adivinhar usuário e senha até acertar combinação fraca ou reutilizada. Não exige alvo famoso: qualquer VPS com porta 22 exposta entra em listas globais em poucos minutos. Ataque gera ruído em log, consome CPU do sshd e pode anteceder exploração se senha for fraca.

Objetivo da defesa não é zero tentativas, é tornar sucesso estatisticamente improvável e detectar padrão cedo. Quem hospeda jogo em [VPS Ryzen](https://streethosting.com.br/vps/ryzen) ou [servidor dedicado](https://streethosting.com.br/dedicated) expõe IP público por necessidade: jogadores precisam conectar. SSH bem endurecido evita que comprometimento do shell vire perda do mundo ou bot Discord.

- Atacante usa listas de usuário e senha vazadas da internet.
- Bots não dormem: varredura é contínua e distribuída.
- Sucesso inicial abre porta para minerador, ransomware ou pivot interno.

## Sinais de ataque nos logs

Sinais claros aparecem em `/var/log/auth.log` ou `journalctl -u ssh`: dezenas de Failed password para root, admin, ubuntu e test em sequência rápida. Invalid user indica dicionário de nomes comuns. Múltiplos IPs diferentes no mesmo minuto sugerem botnet. Pico noturno é normal em VPS BR porque scanners não respeitam fuso.

| Linha típica | Interpretação | Ação |
| --- | --- | --- |
| Failed password for root | Bot testando superusuário | Confirmar PermitRootLogin no |
| Invalid user oracle | Dicionário de serviços | Ruído esperado, monitorar volume |
| Accepted password for deploy | Login senha bem sucedido | Investigar imediatamente se senha deveria estar off |
| Disconnected authenticating user | Tentativa interrompida | Correlacionar com fail2ban ban |

> **Dica**
>
> Configure alerta quando contagem de falhas SSH ultrapassar limiar por hora. Uptime Kuma ou script simples com grep evita descobrir campanha dias depois.

## Camadas de defesa práticas

Primeira camada: autenticação por chave ED25519 e PasswordAuthentication no. Segunda: PermitRootLogin no e AllowUsers com lista mínima. Terceira: fail2ban ou sshguard banindo IP após N falhas. Quarta: UFW permitindo SSH só de faixas conhecidas quando equipe tem IP fixo.

1. Gere chave local: ssh-keygen -t ed25519 -a 100
2. Copie para servidor: ssh-copy-id usuario@ip
3. Abra segunda sessão SSH e confirme login por chave.
4. Edite sshd_config, valide sshd -t, systemctl reload sshd.
5. Só então desconecte sessão antiga e teste novamente.

> **Atenção**
>
> Nunca desative senha nem reinicie sshd sem sessão paralela aberta. Erro de sintaxe ou chave errada tranca equipe inteira até console de recuperação.

Fluxo completo de chaves e sshd está no guia de [SSH seguro em VPS Linux](https://streethosting.com.br/guias/vps/ssh-seguro-vps-linux). Siga ordem de etapas de lá se for primeira configuração.

## fail2ban, UFW e hardening

fail2ban lê log do sshd, conta falhas em janela findtime e aplica ban por bantime via iptables ou nftables. Configuração conservadora para equipe remota: maxretry 5, findtime 600, bantime 3600. Whitelist IP do escritório evita lockout em NAT compartilhado com cuidado. Sempre teste jail.local antes de reiniciar produção.

### Exemplo de jail.local enxuto

Seção sshd com enabled true, port ssh, filter sshd, logpath apontando para auth.log, maxretry 5 e bantime 1h. Após editar, use fail2ban-client reload e fail2ban-client status sshd para confirmar jail ativo.

Combine com [firewall UFW em VPS Ubuntu](https://streethosting.com.br/guias/vps/firewall-ufw-vps-ubuntu): default deny incoming, allow 22/tcp ou porta customizada documentada, allow portas do jogo explicitamente. Docker publicado exige revisão extra porque pode contornar UFW; veja [instalar Docker em VPS](https://streethosting.com.br/guias/vps/instalar-docker-ubuntu-vps) para integração segura.

- [ ] PasswordAuthentication no após validar chave.
- [ ] PermitRootLogin no ou prohibit-password se root excepcional.
- [ ] AllowUsers lista explícita de contas humanas.
- [ ] fail2ban instalado e habilitado no boot.
- [ ] UFW ativo com regra mínima documentada.

## Operação contínua em VPS e dedicado

Mudar porta SSH reduz ruído de bot simples mas não substitui chave forte. Console de recuperação do provedor é rede de segurança quando algo dá errado. Em servidor dedicado ou VPS exposta a internet, rotina trimestral revisa authorized_keys, remove chaves de ex funcionário e confirma que PasswordAuthentication permanece desligado após upgrade do sistema.

Compare planos em [VPS root no Brasil](https://streethosting.com.br/vps) quando projeto mistura Minecraft, bot e painel no mesmo host. Hardware exclusivo em [servidores dedicados](https://streethosting.com.br/dedicated) reduz vizinho barulhento mas não elimina necessidade de SSH endurecido. Detalhes da rede StreetHosting estão em [infraestrutura](https://streethosting.com.br/infraestructure).

Backup de chaves e configuração segue [estratégia de backup 3-2-1](https://streethosting.com.br/guias/infraestrutura/estrategia-backup-3-2-1-servidor): exporte lista de authorized_keys, jail.local e sshd_config para storage externo criptografado. Perder servidor dói menos quando reconstruir acesso leva minutos, não horas de ticket.

1. Agendar revisão trimestral de chaves e permissões sudo.
2. Testar console de recuperação uma vez por semestre.
3. Documentar quem possui chave de produção e contato de emergência.
4. Após incidente, rotacionar chaves e revisar logs de Accepted.

## Perguntas frequentes

### Mudar porta SSH basta?

Reduz volume de bots genéricos, mas não é defesa real. Segurança vem de chave forte, senha remota desligada e fail2ban. Porta obscura sozinha cai em scan completo eventualmente.

### fail2ban pode me bloquear?

Sim se equipe errar senha várias vezes ou NAT corporativo compartilhar IP. Use whitelist para IPs estáveis e maxretry conservador. Documente procedimento de desban pelo console do host.

### Posso manter senha para emergência?

Caminho mais seguro é console de recuperação do provedor e política clara de chaves. Se senha for inevitável, restrinja origem por VPN ou faixa IP e mantenha senha longa única.

### Quanto tempo leva para começar ataque?

Em VPS nova com IP público, tentativas automáticas costumam aparecer em minutos. Por isso hardening deve ser primeiro passo após criar instância, antes de instalar Minecraft ou bot.

## Guias relacionados

- [SSH seguro em VPS Linux: chaves, senhas, fail2ban e hábitos que evitam invasão](https://streethosting.com.br/guias/vps/ssh-seguro-vps-linux.md)
- [Firewall UFW em VPS Ubuntu: regras seguras sem travar o servidor](https://streethosting.com.br/guias/vps/firewall-ufw-vps-ubuntu.md)
- [Como instalar Docker no Ubuntu 22.04 ou 24.04 em VPS (guia direto ao ponto)](https://streethosting.com.br/guias/vps/instalar-docker-ubuntu-vps.md)
- [Estratégia de backup 3 2 1 para servidores](https://streethosting.com.br/guias/infraestrutura/estrategia-backup-3-2-1-servidor.md)

## Produtos citados

- https://streethosting.com.br/vps
- https://streethosting.com.br/vps/ryzen
- https://streethosting.com.br/dedicated
- https://streethosting.com.br/infraestructure

## Dados estruturados

```json
[
  {
    "@context": "https://schema.org",
    "@type": [
      "Article",
      "TechArticle"
    ],
    "headline": "Proteger servidor Linux contra brute force em SSH",
    "name": "Proteger servidor Linux contra brute force em SSH",
    "abstract": "Minutos após publicar um IP, bots começam a testar root e senhas vazadas no SSH. Este guia mostra camadas de defesa que funcionam em produção sem trancar sua equipe fora do servidor.",
    "description": "Defesa prática contra brute force SSH: fail2ban, chaves ED25519, UFW, hardening do sshd_config e operação segura em VPS e servidores dedicados no Brasil.",
    "datePublished": "2026-06-11",
    "dateModified": "2026-06-11",
    "author": {
      "@type": "Organization",
      "name": "Equipe StreetHosting"
    },
    "publisher": {
      "@type": "Organization",
      "name": "StreetHosting",
      "url": "https://streethosting.com.br"
    },
    "inLanguage": "pt-BR",
    "mainEntityOfPage": {
      "@type": "WebPage",
      "@id": "https://streethosting.com.br/guias/infraestrutura/proteger-servidor-linux-ssh-brute-force"
    }
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "Mudar porta SSH basta?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Reduz volume de bots genéricos, mas não é defesa real. Segurança vem de chave forte, senha remota desligada e fail2ban. Porta obscura sozinha cai em scan completo eventualmente."
        }
      },
      {
        "@type": "Question",
        "name": "fail2ban pode me bloquear?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Sim se equipe errar senha várias vezes ou NAT corporativo compartilhar IP. Use whitelist para IPs estáveis e maxretry conservador. Documente procedimento de desban pelo console do host."
        }
      },
      {
        "@type": "Question",
        "name": "Posso manter senha para emergência?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Caminho mais seguro é console de recuperação do provedor e política clara de chaves. Se senha for inevitável, restrinja origem por VPN ou faixa IP e mantenha senha longa única."
        }
      },
      {
        "@type": "Question",
        "name": "Quanto tempo leva para começar ataque?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Em VPS nova com IP público, tentativas automáticas costumam aparecer em minutos. Por isso hardening deve ser primeiro passo após criar instância, antes de instalar Minecraft ou bot."
        }
      }
    ]
  }
]
```