UFW Blocking SSH: Quick Fix in 2 Commands

You Enabled UFW and Now SSH Is Dead

Yeah, we've all been there. You run sudo ufw enable thinking you're securing the server, and the next SSH session times out. You're locked out of your own box. Let's fix it right now.

The Fix: Add the SSH Rule Before Enabling UFW

The culprit here is almost always one thing: you enabled UFW without first adding an allow rule for SSH. UFW's default policy is to deny incoming connections, so the moment you enable it, your SSH port gets cut off. Here's the fix, assuming you still have console access (physical or via iDRAC/iLO/IPMI):

sudo ufw allow ssh
sudo ufw enable

That's it. ufw allow ssh uses the OpenSSH profile, which by default opens port 22. If you run SSH on a non-standard port (say 2222), use this instead:

sudo ufw allow 2222/tcp
sudo ufw enable

Now verify it worked:

sudo ufw status verbose

You should see something like this:

Status: active
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)

Recovery Mode: You're Already Locked Out

If you're reading this from your phone and you can't SSH in at all, you need out-of-band access. Every server has a fallback — iDRAC on Dell, iLO on HPE, IPMI on Supermicro, or a VNC console from your hosting provider. Log into that console (it's a virtual keyboard, mouse, and screen) and run the commands above. If you don't have that set up, you're looking at a datacenter visit or a hosting support ticket. Don't skip console access on production boxes — ever.

Why This Happens

UFW isn't smart out of the box. When you first install it, it sets default policies to deny all incoming traffic and allow all outgoing traffic. The ufw enable command applies those rules immediately. If you didn't add an allow rule for SSH before enabling it, your SSH port gets dropped. It's a design choice that prioritizes security over convenience — and it's bitten every admin at least once.

The key insight: UFW doesn't prompt you to add SSH rules. It just applies whatever rules you've defined. If the rule list is empty (which it is on a fresh install), enabling UFW blocks everything incoming, including your SSH session.

Less Common Variations

UFW Blocks SSH After Reboot

This one's weird. You had SSH working fine, then rebooted, and now it's blocked. Check if UFW is actually enabled:

sudo ufw status

If it's inactive, some other firewall (like iptables, firewalld, or a cloud security group) is blocking you. If it's active but SSH isn't listed, someone removed the rule in a previous session. Check the logs:

sudo journalctl -u ufw | grep -i block

UFW Blocks SSH on a Specific Interface

Sometimes you only want SSH on a management interface. You might have added an allow rule for all interfaces and then later restricted it, locking yourself out. Example of a restrictive rule that works:

sudo ufw allow in on eth0 to any port 22 proto tcp

But if you accidentally used the wrong interface name (eth1 instead of eth0), you're blocked. Double-check the interface name with ip a before adding interface-specific rules.

UFW Blocks SSH From a Specific IP

If you tried to restrict SSH to just your office IP and your IP changed (VPN, DHCP, mobile tethering), you'll be locked out. The fix is to allow a wider range or use a dynamic DNS-based rule. But for recovery, you need console access to change the rule:

sudo ufw delete deny from 192.168.1.100 to any port 22
sudo ufw allow ssh

How to Prevent This From Happening Again

Do two things. First, before you ever run ufw enable, run this command as a safety net:

sudo ufw allow ssh

Second, automate this check. Add a script to your provisioning process — Ansible, cloud-init, whatever you use — that ensures the SSH rule exists before UFW is enabled. Here's a simple bash check for your .bashrc or a startup script:

if sudo ufw status | grep -q inactive; then
    echo "UFW is inactive — add SSH rule before enabling"
fi

Also, never enable UFW over an active SSH session without testing first. If you must do it remotely, use a method that leaves a fallback — like a cron job that disables UFW after 5 minutes if you don't signal it. Something like this in crontab:

*/5 * * * * /usr/sbin/ufw disable

Then run sudo ufw enable, test SSH in a new window, and remove the cron job once confirmed working. I've seen admins do this for years — it's a solid safety net.

Final Thought

UFW is a great tool for simple firewall rules. But it's unforgiving about sequence. Add your SSH allow rule before enabling it. Keep console access as a backup. And never assume your SSH session will survive a firewall change. You'll save yourself a lot of late-night phone calls.