I know who I am arguing with here but port knocking is not silly. It's fantastic.
When I say fantastic, I don't mean it solves all of our problems and obviates any other protections ... what I mean is, for almost zero cost[1] it adds a non-zero level of actual protection.
As a lifelong UNIX sysadmin, it is one of the few totally unalloyed security improvements that I have been able to add to my systems. I believe there are sshd vulns extant that you and I don't know about and port knocking allows me to worry less about them.
I also recommend SMS alerts on successful knocks - SMS alerts that you should never see in surprise. This is trivial, by the way, as you can put semicolons in the knock command:
/sbin/ipfw add 01021 allow tcp from %IP% to 10.0.0.10 22 setup ; /usr/local/sbin/timestamped_sms 4155551212 "knock from %IP% - "
If you believe there are unknown OpenSSH attacks, you can't coherently believe that port knocking is a real defense, since port knocking doesn't do anything to protect the SSH channel that attacks will be carried out in.
Instead, if you're actually worried about OpenSSH vulnerabilities, you shouldn't be exposing SSH to the public Internet at all. I'm not super worried about OpenSSH server vulnerabilities, but I would never recommend that teams leave SSH exposed; they should just hide that stuff behind WireGuard.
Wrong, it solves tons of them.
>adds complexity and cost
Almost zero complexity and cost. Maybe if you're a bad at sysadmin work it adds cost and complexity.
>defense without corresponding increases to attacker costs.
It adds a _huge_, almost incalculable cost increase to attackers.
>If you believe there are unknown OpenSSH attacks, you can't coherently believe that port knocking is a real defense, since port knocking doesn't do anything to protect the SSH channel that attacks will be carried out in.
Looks like you don't understand the concept of 0-days. Several CVEs we're listed elsewhere. I suggest researching 0-day exploits so you understand how port knocking mitigates them.
Port knocking mitigates 0-days.
>Instead, if you're actually worried about OpenSSH vulnerabilities, you shouldn't be exposing SSH to the public Internet at all.
I don't disagree here, VPN is a great solution. Nonetheless, for some shops simple port-knocking on a bastion host solves, a lot of these issues, and removed the complexity that VPNs add.
>I'm not super worried about OpenSSH server vulnerabilities, but I would never recommend that teams leave SSH exposed; they should just hide that stuff behind WireGuard.
No one is super worried about things like shellshock, heart bleed, etc. until they happen.
Port knocking solved a lot of problems, protects you from zero-days, and makes SSH noise a non-issue (huge signal-to-noise gains).
Used in production for years. It's fantastic.
All it takes is me somehow being able to listen in on your traffic - not even decrypt it - and now I know the knock sequence. I know that you have SSH listening on that server. I know you are actively doing something on it.
vs. a VPN where... all I know is you are communicating over a VPN. With DPI I might be able to determine what type of traffic you're sending, but not where it is ultimately going.
Port knocking is not the christ child that will wash away all of our sins ... and therefore is not worth implementing.
You're right!
It doesn't add that much. But it's non-zero and has almost zero cost. It's very elegant, in my mind, and it makes me very happy.
I do agree, nobody should be going to sleep at night, relying solely on obscurity as their source of protection. But these commenters are offering it as an additional layer of indirection. They're not touting it as _the_ solution, full stop.
At the most basic level, would you refute the claim that port knocking or alternate ports are adding additional friction for an attacker, or no?
Myself, I would prefer to run a simple, (hopefully) set-and-forget daemon on my server if it really did add an extra layer of obscurity to my secured SSH service.
I guess I just fail to see why it's one against the other.
Foremost, there is an opportunity cost to setting it up. The time you spend setting up port knocking could be spent setting up another form of security. I believe it is a sound argument to say that a VPN provides more security at a similar level effort. No public SSH means an attack cannot know SSH is running on the server from a port scan because it simply isn't listening. It allows you to reduce the attack surface - you can add more and more servers that you need to SSH into, but you are only allowing public access via your VPN - so you have fewer potential ingress points, and can ratchet up your security and auditing commensurately. And if your VPN concentrator is owned, you should have been setting things up so that they did not implicitly trust someone just because they were on the VPN, so you still have all of your usual measures of security in place.
In that case, there's just not much point. You could also enable port knocking, but I don't think it provides much benefit.
That brings us to the next part. Port knocking is a "weird" thing. It's idiosyncratic and not standardly used. Documenting it and understanding it is additional overhead, and it's something you have to manage and worry about on every server that's using it. Additionally, both standard and SPA implementations are vulnerable to man in the middle attacks, though most SPA based implementations will require an active MITM in that blocks the initial packet rather than just replaying a knock sequence. So extra complexity, less secure, and an oddity on the network that you have to have documented and explain to new team members, etc.
If you're a single person managing a single server, well, honestly you're probably fine just turning off password auth. And you can feel free to do port knocking and whatever else. It probably doesn't matter.
It sounds like port knocking and VPNs, while starkly different in approach, have some overlap in their approach to threat mitigation.
Wireguard et al are much better equipped to handle the needs of an organization, while port knocking's value trends to smaller teams, or even individuals.
I wouldn't want to manage knock rotations for 600 employees, for example.
* A Java, Python, or Ruby app server
* OpenVPN
* Stock nginx
----- starts to get really unlikely right here ----
* The Linux IP stack
* WireGuard
I can't comment on that.
I'm not a UNIX sysadmin because it's a rewarding career path with excellent opportunities for advancement.
I'm a UNIX sysadmin because I truly love doing it and always have. I would do it for free.
I think the reason I continue to prefer (and evangelize) port knocking is that the intersection of (modest) security gain and simplicity/robustness hits a sweet spot for me.
Again, 10+ years in production on many hosts, worldwide, and never so much as a blip. IF knockd were to fail, it would fail in a very boring way. VPNs, on the other hand, are far more complex and they fail in fascinating ways.
I am a sysop turned sysadmin - this is my lifes work. I prefer simple, unixy tools that fail in boring ways :)
Simple systems tend to fail in boring ways. Complex systems tend to fail in interesting ways. Learning more about a complex system, while rewarding in many ways, will not change that identity.
While I fully agree that portknocking doesn’t provide the same layer of protection or flexibility a VPN does - but with the original article in mind: if your reason for deploying a VPN is because you fear to expose unknown bugs in sshd to the Internet the same could be said about every vpn solution.
Therefore portknocking is / (would be*) indeed more elegant because
- it makes no promises to be secure (as in as secure as a VPN) - one could argue: if you use it you know that portknocking is just an additional security layer - and maybe don’t get lazy as in a VPN - a misconfiguration or bug or an attacker might expose sshd on your hosts - a misconfigured VPN at least in a somewhat sizeable deployment can lead to countless attack surfaces
Having said that, that only will work if the rest of the sshd security is in check and your password isn’t hunter2
>f your reason for deploying a VPN is because you fear to expose unknown bugs in sshd to the Internet the same could be said about every vpn solution.
Yeah. You might have a VPN zero day - but then you still have to get into the other SSH servers. Two zero days simultaneously active for openssh and your VPN solution? Pretty unlikely, especially public ones. Someone burning two private zero days on you means you're an incredibly high value target and neither of these would suffice as your sole defense to begin with.
The rest of your argument, if I'm understanding it correctly, is that you think people will get more lax with securing SSH on a box only reachable via VPN than if it was reachable by port knocking? It's possible, but I don't know that the evidence really shows that - lots of comments on this article are along the lines of "i set up port knocking and I've never even seen a malicious ssh connection attempt since then!" - no details of the rest of the security measures they've got in place.
And yeah, going from 'I set up a VPN to connect to my web servers via ssh' to 'I have VPN access to a whole network with all sorts of things running on it' is a big step up, but I don't think it's really in the boundaries of this discussion. Port knocking was never going to be a replacement for a larger VPN deployment, and when you're opening up network access to a wider range of things then how you approach things definitely needs to change.
So yes, if we want to be fair we have to compare an in-host defense system like portknocking (which has one job: secure sshd) to a in-host vpn setup more alike to like the often mentioned wireguard.
And in this "configuration" I completely agree. I still think it may be more likely for a VPN to expose security critical bugs than a bug in knockd - but as you said this should only allow access to your next layer of defense (namely sshd) and maybe (if you're a really valuable target) a three-letter-agency might throw all their resources at you and are willing to throw every weaponized exploit they have at you - yeah than you're even more correct because than they would have a far easier time just intercepting your port knock sequence and throwing all their quantum computation power against your sshd keys.
> The rest of your argument, if I'm understanding it correctly, is that you think people will get more lax with securing SSH on a box only reachable via VPN
The argument I was trying to make is that while a VPN is in in every way a really good idea (the way we described it here - as an in-host security layer) but I have yet to see it being rolled out in that way.
I come from a more traditional sysadmin setting, and of most sysadmins I worked with would find implementing this "correctly" to tedious and would either
a) terminate the vpn connection at the rack or co-location "border" and shove a bunch of servers down a single VPN connection b) terminating every servers vpn connection at a single vpn concentration point
Regardless of which, in virtually all cases that I know of never was there any thought given about intra-VPN firewall rules or allowing only certain ports on the VPN. Most of the time you get the servers that are somewhat related, shove them in a subnet expose that subnet via VPN and you're golden.
And so from my practical experience, I would think that a compromised VPN in my reality would be worse than a exploited knockd, but only because it isn't scoped to the same level.
On a sidenote: I'll guess that modern orchestration tools make it pretty easy to roll out knockd and / or wireguard pretty easily in the discussed fashion - it's just I don't get to play with those.
That was a lot of text, just to say I agree with you - but hey, I guess agreeing on something on the internet is somewhat nice so have a great day.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openvpn
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pulse+secur...
VPN doesn't magically fix all problems.
wireguard is good so far, but the kernel implementation is in C, so who knows.
I do agree with the author of the original article that security should come in layers
Once something is secured with SSH and a VPN, you've got that many more actual layers - you now need a CVE that allows access or credential leak for both the VPN and SSH. (And many of those CVEs don't necessarily allow a random attacker to arbitrarily gain access)
https://news.ycombinator.com/item?id=24446919 has my list of what the bare minimum SSH protections should be for anything where you are storing customer/user data in my opinion, as well as additional best practices that I have employed.
Can a theoretical attacker intercept a port knocking sequence? maybe. Would a script kiddie running a new ssh 0day against the entire internet be able to do this? no.
If it's your private pet server - sure. In larger networks you have to document the access, manage the allowed ports on the network, configure security groups or equivalent on instances, provide alternative steps for people with unusual clients (for example database UI app proxying over SSH), etc. The cost suddenly becomes very non-trivial.
That's interesting, that's the first time I've heard a justification for port knocking that actually makes sense to me.
I'm curious for others' thoughts here -- are non-public vulnerabilities something you consciously try to mitigate? So that, for example, using 2 different 8-character passwords that are implemented with different technologies, is therefore fundamentally more secure than a single 16-character password? Precisely so that a vulnerability in one is still protected by the other?
To me this feels like it's really only applicable if you need to protect your data from hostile governments targeting you specifically, who might actually have zero-days they have weaponized.
However, if you're just trying to protect yourself from everyday hackers or even targeted corporate espionage, is unknown vulnerabilities really something that's realistically worth protecting oneself from? (Assuming you're always installing all security patches.)
Sure, a small percentage of adversaries are in neither category, and a random hacker dedicated to hitting your specific server may suspect port knocking and could try to circumvent it, but most companies don't have an adversary like that, and even if they do, you've made it harder for them for a small cost.
Does it solve anything else?
> I believe there are sshd vulns extant that you and I don't know about and port knocking allows me to worry less about them.
Wouldn't you need to worry about vulnerabilities in knockd?
CVE-2001-0144 - SSH1 CRC-32 compensation attack detector allows remote attackers to execute arbitrary commands on an SSH server or client via an integer overflow
CVE-2008-0166 - OpenSSL 0.9.8c-1 up to versions before 0.9.8g-9 on Debian-based operating systems uses a random number generator that generates predictable numbers, which makes it easier for remote attackers to conduct brute force guessing attacks against cryptographic keys.
I had a machine almost get compromised from the 1st vulnerability ( noexec on /tmp broke their script ). When the 2nd came out I was using non standard ports and or port knocking. Despite having vulnerable keys I was safe until I could upgrade.
If a SSH RCE 0day was released:
* every "Just use SSH keys, and disable passwords" box sitting on the internet with ssh on port 22 will get compromised within hours.
* The boxes using fail2ban will get compromised within hours.
* The majority of boxes on nonstandard ports would likely be ok, at least for some time.
* The boxes using port knocking would be safe.
Having said that: I don't like exposing SSH services either! Which is why I try to keep them behind WireGuard, at least on prod networks that I care about.
In contrast to an actual VPN, port-knocking and (heh) nonstandard SSH ports shield you only from casual attackers; both give a middlebox attacker all the access they need to launch the attack.
Port knocking isn't a terrible idea but I generally prefer locking down the networks (or, these days, using AWS SSM / GCP IAP to avoid listening publicly at all) since having something on the internet means you're just one mistake away from problems and need to staff monitoring accordingly.
The other thing to remember here is that we're talking about one general CVE in two decades. Almost any other running service has been much worse so while SSH is important to protect I don't know that I'd make the argument that further pushing that one service is really the best bang for your buck.
Possibly.. It does depend on the port. 222 and 2222 often are scanned with 22. 2200-2299 is probably common now. I was using 2221 for a bit but after a few years that started seeing some auth attempts.
I mostly watched entire /16s, not single hosts.. the scan patterns for a large netblock are very interesting. It takes as much effort to scan the entire internet on port 22 as it does to scan all ports on a /16.. attackers simply do not do that.
The benefit of some of the port knocking systems is that the attack surface is almost nothing and they are easy to audit. I used it a few jobs ago on my management system/bastion host. I couldn't rely on the VPN since I was the one that managed the VPN, so I needed a way to securely login remotely that did not go through the VPN, and did not end up having sshd exposed to the world.
These days I run sshd at home behind https://www.tarsnap.com/spiped.html
Ubiquitous wireguard may change things.. we'll see.
Not in my experience, I would even say that full range port scanning is extremely rare. Botnets (again, in my experience) seem to only be interested in vanilla installations and will test standard ports exclusively. But of course, if you are in charge of some very tempting target (eg a cryptocurrency exchange) your experience will be totally different than mine.
No, safer. It is very well possible to brute-force port knocking or eavesdropping the ports since that information is not encrypted. Is it harder? Of course, a lot, but if you think scanning 65k ports on each host on the internet is reasonable, then evading a port knock is very much, too.
It's incredibly unlikely - there is probably more chance of the sun imploding tomorrow. And if you're the type to install port knocking, you've almost certainly also installed something like LFD, which will temporarily block IPs for port scanning.
Also, without inside information, how would you even know that a server was using port knocking?
> unlike
But brute forcing in general? not a chance. There are 18446744073709551616 4 port sequences.
Here, for comparison:
281474976710656 - total ports in IPv4 space
18446744073709551616 - 4 port combinations
1267650600228229401496703205376 - my estimation for 22 in IPv6
I’d say cracking that is… Unfeasible.
That also assumes you know the existence of a server on which there is ssh under an unknown combination of port knocking of length 4.
Moving the port to some obscure random one divided the number of requests from several thousands per hour to a few per day. Definitely an improvement by any measure : suddenly you can analyze the attacks if necessary.
I run fail2ban on top of it, because why not? In case someone would attempt to really target my system, any obstacle is good to take. And who knows what ssh vulnerabilities exist; any protection is good to take.
I usually have several cloud servers running with a normally secured SSHD running. There's some failed login attempts yeah. I've never seen even 1% CPU usage from them. I doubt even posting my server address on every hacking forum I could find and daring them to try and hack me would result in getting enough failed SSH login attempts to blip my CPU usage. I have no idea how that could even happen, aside from somebody intentionally targeting your server with a really weird attack for whatever reason.
Reducing log clutter alone probably does confer some small indirect benefit, since it's less likely a more sophisticated attempt or successful breach would go unnoticed when inspecting logs. (Assuming there's some SIEM log forwarding or that it's not a situation where an attacker was able to or wise enough to wipe logs.)
Example:
* Use RSA keys instead of passwords -> This will eliminate most risk, except for exploits in sshd itself,
* Change the default port from 22 to something in the 40k+ range, which will keep you from being scanned, and
* Whitelist IP addresses that can connect to port xx on your server -> This will eliminate 95% of remaining risk
* Using a 'clean' bastion server to access other systems via agent-forwarding, preventing malware on admin workstations from being able to propagate over SSH.
So, no you're never going to be 100% secure, that's just unreasonable. But like you said, the cost can be increased to the point that all but the most determinted state sponsored APT groups.
I'm replying to these suggestions all over this item because I think it's important, so I apologize if you've since seen this comment elsewhere, but:
This introduces new security risks. Non-privileged users can bind on ports in the 40k+ range and cannot bind on 22. If you restart sshd for a software upgrade or some other reason, or the iptables rules you're using to remap the ports get flushed, the malicious non-privileged user can now bind to the port people were communicating with your sshd on, and if they ignore the host key mismatch, everything they send can be captured by the malicious user.
Older openssh clients have default configurations that can result in the leak of the whole private key, if you use password auth or 2FA they can outright steal those, perhaps their fake sshd will do more than just steal credentials and will actually mimic a shell and let them gain more understanding of how the system ticks, etc.
Is this level of attack something most people are going to run into? No. But neither is an attack more sophisticated than brute force password attempts. It's definitely information people should be keeping in mind when making these sorts of decisions, too.
My firewall does port mapping so externally it's not 22, but internally it is.
There's still public access to SSH, so you're still at risk from a zero day, weak credentials, etc., so I don't think it's quite to ideal levels where you are employing a VPN, disallowing all public access, etc., but at least you're not introducing new potential attack vectors :)
To gain access to the server via SSH they now need both a way in to the VPN and a way in to SSH, vs. just needing a way in via SSH.
It doesn't do much if someone just gives up the keys for the VPN and SSH, but it would mean that you would need two simultaneous exploits for the VPN and SSH to gain access.
In scenario 1, you do not gate access via VPN. Things are accessible via the public internet.
In scenario 2, you do gate access via VPN. Things are not accessible via the public internet. Someone compromises the VPN. They now have as much access as if there was no VPN and things were accessible to the public internet.
In scenario 2, you are more secure than in scenario 1 until the VPN is compromised. You are then just as secure as you were in scenario 1.
If you are not restricting access to a VPN in the first place, how would compromising a theoretical VPN result in greater access?
Of course if the setup is VPN -> firewall -> SSH to make sure only the SSH is exposed through VPN, then I agree you'd be more secure with VPN+SSH.
In the discussion we're having, we're going from a setup where there is no equivalent to a private network because everything is public, to having a private network that only allows you access to the things that were previously public.
So either only SSH is exposed to the public, or only VPN is exposed. Without an additional firewall after the VPN, how is my LAN more protected with the VPN vs SSH?
With your configuration, all that needs to exist is an SSH 0 day to gain access to the server. With a VPN, they need that AND a 0 day for the VPN software to gain access to the server.
You can have a more complex setup with a VPN, but that isn't the discussion here - the discussion is securing SSH. If you want to provide VPN access to an array of other services, or as access to a corporate LAN or similar, then that's another conversation that has to involve the specifics of those services and that configuration. It's not what is being recommended here.
The other thing to consider is that there could be exploits in OpenSSH itself. There hasn't been a truly critical vulnerability in a very long time, but low severity or non RCE vulnerabilities aren't exactly rare: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh
Almost barfed from sheer intensity of tech corpobabble. Its for blocking 0-days dummy!
I'd say that matters. Think about all the secrets (tls keys, whatever) a server has in memory.
If you can't connect to the sshd daemon, you can't attack it.
I’m not sure there is any such good example though. Every obscurity control I’ve ever seen has imposed costs upon the users, administrators, engineers... but I’ve never seen one that I would rely on to improve security posture in any meaningful way.
I’ve certainly never seen an obscurity control that was worth its opportunity cost. I can think of dozens of actually useful controls where even a marginal improvement in operational performance would be worth more than every conceivable obscurity control combined.
Exactly! Especially when you can create a high cost asymmetry, low-cost for you to add, high cost for the attacker to bypass.
Agree that the SSH examples aren't the best. I would have picked DRM.
I would like to see a list of suggestions of "low cost" ways to obscure systems that are (relatively) harder to counteract. But I guess as soon as anyone publishes such a list then hackers will start checking for them.
Or even use a good password, if you don't have many untrusted users. It works perfectly.
Changing the port is not silly, it increases the SNR in logs, that's already a worthy goal.
You, uh, do know who you're replying to, right? https://sockpuppet.org/me/ if not - I don't mention this to go "lol he must be right because of who he is", but calling a well respected security researcher with plenty of real world street cred ignorant is a bit much.
>SPA port knocking is cryptographically secure and does not suffer from replay attacks.
SPA port knocking doesn't suffer from passive replay attacks, but it does suffer from block and replay attacks. An active MITM can still get you.
His suggestion hasn't been "if you care about security just don't do port knocking", his suggestion has been "if you care about security just throw up a VPN it'll be more secure and just as much work"
Care to elaborate? Not even fwknop documentation claims to be secure from all mitm attacks:
>Automatic resolution of external IP address via cipherdyne.org/cgi-bin/myip (this is useful when the fwknop client is run from behind a NAT device). Because the external IP address is encrypted within each SPA packet in this mode, Man-in-the-Middle (MITM) attacks where an inline device intercepts an SPA packet and only forwards it from a different IP in an effort to gain access are thwarted.
If I'm MITM'ing you from the same Starbucks or am otherwise behind the same NAT as you, I don't care if you've got the IP encrypted in the packet when I forward it on.
>Not the same amount of work, so no, wrong. If I had a dollar for every billion dollar unicorn that that didn't have a corporate VPN, I'd have a lot of dollars.
There's not enough billion dollar unicorns out there to actually have a lot of dollars, even if 100% of them lacked corporate VPNs :D
Regardless, you don't even need a full on corporate VPN. You can throw up a tiny VM for your VPN in the same private subnet as your servers, only listen on 22 on the private IPs for the servers. You can do this in less than an hour with Wireguard. Super easy.
You made the claim. You prove it with documentation.
>If I'm MITM'ing you from the same Starbucks or am otherwise behind the same NAT as you, I don't care if you've got the IP encrypted in the packet when I forward it on.
That is by definition NOT a MITM attack.
>There's not enough billion dollar unicorns out there to actually have a lot of dollars, even if 100% of them lacked corporate VPNs :D
The example is only billion dollar ones. If I include +$10m+ ones, I'd have enough to dollars to buy a new laptop ;D!
>Regardless, you don't even need a full on corporate VPN. You can throw up a tiny VM for your VPN in the same private subnet as your servers, only listen on 22 on the private IPs for the servers. You can do this in less than an hour with Wireguard. Super easy.
You just described a bastion host, and port knocking makes sense on those as well LOL. Wireguard only currently supports UDP, which can and had been a limitation in the past.
I... er, did?
>That is by definition NOT a MITM attack.
You're intercepting the packet and blocking it by being in the path.
>You just described a bastion host, and port knocking makes sense on those as well LOL. Wireguard only currently supports UDP, which can and had been a limitation in the past.
Bastion hosts are generally SSH/RDP/VNC type affairs. SSH in to the bastion and then you have access to the other servers. This is actually how I set things up in production environments - the VPN concentrator only allows access to the jumphosts, and then there's extensive logging and auditing there.
I'm not sure why Wireguard only supporting UDP would be a problem - you can pass whatever type of traffic inside of the tunnel.
You... Ugh... Didn't? You claimed that it suffers from MITM attack. You are not able to prove that it suffers from any MITM attack (the docs specifically outline a way to mitigate a specific MITM attack, but do not outline any others). Unless you have a source that states otherwise, you're wrong.
>You're intercepting the packet and blocking it by being in the path.
Wrong, that is by definition not a MITM attack.
>Bastion hosts are generally SSH/RDP/VNC type affairs. SSH in to the bastion and then you have access to the other servers.
Correct, and you set up port knocking for these. Thanks for proving my point.
>This is actually how I set things up in production environments - the VPN concentrator only allows access to the jumphosts, and then there's extensive logging and auditing there.
There should be extensive logging and auditing on the bastion host. Port knocking reduces the noise to effectively 0.
>I'm not sure why Wireguard only supporting UDP would be a problem - you can pass whatever type of traffic inside of the tunnel.
There have been multiple instances where UDP has been block at sites in the past. Looks like you're ignorant to this. Look up why OpenVPN supports TCP.
But SSH is a terrible example, because the cost to the defender of simply not having SSH vulnerabilities is the same, or even less, than the cost of obfuscating it with nonstandard ports, "port knocking", or fail2ban, which are all silly ideas.
Just use SSH keys, and disable passwords.
I think maybe it comes down to this: dialing attacker costs up incrementally can make sense if it's the most cost-effective way for a fully-informed defender to improve security. But incremental cost-increasing countermeasures aren't a substitute for sound engineering; you don't get to count "having to learn stuff" as a valid defender cost.