Firewall the SSH port

The fix

# ufw — Debian, Ubuntu
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw deny 22/tcp

# firewalld — RHEL, Rocky, Alma
sudo firewall-cmd --permanent --new-zone=sshadmin
sudo firewall-cmd --permanent --zone=sshadmin --add-source=203.0.113.10
sudo firewall-cmd --permanent --zone=sshadmin --add-service=ssh
sudo firewall-cmd --permanent --zone=public --remove-service=ssh
sudo firewall-cmd --reload

Replace 203.0.113.10 with the address you administer from.

Why it matters

Every other control on this list hardens a daemon that attackers can still reach. A firewall rule means they never get to it. Authentication bugs, a misconfigured directive, a bad upgrade — none of it is reachable from an address that can’t open the socket.

This is the highest-leverage SSH control available when you have a fixed administrative address or a bastion. It closes the exposure rather than narrowing it.

Changing the port is not this control

Moving SSH to port 2222 is commonly presented as hardening. It isn’t, and it’s worth being precise about why:

• It does cut log noise substantially. Broad internet scans hammer port 22 and mostly don’t follow to high ports, so your auth log gets quieter.
• It does not stop a targeted attacker. A full port scan finds the daemon in seconds, and the banner identifies it immediately.

Quieter logs have real operational value — it’s easier to see a genuine attack when the noise is gone. Just don’t count it as an access control. If you want the noise gone and the exposure closed, the firewall rule does both, and the port change does one.

If you do change the port, note the ordering trap: add the new rule and verify the new port works before removing the old one.

On Ubuntu 22.10 and newer, the port lives in two places

Ubuntu moved SSH to systemd socket activation in 22.10, which means ssh.socket owns the listener and Port in sshd_config is not the whole story. Check which model you’re on:

systemctl is-enabled ssh.socket

If that returns enabled, a port change needs the socket restarted, not the service reloaded:

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

And to stop it listening on both the old and new port, override the socket explicitly — the empty ListenStream= clears the inherited value first:

/etc/systemd/system/ssh.socket.d/listen.conf

[Socket]
ListenStream=
ListenStream=2222

Verify it worked

Confirm what is actually listening, rather than what the config says:

sudo ss -lntp | grep -E 'sshd|ssh.socket'

Expect exactly one line, on the port you intended.

Then confirm the firewall from outside the host — a rule that looks right locally can still be shadowed by a cloud security group:

# from an address that should be blocked
nc -zv -w 5 your.host 22

Expect a timeout or refusal. If it connects, the rule is not effective.

Before you apply this

A firewall rule is the fastest way to lock yourself out of a remote host, because it takes effect immediately and applies to your next connection.

Before you apply a deny:

1. Confirm your administrative address is stable. A residential ISP address changes; a VPN or bastion address is what you want to allow-list.
2. Keep your current session open. ufw and firewalld do not drop established connections when rules change, so an open session survives a bad rule.
3. Open a second terminal and confirm you can still get in before closing the first.

On a cloud instance, also check the provider’s security group — it is a second firewall, and locking yourself out there needs console access to undo. If you have no console or serial access, do not apply a deny rule remotely.

Related

• Restrict which users can log in over SSH — narrow who, once you’ve narrowed where from.
• SSH exposed to the internet — what you’re actually closing here.