VPS Tutorials
SSH Locked Out After Enabling UFW on a VPS (2026): Firewall Rules, Console, and Rescue Mode Recovery Checklist
SSH suddenly stops connecting after you enable UFW. Usually the server isn't broken — the problem is the SSH port, the cloud firewall, or rule ordering. This article covers four situations — still connected, locked out, console-only access, and rescue mode — with copy-paste troubleshooting and recovery commands.
SSH Locked Out After Enabling UFW on a VPS (2026): Firewall Rules, Console, and Rescue Mode Recovery Checklist
The most common mistake people make the first time they enable a firewall on a VPS isn't "failing to turn on security protection" — it's running this first:
sudo ufw enable
Then the current SSH session holds on for a while, but a newly opened terminal can't connect. A little later the network hiccups, the existing SSH session drops too, and the server has effectively locked you outside the door.
This is very common, especially on Ubuntu / Debian systems. UFW itself is fine — it's just blocking inbound connections you haven't explicitly allowed. The real problem is usually in one of three places:
- You didn't allow the SSH port first
- You changed the SSH port but only allowed 22
- The cloud provider's security group and the system's UFW rules conflict with each other
This article handles two states: "still connected" and "already disconnected." Don't rush to reinstall the system — most cases can be recovered.
If you still have an SSH window that hasn't dropped, work in that window first and don't close it.
If you can't connect at all but the VPS console offers VNC, Console, Serial Console, or Rescue Mode, you still have a chance to recover.
Look at the error first:
ssh root@your_server_ip
Common symptoms fall into roughly these categories:
| Symptom | More likely cause |
|---|---|
Connection timed out | Firewall, security group, port not allowed |
Connection refused | SSH service not listening, or wrong port |
Permission denied | Key, user, or permission issue |
| Only your office/home network can't connect | Your local IP is restricted or wrongly banned by Fail2Ban |
If you see Permission denied, the focus isn't UFW — see this article first: What to Do About VPS SSH Permission denied.
If it's Connection timed out, keep reading this article.
This is the easiest case to recover. Don't reboot, don't log out, don't close the terminal.
sudo ufw status verbose
If you see something like:
Status: active
Default: deny (incoming), allow (outgoing), disabled (routed)
that means inbound is denied by default. Next, confirm whether the SSH port is allowed.
Don't guess the port. Look at the listeners directly:
sudo ss -lntp | grep ssh
You might see:
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=888,fd=3))
Or it might be:
LISTEN 0 128 0.0.0.0:2222 0.0.0.0:* users:(("sshd",pid=888,fd=3))
Then check the config file to confirm:
sudo grep -E '^Port|^ListenAddress' /etc/ssh/sshd_config
If there's no Port output, it's usually the default 22.
If SSH is on the default 22:
sudo ufw allow OpenSSH
sudo ufw allow 22/tcp
OpenSSH is UFW's application profile, usually equivalent to allowing 22, but I'd recommend also writing an explicit 22/tcp rule — it's clearer when troubleshooting later.
If you changed it to 2222:
sudo ufw allow 2222/tcp
If you're unsure of the port, don't delete rules at random — first allow the port SSH is actually listening on.
sudo ufw reload
sudo ufw status numbered
You should see something like:
[ 1] 22/tcp ALLOW IN Anywhere
[ 2] 2222/tcp ALLOW IN Anywhere
Then, without exiting the current window, open a new terminal and test:
ssh root@your_server_ip
If you use a custom port:
ssh -p 2222 root@your_server_ip
Once the new window connects, close the old one.
Many VPS panels offer a VNC Console, Serial Console, or Web Console. These don't go through the public SSH port, so when UFW blocks SSH, the console usually still opens.
After entering the console, log in to the system. Then run:
sudo ufw status numbered
If it's just that the SSH port isn't allowed, add the rule directly:
sudo ufw allow 22/tcp
sudo ufw reload
If you're unsure of the SSH port:
sudo ss -lntp | grep ssh
sudo grep -E '^Port|^ListenAddress' /etc/ssh/sshd_config
Then allow the actual port:
sudo ufw allow 2222/tcp
sudo ufw reload
If you're in a hurry to restore access, you can temporarily disable UFW:
sudo ufw disable
But this is only a temporary self-rescue. Once you can log in over SSH again, immediately restore the minimal rules:
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
If your SSH isn't on 22, replace 22/tcp with the actual port.
If the VPS panel has no usable console, or you can't log in to the console, you'll need Rescue Mode. Names vary by provider; common ones include:
- Rescue Mode
- Recovery Mode
- Rescue ISO
- Boot from ISO
- Emergency Console
After entering rescue mode, the system usually boots into a temporary Linux environment. What you need to do is mount the original system disk, then go in and modify the UFW rules or disable UFW directly.
First, look at the disks:
lsblk
Assuming the original system partition is /dev/vda1, mount it:
sudo mkdir -p /mnt/sysroot
sudo mount /dev/vda1 /mnt/sysroot
If there are separate boot or efi partitions, mount them according to the actual layout. Most small VPS instances have only a single root partition.
Enter the original system:
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
Disable UFW:
ufw disable
Or add allow rules:
ufw allow 22/tcp
ufw reload
Exit and reboot:
exit
sudo reboot
If you're not familiar with rescue mode, read this alongside: How to Use VPS Rescue Mode.
Many people only change UFW inside the system and forget there's another firewall layer in the cloud provider's panel.
The public access path is usually:
你的电脑 -> 云厂商安全组/防火墙 -> VPS 系统 UFW -> sshd 服务
If any layer is blocked, SSH won't connect.
So check all of these at the same time:
- Whether the cloud provider's security group allows the SSH port
- Whether the inbound rule only allows a certain IP
- Whether the VPS is bound to the correct public IPv4 / IPv6
- Whether the system's UFW allows the same port
- Whether sshd is actually listening on that port
If your site services are also unreachable, see: VPS Service Started but Not Accessible from the Internet.
From now on, don't just run ufw enable. A safer order is:
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
If you use a custom SSH port, such as 2222:
sudo ufw allow 2222/tcp
Then open another SSH window to test, and only close the old connection after confirming the new one works.
--dry-run doesn't actually enable the rules, but it lets you see what UFW would do. It can't catch every problem for you, but it's safer than enabling the firewall directly.
If Docker runs on the VPS, looking only at UFW can mislead you. Docker modifies iptables rules, so some ports may be exposed to the public internet through Docker port mappings even if UFW doesn't appear to allow them.
For example:
docker run -p 8080:80 nginx
Ports like these aren't necessarily fully controlled by UFW. For production, it's better to:
- Allow only necessary ports in the cloud provider's security group
- Bind Docker services to
127.0.0.1where possible - Route external access uniformly through an Nginx / Caddy reverse proxy
- Never map databases, Redis, or admin panels directly to the public internet
If you're dealing with abnormal Docker service access, see: What to Do When a VPS Docker Container Keeps Restarting.
If SSH is still on the default 22, this is usually fine. But if you changed Port in /etc/ssh/sshd_config, OpenSSH may not save you.
The safe approach is to allow the actual port:
sudo ufw allow 2222/tcp
You allowed 2222 in the system but the cloud panel only allows 22 — it will still time out.
Both sides must match.
ufw status numbered numbers change as you delete rules. Delete one at a time and re-check after each deletion:
sudo ufw status numbered
sudo ufw delete 3
sudo ufw status numbered
Don't delete several in a row based on old numbers.
UFW is essentially a front-end tool; underneath it's still a rule system. If you also hand-write iptables / nftables, use Docker, and enable a cloud firewall, troubleshooting gets complicated.
For an ordinary VPS, keep it simple first: the cloud firewall manages the public entry point, and UFW does minimal allow-listing inside the system.
If you can't get in over SSH right now, do this in order:
- Check whether the SSH error is
timed outorPermission denied - Check whether the cloud provider's security group allows the SSH port
- Try logging in via Web Console / VNC Console
- Run
ufw status numbered - Use
ss -lntp | grep sshto find the real SSH port - Allow the real port:
ufw allow 端口/tcp - After
ufw reload, open another window to test - If the console doesn't work either, enter Rescue Mode to disable or repair UFW
- What to Do When a VPS Is Wrongly Banned by Fail2Ban: if you suspect your local IP is banned rather than a UFW problem, read this.
- What to Do About VPS SSH Permission denied: if SSH reaches the server but authentication fails, check keys, users, and permissions.
- How to Use VPS Rescue Mode: if you can't get into the console and need to fix the system from a rescue environment.
One last thing to remember: before enabling UFW, allow the current SSH port first and keep an old SSH window open. Enabling a firewall faster isn't safer — if the rule order is wrong, the first thing it blocks is usually you.