Tutoriais de VPS
SSH bloqueado após ativar o UFW no VPS (2026): regras de firewall, console e checklist de recuperação com modo resgate
O SSH para de conectar de repente após você ativar o UFW. Normalmente o servidor não está quebrado: o problema é a porta SSH, o firewall da nuvem ou a ordem das regras. Este artigo cobre quatro situações — ainda conectado, bloqueado do lado de fora, apenas console e modo resgate — com comandos de diagnóstico e recuperação prontos para copiar.
SSH bloqueado após ativar o UFW no VPS (2026): regras de firewall, console e checklist de recuperação com modo resgate
O erro mais comum de quem ativa um firewall em um VPS pela primeira vez não é "não ter ativado a proteção de segurança", mas ter executado primeiro:
sudo ufw enable
Depois disso, a sessão SSH atual aguenta por um tempo, mas um terminal novo não conecta mais. Pouco depois a rede oscila, a SSH existente também cai e o servidor praticamente te tranca do lado de fora.
Isso é muito comum, especialmente em sistemas Ubuntu / Debian. O UFW em si não tem problema: ele apenas bloqueia as conexões de entrada que você não liberou explicitamente. O problema real costuma estar em um de três pontos:
- Você não liberou a porta SSH antes
- Você mudou a porta SSH, mas só liberou a 22
- O grupo de segurança do provedor de nuvem e as regras do UFW no sistema entram em conflito
Este artigo trata de dois estados: "ainda consigo conectar" e "já não consigo conectar". Não se apresse em reinstalar o sistema: na maioria dos casos é possível recuperar.
Se você ainda tem uma janela SSH que não caiu, trabalhe nela primeiro e não a feche.
Se você já não consegue conectar de jeito nenhum, mas o console do VPS oferece VNC, Console, Serial Console ou Rescue Mode, ainda há chance de recuperar.
Veja primeiro o erro:
ssh root@your_server_ip
Os sintomas comuns se agrupam mais ou menos assim:
| Sintoma | Causa mais provável |
|---|---|
Connection timed out | Firewall, grupo de segurança, porta não liberada |
Connection refused | Serviço SSH não está escutando, ou porta errada |
Permission denied | Problema de chave, usuário ou permissão |
| Só a rede do escritório/casa não conecta | Seu IP local está restrito ou foi bloqueado por engano pelo Fail2Ban |
Se você vê Permission denied, o foco não é o UFW; veja primeiro este artigo: O que fazer com VPS SSH Permission denied.
Se for Connection timed out, continue lendo este artigo.
Este é o caso mais fácil de recuperar. Não reinicie, não faça logout, não feche o terminal.
sudo ufw status verbose
Se você vir algo como:
Status: active
Default: deny (incoming), allow (outgoing), disabled (routed)
isso significa que a entrada é negada por padrão. Em seguida, confirme se a porta SSH está liberada.
Não adivinhe a porta. Veja diretamente os listeners:
sudo ss -lntp | grep ssh
Você pode ver:
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=888,fd=3))
Ou talvez:
LISTEN 0 128 0.0.0.0:2222 0.0.0.0:* users:(("sshd",pid=888,fd=3))
Depois confira o arquivo de configuração para confirmar:
sudo grep -E '^Port|^ListenAddress' /etc/ssh/sshd_config
Se não houver saída de Port, normalmente é a 22 padrão.
Se o SSH está na 22 padrão:
sudo ufw allow OpenSSH
sudo ufw allow 22/tcp
OpenSSH é o perfil de aplicação do UFW, normalmente equivale a liberar a 22, mas eu recomendo também escrever uma regra explícita 22/tcp: fica mais claro na hora de diagnosticar depois.
Se você mudou para a 2222:
sudo ufw allow 2222/tcp
Se você não tem certeza da porta, não saia apagando regras: primeiro libere a porta em que o SSH está realmente escutando.
sudo ufw reload
sudo ufw status numbered
Você deve ver algo como:
[ 1] 22/tcp ALLOW IN Anywhere
[ 2] 2222/tcp ALLOW IN Anywhere
Depois, sem sair da janela atual, abra outro terminal e teste:
ssh root@your_server_ip
Se você usa uma porta personalizada:
ssh -p 2222 root@your_server_ip
Quando a nova janela conectar, feche a antiga.
Muitos painéis de VPS oferecem VNC Console, Serial Console ou Web Console. Eles não passam pela porta SSH pública, então quando o UFW bloqueia o SSH, o console normalmente ainda abre.
Depois de entrar no console, faça login no sistema. Em seguida, execute:
sudo ufw status numbered
Se for só a porta SSH não liberada, adicione a regra diretamente:
sudo ufw allow 22/tcp
sudo ufw reload
Se você não tem certeza da porta SSH:
sudo ss -lntp | grep ssh
sudo grep -E '^Port|^ListenAddress' /etc/ssh/sshd_config
Depois libere a porta real:
sudo ufw allow 2222/tcp
sudo ufw reload
Se você está com pressa para recuperar o acesso, pode desativar o UFW temporariamente:
sudo ufw disable
Mas isso é só um autossalvamento temporário. Assim que conseguir entrar por SSH de novo, restaure imediatamente as regras mínimas:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
Se o seu SSH não está na 22, substitua 22/tcp pela porta real.
Se o painel do VPS não tem console utilizável, ou você não consegue fazer login no console, será preciso usar o Rescue Mode. Os nomes variam conforme o provedor; os mais comuns são:
- Rescue Mode
- Recovery Mode
- Rescue ISO
- Boot from ISO
- Emergency Console
Depois de entrar no modo resgate, o sistema normalmente inicia em um ambiente Linux temporário. O que você precisa fazer é montar o disco do sistema original e entrar nele para modificar as regras do UFW ou desativar o UFW diretamente.
Primeiro veja os discos:
lsblk
Supondo que a partição do sistema original seja /dev/vda1, monte-a:
sudo mkdir -p /mnt/sysroot
sudo mount /dev/vda1 /mnt/sysroot
Se houver partições boot ou efi separadas, monte-as conforme a situação real. A maioria dos VPS pequenos tem apenas uma partição raiz.
Entre no sistema original:
sudo mount --bind /dev /mnt/sysroot/dev
sudo mount --bind /proc /mnt/sysroot/proc
sudo mount --bind /sys /mnt/sysroot/sys
sudo chroot /mnt/sysroot
Desative o UFW:
ufw disable
Ou adicione regras de liberação:
ufw allow 22/tcp
ufw reload
Saia e reinicie:
exit
sudo reboot
Se você não está familiarizado com o modo resgate, consulte também: Como usar o modo resgate do VPS.
Muita gente só altera o UFW dentro do sistema e esquece que o painel do provedor de nuvem tem outra camada de firewall.
O caminho de acesso público normalmente é:
你的电脑 -> 云厂商安全组/防火墙 -> VPS 系统 UFW -> sshd 服务
Se qualquer camada estiver bloqueada, o SSH não conecta.
Por isso você deve verificar ao mesmo tempo:
- Se o grupo de segurança do provedor de nuvem libera a porta SSH
- Se a regra de entrada permite apenas um IP específico
- Se o VPS está vinculado ao IPv4 / IPv6 público correto
- Se o UFW do sistema libera a mesma porta
- Se o sshd realmente está escutando nessa porta
Se os serviços do seu site também estão inacessíveis, consulte: Serviço do VPS iniciado mas inacessível pela internet.
De agora em diante, não execute diretamente ufw enable. Uma ordem mais segura é:
sudo ufw status verbose
sudo ss -lntp | grep ssh
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --dry-run enable
sudo ufw enable
sudo ufw status numbered
Se você usa uma porta SSH personalizada, como 2222:
sudo ufw allow 2222/tcp
Depois abra outra janela SSH para testar e só feche a conexão antiga quando confirmar que a nova funciona.
--dry-run não ativa as regras de verdade, mas permite ver o que o UFW faria. Ele não consegue detectar todos os problemas por você, mas é mais seguro do que ativar o firewall diretamente.
Se o Docker roda no VPS, olhar só o UFW pode levar a uma avaliação errada. O Docker altera as regras do iptables, então algumas portas podem ficar expostas à internet pelo mapeamento de portas do Docker mesmo que o UFW não pareça liberá-las.
Por exemplo:
docker run -p 8080:80 nginx
Portas como essas não estão necessariamente sob controle total do UFW. Em produção, é melhor:
- Liberar apenas as portas necessárias no grupo de segurança do provedor de nuvem
- Vincular os serviços Docker a
127.0.0.1sempre que possível - Encaminhar o acesso externo de forma unificada por um proxy reverso Nginx / Caddy
- Não mapear bancos de dados, Redis ou painéis administrativos diretamente para a internet
Se você está com problemas de acesso anormal a serviços Docker, consulte: O que fazer quando um contêiner Docker do VPS fica reiniciando.
Se o SSH ainda está na 22 padrão, normalmente não há problema. Mas se você alterou Port em /etc/ssh/sshd_config, pode ser que OpenSSH não te salve.
O jeito seguro é liberar a porta real:
sudo ufw allow 2222/tcp
Você liberou a 2222 no sistema, mas o painel da nuvem só libera a 22: também vai dar timeout.
Os dois lados precisam ser iguais.
Os números de ufw status numbered mudam conforme você apaga. Apague uma de cada vez e consulte de novo após cada exclusão:
sudo ufw status numbered
sudo ufw delete 3
sudo ufw status numbered
Não apague várias seguidas com base em números antigos.
O UFW é essencialmente uma ferramenta front-end; por baixo ainda é um sistema de regras. Se você também escreve iptables / nftables à mão, usa Docker e ativa um firewall na nuvem, o diagnóstico fica complicado.
Para um VPS comum, mantenha primeiro a simplicidade: o firewall da nuvem gerencia a entrada pública e o UFW faz a liberação mínima dentro do sistema.
Se agora você não consegue entrar por SSH, faça nesta ordem:
- Veja se o erro SSH é
timed outouPermission denied - Verifique se o grupo de segurança do provedor de nuvem libera a porta SSH
- Tente fazer login pelo Web Console / VNC Console
- Execute
ufw status numbered - Use
ss -lntp | grep sshpara encontrar a porta SSH real - Libere a porta real:
ufw allow 端口/tcp - Após
ufw reload, abra outra janela para testar - Se o console também não funcionar, entre no Rescue Mode para desativar ou corrigir o UFW
- O que fazer quando o VPS é bloqueado por engano pelo Fail2Ban: se você suspeita que o seu IP local foi bloqueado e não é um problema do UFW, leia este artigo.
- O que fazer com VPS SSH Permission denied: se o SSH chega ao servidor mas a autenticação falha, verifique chaves, usuários e permissões.
- Como usar o modo resgate do VPS: se você não consegue entrar no console e precisa corrigir o sistema a partir de um ambiente de resgate.
Por último, lembre-se: antes de ativar o UFW, libere primeiro a porta SSH atual e mantenha uma janela SSH antiga aberta. Ativar o firewall mais rápido não é mais seguro: se a ordem das regras estiver errada, a primeira coisa que ele bloqueia costuma ser você mesmo.