I suspect the distributed cracking will move to the same pattern as the SMTP/pop3 brute force guys did and use one IP per x+1 seconds where x=the ssh penalty window. We have seen this on our customer facing smtp server where we have hundreds of remote compromised IPs trying each one password per 30-60min. Still, I welcome this change as there are enough single prick attackers out there where this will help cut down on the size of the logs to process / digest.
For what it's worth if you have control over both client and server and don't want to limit access using a strict IP whitelist, an alternative solution that will keep your logs quieter and add additional protection is to use good old fashioned port knocking. knockd on Linux helps with automating this on the server side. Client side you can use anything (although knockd does include a dedicated client) to send your sequence of packets before actually connecting.
How about a service that lets bruteforcers "in" after some number of failed attempts, but what they get is just a fake command prompt that accepts all of their commands? I'm sure hackers would eventually adapt, but it would annoy them for a while.
This thread has some mentions of memory-safe issues. Has anyone tried a Go or Rust sshd in their production?<p>I've had some dreams of a "tighter" sshd for my universe and have toyed (unsuccessfully) with a Go one.<p>Anyone want to share their experience?
Hem... There is PerSourcePenaltyExemptList to whitelist specific hosts so while I agree it might create a bit more complexity (not much different than handling fail2ban and co) it's not "blocking" like described.
PerSourcePenalties-like abuse mitigations are not very subtle, but often <i>very</i> effective.<p>My own experience with this is not as much with SSH as with SMTP. If your particular IP emits a single non-deliverable message every 30 minutes or so, that's fine.<p>But: more than a handful of SPF failures for the same sender/recipient combo within 10 minutes or so? Yeah, you're now on the general-deny-list. And persisting even then? Automagically tar-pitted on the firewall, and have fun...
I wish the openssh folks would implement a UDP based "whole auth key or no talk at all" protocol.<p>ie Single Packet Authorization<p>Wrapping your ssh with wireguard (because wireguard doesn't respond without a full key) doesn't feel too good.