Ubuntu ufw SSH Troubleshooting: Checking Allow Rules and Recovery

ufw Troubleshooting - SSH Connection

What You'll Learn

  • How to systematically isolate ufw as the cause when SSH won't connect
  • Quick recovery when "allowed but still can't connect" or "suddenly locked out"
  • How to avoid common accidents (locking yourself out)

Quick Summary

When SSH won't connect, follow this order from top to bottom:

  1. Confirm SSH port (not always 22)
  2. Check if ufw is the cause: sudo ufw status verbose
  3. Check allow rules: sudo ufw status numbered
  4. Add necessary allow: sudo ufw allow <PORT>/tcp
  5. Still failing? Check non-ufw causes (port listening, sshd, security groups)

Important

This article assumes you can access the server (via console or alternate route). If you're locked out via SSH, use cloud console or VPS web console.

Table of Contents

  1. First, Clarify the Situation
  2. Check if ufw Is the Cause
  3. Confirm SSH Port Number
  4. Check ufw Rules (Numbered)
  5. Allow SSH Port
  6. Allow with IP Restriction
  7. Top 5 "Allowed But Still Fails" Causes
  8. Error Examples and Interpretation
  9. Things to Avoid

1. First, Clarify the Situation

Confirm these 3 points:

  • Target host: Domain or IP
  • Target port: 22 or custom like 2222
  • Source: Home, office, bastion, etc. (needed for IP restrictions)

2. Check if ufw Is the Cause (Do This First)

If ufw is inactive, it's not the cause.

$ sudo ufw status verbose

Example output (active):

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

Example output (inactive):

Status: inactive
  • inactive → Not ufw (check sshd, port, cloud firewall, etc.)
  • active → Proceed to check rules

3. Confirm SSH Port Number (22 Isn't Always Right)

SSH port is often changed from 22 for security.

$ sudo grep -nE '^\s*Port\s+' /etc/ssh/sshd_config

Also check (for included configs):

$ sudo sshd -T | grep -i '^port '

sshd -T shows the actual running config, so it's reliable.

4. Check ufw Rules (Numbered)

Check current state first. Don't guess.

$ sudo ufw status numbered

Key points:

  • Is SSH port (e.g., 22/tcp or 2222/tcp) ALLOW IN?
  • Are there any DENY rules (priority issues)?
  • Is From restricted (locked out if your IP changes)?

5. Quick Recovery: Allow SSH Port

Priority is getting connected again. Lock it down with IP restrictions later.

5-1. Allow Standard Port 22

$ sudo ufw allow 22/tcp

5-2. Allow Port 2222 (Example)

$ sudo ufw allow 2222/tcp

Always verify after adding:

$ sudo ufw status numbered

6. More Secure: Allow with IP Restriction (Recommended)

IP-restricted SSH is more secure than wide open.

$ sudo ufw allow from 203.0.113.10 to any port 2222 proto tcp

Warning: If your home IP changes, you'll be locked out next day. Consider "static IP", "VPN", or "bastion host" for production.

7. Top 5 "Allowed But Still Fails" Causes

Cause 1: sshd Is Not Running / Crashed

$ sudo systemctl status ssh
$ sudo systemctl start ssh
$ sudo journalctl -u ssh -n 200

Cause 2: Server Not Listening on That Port

$ sudo ss -lntp | grep ':22 '
$ sudo ss -lntp | grep ':2222 '

Cause 3: Cloud/Hosting Firewall Blocking

AWS Security Groups, GCP VPC Firewall, VPS admin panel firewall, etc. ufw alone won't help.

$ nc -vz example.com 2222
  • timed out → Path/firewall (including cloud side)
  • refused → Server not listening
  • succeeded → Network path is open

Cause 4: ufw Rule Priority or deny Taking Effect

$ sudo ufw status numbered
$ sudo ufw delete 3

Cause 5: IPv6 Only Closed / Only IPv6 Open

Check Anywhere (v6) in status for IPv6 rules.

8. Error Examples and Interpretation

8-1. Connection timed out

Meaning: Packets not reaching (firewall/SG/routing/DNS/host down)

8-2. Connection refused

Meaning: Reached but nothing listening on that port

8-3. Permission denied (publickey)

Meaning: Network works, authentication fails (not ufw)

8-4. Host key verification failed

Meaning: known_hosts mismatch (not ufw)

$ ssh-keygen -R example.com

9. Things to Avoid

Don't: Enable ufw Without SSH Allow Rule

Running ufw enable without SSH allowed locks you out remotely.

Safe order:

  1. sudo ufw allow <ssh-port>/tcp
  2. sudo ufw enable
  3. sudo ufw status numbered

Don't: Spam deny Rules Without Understanding

Too many deny rules create priority issues and slow recovery.

Don't: Add IP Restrictions Without Checking "Your IP"

If home IP changes frequently, IP restriction without VPN/bastion causes lockouts.

Copy-Paste Template

# Allow SSH(2222) wide open (recovery first)
sudo ufw allow 2222/tcp
sudo ufw status numbered

# Allow SSH(2222) from specific IP (production)
sudo ufw allow from 203.0.113.10 to any port 2222 proto tcp
sudo ufw status numbered

# Delete deny rule by number
sudo ufw status numbered
sudo ufw delete 3
sudo ufw status numbered

# Check if sshd is running
sudo systemctl status ssh
sudo journalctl -u ssh -n 200
sudo ss -lntp | grep ':2222 '

# Client-side connectivity check
nc -vz example.com 2222

Summary

  • ufw troubleshooting: "Is ufw active?" → "Confirm SSH port" → "Check rules" → "Add allow"
  • timed out / refused / publickey differences tell you the layer of the problem
  • Don't blindly ufw enable/deny - check numbered status first

Test Environment

Commands in this article were tested on Ubuntu 24.04 LTS / bash 5.2.

Next Reading