---
title: "Proteger SSH contra brute force: estratégia em camadas"
description: "Estratégia contra brute force no SSH: chave, senha desligada, root bloqueado, AllowUsers em sshd_config.d, teste em segunda sessão, Fail2Ban e VPN."
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-09-28"
author: "Equipe StreetHosting"
difficulty: "intermediario"
language: "pt-BR"
keywords:
  - "proteger ssh brute force"
  - "fail2ban linux"
  - "ssh seguro servidor"
  - "hardening ssh linux"
  - "desativar login por senha ssh"
  - "sshd_config ubuntu 24.04"
  - "ssh por vpn wireguard"
---

# Como tirar o SSH do alcance de ataques de força bruta

Minutos depois de um IP ir ao ar, robôs começam a testar root e senhas vazadas no SSH. Este guia organiza a defesa em camadas, do sshd_config à VPN, sem trancar a equipe fora do servidor.

> **Resposta rápida**
>
> Para **proteger o SSH contra brute force**, entre só com **chave**, desligue a senha e o login do root em um arquivo próprio em `/etc/ssh/sshd_config.d/`, limite os usuários com AllowUsers e teste em uma segunda sessão antes de fechar a primeira. Depois, reduza a exposição: Fail2Ban para o ruído e, se possível, SSH aceito só de IPs conhecidos ou pela VPN.

## O que é brute force em SSH

Brute force em SSH é a tentativa automatizada de adivinhar usuário e senha até acertar uma combinação fraca ou reutilizada. Não é preciso ser um alvo famoso: qualquer IP com a porta 22 aberta entra em listas de varredura em poucos minutos. As variações mais comuns são três.

- **Dicionário:** nomes comuns como root, admin, ubuntu e test, com senhas óbvias.
- **Senhas vazadas:** combinações reais de vazamentos de outros serviços, testadas porque muita gente repete senha.
- **Password spraying distribuído:** milhares de IPs, cada um tentando uma ou duas senhas, para não disparar limites por IP. É o formato que escapa do Fail2Ban.

Um acerto costuma virar minerador de criptomoeda, envio de spam, ataque a terceiros a partir do seu IP ou sequestro de dados. O objetivo da defesa não é zerar as tentativas, que nunca param, e sim tornar o sucesso impossível e reduzir a superfície exposta.

## Sinais de ataque nos logs

No Ubuntu 24.04 o serviço se chama ssh, e os eventos ficam no journal e em `/var/log/auth.log`. Três consultas dão o quadro:

```
# falhas de senha na última hora
sudo journalctl -u ssh --since "1 hour ago" | grep -c "Failed password"

# IPs que mais tentaram usuários inexistentes hoje
sudo journalctl -u ssh --since today | grep "Invalid user" | awk '{print $(NF-2)}' | sort | uniq -c | sort -rn | head

# logins que deram certo
sudo journalctl -u ssh | grep "Accepted"
```

| Linha típica | Interpretação | Ação |
| --- | --- | --- |
| Failed password for root | Robô testando o superusuário por senha | Confirmar PermitRootLogin no e senha desligada |
| Invalid user oracle | Dicionário de nomes de serviços | Ruído esperado; acompanhar o volume |
| Connection closed by authenticating user ... [preauth] | Tentativa encerrada antes de autenticar | Nada, se o login é só por chave |
| Accepted password for deploy | Login por senha bem sucedido | Investigar na hora se a senha deveria estar desligada |
| Accepted publickey de IP desconhecido | Chave válida usada de origem estranha | Revisar authorized_keys e trocar a chave |

Muitos IPs diferentes no mesmo minuto indicam uma botnet. Picos de madrugada são normais, porque varreduras não respeitam fuso. O sinal que importa de verdade é uma linha Accepted que você não reconhece.

## Escolha o modelo de exposição

Com a senha desligada, adivinhar o acesso deixa de ser possível na prática: o robô precisaria da sua chave privada. O risco que sobra é uma chave roubada ou uma falha no próprio servidor SSH. Em 2024, a falha conhecida como regreSSHion permitia execução remota antes da autenticação em várias versões do OpenSSH. Servidores com o SSH fechado para a internet não estavam ao alcance. Por isso a pergunta estratégica é quem consegue chegar à porta.

| Modelo | Como fica | Quando usar |
| --- | --- | --- |
| Aberto, só com chave | Porta pública, senha desligada, Fail2Ban contra o ruído | Equipe sem IP fixo; o mínimo aceitável |
| Restrito por IP | Firewall aceita o SSH só de endereços conhecidos | Escritório com IP fixo ou servidor intermediário |
| Só pela VPN | Porta fechada para a internet, acesso pelo WireGuard | Produção com dados sensíveis; exige manter a VPN |
| Porta alternativa | Mesma exposição, menos linhas no log | Complemento, nunca como defesa principal |

Qualquer que seja o modelo, as duas próximas seções são obrigatórias: endurecer o sshd e testar sem se trancar fora.

## Endurecer o sshd com um arquivo próprio

Antes, a chave precisa estar instalada e funcionando para um usuário com sudo. O passo a passo está em [login por chave SSH sem senha](https://streethosting.com.br/guias/vps/configurar-chave-ssh-sem-senha-vps) e, para quem usa Windows, em [chave SSH no Windows](https://streethosting.com.br/guias/vps/configurar-chave-ssh-windows). Em vez de editar o sshd_config principal, crie um arquivo seu:

```
# /etc/ssh/sshd_config.d/00-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowUsers deploy
MaxAuthTries 3
LoginGraceTime 30
```

O nome começando com 00 não é enfeite. O sshd_config do Ubuntu inclui os arquivos dessa pasta logo no topo, em ordem alfabética, e para cada opção vale o primeiro valor lido. Imagens de nuvem costumam trazer um `50-cloud-init.conf` com PasswordAuthentication yes; um arquivo seu com número maior perderia para ele. Confira o que existe e valide:

```
grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
sudo sshd -t
sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractive|permitrootlogin|allowusers|maxauthtries'
sudo systemctl reload ssh
```

- **sshd -t** não imprime nada quando a configuração está certa. **sshd -T** mostra os valores efetivos, depois de todos os includes, e é a prova de que a senha está mesmo desligada.
- **AllowUsers** aceita também origem: `AllowUsers deploy@203.0.113.10` só deixa o deploy entrar daquele IP.
- **MaxAuthTries 3** pode barrar você se o agente SSH oferecer muitas chaves antes da certa. A mensagem é Too many authentication failures; resolva com IdentitiesOnly yes e a chave certa no arquivo de configuração do cliente.

## Teste em uma segunda sessão antes de fechar a primeira

O reload não derruba a sessão em que você está, e é ela que salva o dia se algo der errado. Mantenha essa janela aberta e, em outro terminal, faça os testes:

1. Login normal com a chave: `ssh deploy@IP_DA_VPS`. Precisa entrar.
2. Login forçando senha: `ssh -o PubkeyAuthentication=no deploy@IP_DA_VPS`. Precisa ser recusado com Permission denied (publickey), sem nem perguntar a senha.
3. Login como root: `ssh root@IP_DA_VPS`. Precisa ser recusado.
4. Só com os três resultados certos, feche a primeira sessão.

> **Atenção**
>
> Se o teste falhar, corrija pela sessão que ficou aberta: apague ou ajuste o arquivo, rode sudo sshd -t e recarregue. Se as duas sessões caírem, o caminho é o console da VPS na área do cliente, que exige a senha local do usuário. Defina essa senha com sudo passwd antes de começar.

## Fail2Ban, firewall e VPN

Com o sshd endurecido, as camadas seguintes reduzem ruído e exposição.

**Fail2Ban.** No Ubuntu 24.04, a jail do SSH já vem ligada ao instalar o pacote e lê o journal. Com senha desligada, ele não impede invasão nenhuma que a chave já não impeça, mas limpa o log, poupa CPU e tira de circulação os IPs mais insistentes. Contra password spraying distribuído, cada IP erra pouco e passa abaixo do limite. A configuração completa, com aumento progressivo e recidive, está em [configurar Fail2Ban na VPS](https://streethosting.com.br/guias/vps/configurar-fail2ban-ssh-vps). Versões novas do OpenSSH, a partir da 9.8, trazem penalidades nativas por origem, mas o Ubuntu 24.04 usa a 9.6, então o Fail2Ban segue sendo a ferramenta.

**Restrição por IP ou VPN.** É a camada que mais reduz a superfície:

```
# SSH só de um IP fixo
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

# SSH só pela interface da VPN WireGuard
sudo ufw allow in on wg0 to any port 22 proto tcp

# depois de testar pelas novas regras, feche a regra aberta
sudo ufw status numbered
sudo ufw delete NUMERO_DA_REGRA_ABERTA
```

A sintaxe e os cuidados para não perder o acesso estão no guia de [firewall UFW na VPS](https://streethosting.com.br/guias/vps/firewall-ufw-vps-ubuntu), e a montagem da VPN em [VPN WireGuard na VPS](https://streethosting.com.br/guias/vps/proteger-vps-wireguard-vpn). Com IP residencial dinâmico, prefira a VPN: a lista de IPs quebra na próxima troca de endereço.

**Troca de porta.** Reduz linhas no log, porque robôs simples só testam a 22, mas varreduras completas acham qualquer porta. No Ubuntu 24.04 o SSH é ativado por socket, e a troca exige recarregar o systemd e reiniciar o ssh.socket, sempre com a porta nova liberada no firewall antes.

- [ ] Login só por chave, com PasswordAuthentication e KbdInteractiveAuthentication em no
- [ ] PermitRootLogin no; se o root for inevitável, só com chave
- [ ] AllowUsers com a lista mínima de contas humanas
- [ ] Configuração conferida com sshd -T depois de cada mudança
- [ ] Fail2Ban ativo na porta real do SSH
- [ ] Firewall com SSH restrito por IP ou VPN sempre que possível

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

Segurança do SSH não é uma tarefa de um dia. Uma rotina curta evita que a configuração se degrade:

1. A cada trimestre, revise o authorized_keys de cada usuário e remova chaves de quem saiu da equipe ou de máquinas aposentadas.
2. Depois de upgrades grandes do sistema, rode o sshd -T de novo e confirme que a senha continua desligada.
3. Configure um alerta para linhas Accepted fora do padrão e para picos de falhas por hora.
4. Uma vez por semestre, teste o login pelo console do painel.
5. Depois de qualquer incidente, troque todas as chaves e revise o histórico de logins aceitos.

> **Dica**
>
> Guarde uma cópia do `00-hardening.conf`, do jail.local e da lista de chaves autorizadas fora do servidor. Reconstruir o acesso de uma máquina nova leva minutos quando a configuração está pronta. O passo a passo geral de endurecimento está no guia de [SSH seguro na VPS Linux](https://streethosting.com.br/guias/vps/ssh-seguro-vps-linux).

O AntiDDoS incluso na rede das [VPS da StreetHosting](https://streethosting.com.br/vps) segura ataques volumétricos, mas não brute force, que é pouco tráfego e parece legítimo. Essa camada é sua, e o acesso root e a virtualização KVM deixam você aplicar tudo o que está neste guia, com o console do painel como rede de segurança. As VPS ficam em São Paulo e começam em R$ 26,00 na linha Xeon e R$ 42,00 na Ryzen 9 9950X. Para operações maiores, os [servidores dedicados](https://streethosting.com.br/dedicated) têm hardware exclusivo, 10 Gbps e AntiDDoS, a partir de R$ 1.599,00, com entrega em até 6 dias. Hardware exclusivo não dispensa SSH endurecido.

## Perguntas frequentes

### Mudar a porta do SSH basta?

Não. Reduz o volume de robôs genéricos e deixa os logs mais limpos, mas qualquer varredura completa encontra a porta nova. A proteção de verdade vem de login só por chave, senha remota desligada e exposição reduzida por IP ou VPN.

### O Fail2Ban pode me bloquear?

Pode, se alguém da equipe errar várias vezes ou se muita gente sair pelo mesmo IP, como em escritórios e redes com CGNAT. Coloque IPs estáveis no ignoreip e deixe documentado como desbanir pelo console da VPS.

### Posso manter login por senha no SSH para emergências?

Não é necessário. A saída de emergência é o console da VPS na área do cliente, que funciona pelo hipervisor e aceita a senha local do usuário mesmo com a senha desligada no SSH. Assim a emergência não fica aberta para a internet inteira.

### Quanto tempo leva para começarem as tentativas?

Em uma VPS nova com IP público, tentativas automáticas costumam aparecer em minutos. Por isso o endurecimento do SSH deve ser o primeiro passo depois de criar o servidor, antes de instalar jogo, bot ou aplicação.

### O AntiDDoS da hospedagem protege contra brute force?

Não. O AntiDDoS filtra volume anormal de tráfego, e um ataque de força bruta é pouco tráfego, com conexões que parecem legítimas. Quem barra esse ataque é a configuração do SSH, o Fail2Ban e a restrição de acesso, que ficam por sua conta na VPS.

## 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)
- [Configurar Fail2Ban na VPS: SSH, Nginx e reincidentes](https://streethosting.com.br/guias/vps/configurar-fail2ban-ssh-vps.md)
- [UFW na VPS Ubuntu: regras de firewall sem perder o SSH](https://streethosting.com.br/guias/vps/firewall-ufw-vps-ubuntu.md)
- [Configurar chave SSH no Windows para acessar a VPS](https://streethosting.com.br/guias/vps/configurar-chave-ssh-windows.md)
- [Como criar uma VPN com WireGuard na VPS para acesso privado](https://streethosting.com.br/guias/vps/proteger-vps-wireguard-vpn.md)

## Produtos citados

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

## Dados estruturados

```json
[
  {
    "@context": "https://schema.org",
    "@type": [
      "Article",
      "TechArticle"
    ],
    "headline": "Como tirar o SSH do alcance de ataques de força bruta",
    "name": "Proteger SSH contra brute force: estratégia em camadas",
    "abstract": "Minutos depois de um IP ir ao ar, robôs começam a testar root e senhas vazadas no SSH. Este guia organiza a defesa em camadas, do sshd_config à VPN, sem trancar a equipe fora do servidor.",
    "description": "Estratégia contra brute force no SSH: chave, senha desligada, root bloqueado, AllowUsers em sshd_config.d, teste em segunda sessão, Fail2Ban e VPN.",
    "datePublished": "2026-06-11",
    "dateModified": "2026-09-28",
    "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 a porta do SSH basta?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Não. Reduz o volume de robôs genéricos e deixa os logs mais limpos, mas qualquer varredura completa encontra a porta nova. A proteção de verdade vem de login só por chave, senha remota desligada e exposição reduzida por IP ou VPN."
        }
      },
      {
        "@type": "Question",
        "name": "O Fail2Ban pode me bloquear?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Pode, se alguém da equipe errar várias vezes ou se muita gente sair pelo mesmo IP, como em escritórios e redes com CGNAT. Coloque IPs estáveis no ignoreip e deixe documentado como desbanir pelo console da VPS."
        }
      },
      {
        "@type": "Question",
        "name": "Posso manter login por senha no SSH para emergências?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Não é necessário. A saída de emergência é o console da VPS na área do cliente, que funciona pelo hipervisor e aceita a senha local do usuário mesmo com a senha desligada no SSH. Assim a emergência não fica aberta para a internet inteira."
        }
      },
      {
        "@type": "Question",
        "name": "Quanto tempo leva para começarem as tentativas?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Em uma VPS nova com IP público, tentativas automáticas costumam aparecer em minutos. Por isso o endurecimento do SSH deve ser o primeiro passo depois de criar o servidor, antes de instalar jogo, bot ou aplicação."
        }
      },
      {
        "@type": "Question",
        "name": "O AntiDDoS da hospedagem protege contra brute force?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Não. O AntiDDoS filtra volume anormal de tráfego, e um ataque de força bruta é pouco tráfego, com conexões que parecem legítimas. Quem barra esse ataque é a configuração do SSH, o Fail2Ban e a restrição de acesso, que ficam por sua conta na VPS."
        }
      }
    ]
  }
]
```