Confirm UFW is the intended firewall manager and does not conflict with a hosting panel, container platform or another rule manager. Record the actual SSH port and your stable source address or VPN range. Keep console recovery and an existing session available.

1. Inspect sudo ufw status verbose and current listeners. Inventory required public services and private administrative services before changing policy.
2. Add an explicit allow rule for the real SSH port and intended source network. The OpenSSH application profile usually assumes its configured profile ports, so inspect it before relying on it for a custom port.
3. Add only the required application ports or reviewed application profiles. Account for IPv6 deliberately rather than assuming IPv4 rules cover every exposure.
4. Review the resulting rules, then enable or adjust the firewall during a controlled window. Keep the original session open.
5. Open a new SSH connection from the allowed network and test public services externally. Once confirmed, remove obsolete broad allowances using their exact rule identity and recheck numbered rules after each removal.

From the server console or an existing administrator session, inspect UFW and the SSH listener before drafting a rule change. Replace port 22 if SSH uses a different port. These checks show existing state and do not enable, reload or remove firewall rules.

sudo ufw status verbose
sudo ufw status numbered
sudo ss -ltnp 'sport = :22'

Read the result: Confirm the intended source network can reach the actual listening address and port in the applicable IP family. A numbered UFW listing helps review rules, but its numbers can change after edits. An allow rule for the default OpenSSH profile may not match a custom SSH port.

Also review the provider firewall, VPN or bastion policy. Keep console access until a new connection from the intended network succeeds after the reviewed change. Do not enable an unfamiliar firewall ruleset remotely merely because one visible SSH rule appears correct.

No. An established connection may remain permitted while new connections are blocked. Always test a separate fresh session before ending the working one.

Confirm intended clients can connect and an unauthorized test source is denied where required. Verify the rule state after a controlled reload or reboot. Check provider-level firewalls separately because both layers can affect access.

If new SSH connections fail, use the current session or console to correct the scoped rule. Do not reset all firewall rules or globally disable filtering as the permanent solution. If containers publish services outside the expected UFW path, inspect their documented networking integration rather than assuming the UFW display describes all traffic.

• Recovering from an SSH lockout using the server console
• Finding which process listens on a Linux network port
• Separating DNS failure from network failure on Linux
• Installing an SSH key without losing existing server access

• Ubuntu: Firewalls
• manpages.ubuntu.com: Ufw

• iproute2 ss manual, published by Debian