Dozens. Maybe hundreds. But they can't get in as they don't have the key.

change port.

After years of cargo-culting this advice—"run ssh on a nonstandard port"—I gave up and reverted to 22 because ssh being on nonstandard ports didn't change the volume of access attempts in the slightest. It was thousands per day on port 22, and thousands per day on port anything-else-i-changed-it-to.

It's worth an assessment of what you _think_ running ssh on a nonstandard port protects you against, and what it's actually doing. It won't stop anything other than the lightest and most casual script-based shotgun attacks, and it won't help you if someone is attempting to exploit an actual-for-real vuln in the ssh authentication or login process. And although I'm aware the plural of "anecdote" isn't "data," it sure as hell didn't reduce the volume of login attempts.

Public key-only auth + strict allowlists will do a lot more for your security posture. If you feel like ssh is using enough CPU rejecting bad login attempts to actually make you notice, stick it behind wireguard or set up port-knocking.

And sure, put it on a nonstandard port, if it makes you feel better. But it doesn't really do much, and anyone hitting your host up with censys.io or any other assessment tool will see your nonstandard ssh port instantly.

Conversely, what do you gain by using a standard port?

Now, I do agree a non-standard port is not a security tool, but it doesn't hurt running a random high-number port.

> Conversely, what do you gain by using a standard port?

One less setup step in the runbook, one less thing to remember. But I agree, it doesn't hurt! It just doesn't really help, either.

it did for me.

I've tried using a nonstandard port but I still see a bunch of IPs getting banned, with the added downside of if I'm on the go sometimes I don't remember the port

Underrated reply - I randomize the default ports everywhere I can, really cuts down on brute force/credential stuffing attempts.

or keep the port and move to IPv6 only.