What on earth does a port have to do with a denial of service? Let's play this out, Mr. Spock:

- I have some kind of SSH-specific DoS and will simply enumerate ports until I find SSH, which readily identifies itself right off the bat by nature of the protocol. (No config for that.) Result: DoS successful.

- You deploy fail2ban because someone told you to do so because it makes you "safer." Now I can DoS you in three ways since I know (a) there's a Python regex running on your log and (b) naughty addresses will add a netfilter rule, gradually slowing down each packet as it traverses INPUT. What's that, Lassie? A /16 fell down the SSH port while I inundated fail2ban with failures? (Why do you think fail2ban doesn't have IPv6 support yet? I'm just waiting for [0] since solving the problem is intractable, despite what is common consensus in that community. Oh, you're flattening prefixes? How cute. Watch me find the corner cases in your flattening algorithm since I have several googols of v6 addresses to play with.) Result: DoS successful.

- I grow bored of your mildly annoying countermeasures and simply fire up a reflection attack that targets you with several gigabit/sec of traffic behind the aft nacelle, not caring where your SSH lives. Result: Vastly more probable DoS super successful once your hosting provider null routes you. Add cron to watch for your return. Repeat. Follow you to the new IP when you try that because I will invariably find it (probably when you get back on IRC). Walk over your cold server's corpse while you panic and email CloudFlare who can't help, and you can't afford who can. The end.

Now, shall we begin?

There is a lot of shitty shaman wisdom, some making an appearance in this thread, around the SSH port and logging and yadda yadda that actually makes things less safe for a lot of people who don't know better. Most people move SSH from 22 to something like 2200, forgetting that <1024 requires root so now they're one sshd listener crash or restart race away from a local user intercepting SSH with a malicious binary. Oops.

Correct, and only correct, answer: leave sshd on 22 and get your squishy services off the public Internet or rotate the logs faster. You are a sysadmin with grep and awk. Deal with failures in your log. They are there for a reason, especially if you are exposing sshd to the Internet, and pulling netfilter in or moving ports around is silly TSA-level security theater.

This is all promulgated by those "do these ten things first when you install Ubuntu" guides which capitalize on folks not knowing any better to identify (often faulty) opinion. If you followed one lately it's probably steered you wrong, much like those Learn Sushi Preparation in 24 Hours books. Take the time to understand the problem if you're going to operate services on the Internet and get away from guides. (And yes, I am indicting you for writing one, iff yours includes anything discussed in this comment. Sorry.)

Knocking is the only truly plausible, though still silly, security idea here but even that betrays itself in an nmap by nature of TCP. Also, hope you don't forget your knock when your machine is on fire. (You will.)

It's too bad I'm on the right side of ethical these days or I'd patch all the common SSH scanners to try every port so people will stop doing stuff like this. Some already do.

[0]: https://github.com/fail2ban/fail2ban/pull/1410