ufw SSH Troubleshooting - Checking Allow Rules and Recovery

2025-12-16 Reading time: About 12 min Difficulty: Intermediate

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)

1. First, Clarify the Situation

Conclusion: Confirm host, port, and source IP before any firewall change to avoid lockout.

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)

Conclusion: Run sudo ufw status verbose — if inactive, ufw is not causing the SSH failure.

If ufw is inactive, it's not the cause (likely something else).

$ 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)

Conclusion: Run sudo sshd -T | grep '^port' to confirm the actual SSH port sshd is using.

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 '

4. Check ufw Rules (Numbered)

Conclusion: sudo ufw status numbered — verify SSH port has ALLOW IN and no DENY override.

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

Conclusion: sudo ufw allow <PORT>/tcp to restore SSH, then verify with status numbered.

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)

Conclusion: ufw allow from <IP> to any port <PORT> proto tcp after confirming a static IP.

IP-restricted SSH is more secure than wide open.

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

7. Top 5 "Allowed But Still Fails" Causes

Conclusion: When the allow rule exists but SSH fails, check sshd, port, and cloud firewall.

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

Conclusion: "Timed out" is blocked route; "refused" is nothing listening; publickey is auth.

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

Conclusion: Add SSH allow before ufw enable, avoid deny stacking, confirm IP stability.

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.

# 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