Restricting SSH is the highest-value firewall change most environments can make, and the one most likely to end with an engineer locked out of production at an inconvenient hour. Both facts have the same cause: the change removes the path you are currently using to make it.
The technique is not complicated. The order is what matters.
Before touching a rule, pick the model you are moving to. There are three that work.
A bastion host. One small instance accepts SSH from named ranges; every other machine accepts SSH from the bastion's tag only. Cheap, easy to reason about, and the audit trail is in one place. The bastion is a hop, not a workstation — no application software, no long-lived agents, and a short list of accounts.
A VPN into the VPC. Site-to-site or client VPN, with SSH allowed from the VPN range. Better when several people need private access to many services, not just SSH, and it removes the public port entirely.
Office ranges only. Adequate when the team works from fixed addresses and there are few servers. It fails the moment someone needs to fix something from a train, so pair it with a documented break-glass path.
Work from additive changes to restrictive ones, and verify the new path before you remove the old one.
First, build the new path: launch the bastion or bring up the VPN, tag it, and allow SSH to the private tags from that tag or range. At this point both the new path and the existing open port work.
Second, verify it from a session you did not open through the old path. Open a second terminal, connect through the bastion — ssh -J bastion app-01 — and run something. Do not skip this because the config looks right. A wrong key on the bastion, a missing agent-forwarding setting or an SSH daemon bound to the wrong interface all look identical to a correct setup until you try.
Third, and only then, narrow the old rule. Change inbound 22 on the private tags from 0.0.0.0/0 to tag: bastion. Keep your verified session open while you do it — a stateful firewall does not tear down established connections when a rule changes, so you keep a live shell to undo from if something is wrong.
Fourth, confirm the negative. From a machine outside, try to reach 22 on an application instance directly. It should time out. If it refuses instead of timing out, something in front is answering and you have not restricted what you think you have.
Every restriction needs a documented way back. What you must not do is leave a permanently open port "just in case" — that is the rule you were trying to remove.
The workable options: console or serial access through the provider portal, which needs no network path at all and is the reason to check your instance password is in the password manager before you need it; a second bastion in another region, stopped, that you start only during an incident; or an emergency firewall rule you can apply from the portal or API in seconds, with a note that says who may apply it and when it must be removed.
Test the break-glass path once, deliberately, on a machine that does not matter. An untested emergency path is a story you tell yourself, not a plan.
Network policy limits who can reach the port. It does not fix what happens after they do. Keep the host side boring: keys only with PasswordAuthentication no, no root login, one account per human, and keys with a passphrase so a stolen laptop is not a stolen server.
Fail2ban and moving SSH to a high port become largely pointless once the port is not exposed to the internet — the noise they were suppressing no longer arrives. Spend the time on key hygiene instead.
Choose bastion, VPN or fixed ranges. Build the new path, verify it from a fresh session, then narrow the old rule while holding a live shell. Confirm the port really is unreachable from outside, and write down a break-glass path you have actually tested.
Antyxsoft Cloud Firewalls let you allow SSH from a bastion tag or a named range and drop everything else, applied at the platform edge with nothing to install in the guest — see how Cloud Firewalls work.