2 ms·

> Rate limiting You don't need fail2ban to rate-limit SSH. RFTM ... MaxStartups, PerSourceMaxStartups, PerSourceNetBlockSize. > trying to brute force

> Rate limiting You don't need fail2ban to rate-limit SSH. RFTM ... MaxStartups, PerSourceMaxStartups, PerSourceNetBlockSize. > trying to brute force AuthenticationMethods publickey PasswordAuthentication no ChallengeResponseAuthentication no PermitRootLogin no

theteapot 4y ago
> (not just SSH) ... We know about the SSH daemon config. You still get all sorts of probing that isn't a brute force on SSH.
- nix23 4y ago
  Exactly, fail2ban/blacklistd is for software who lacks certain function ssh has for example sendmail, asterisk etc: https://github.com/fail2ban/fail2ban/tree/master/config/filter.d https://github.com/fail2ban/fail2ban/tree/master/config/filt...
tlamponi 4y ago
Not disagreeing in general and disallowing password login for root is IMO really a no-brainer. But, it's nonetheless a fact that a (temporary) nft drop rule in the kernel is much more effective than traffic hitting a user space daemon like SSH. Some NICs even allow offloading that (e.g., in form of a bpf program) to the card itself, so that such traffic won't ever hit the system (CPU) at all. So yes, SSH can be made secure and rate-limited without anything else, but that won't be the most efficient solution; now fail2ban/sshguard/... ain't no free lunch either, so one needs to weight the added (IMO small, but still) complexity against benefits in a specific use case.
BoardsOfCanada 4y ago
Just to double check my sshd settings I logged in to a server I have, and while it had "PasswordAuthentication no" set in the normal place in the config file, there was a line added to the very end of it "PasswordAuthentication yes", which I guess overrides the previous one. The server is reinstalling the OS right now...
- pferde 4y ago
  FWIW, your guess is incorrect. From sshd_config(5): "For each keyword, the first obtained value will be used." Still, if you cannot explain how that second line got in there, it is probably prudent to reinstall (perhaps even reflash BIOS).

theteapot 4y ago

> (not just SSH) ... We know about the SSH daemon config. You still get all sorts of probing that isn't a brute force on SSH.

nix23 4y ago
Exactly, fail2ban/blacklistd is for software who lacks certain function ssh has for example sendmail, asterisk etc: https://github.com/fail2ban/fail2ban/tree/master/config/filter.d https://github.com/fail2ban/fail2ban/tree/master/config/filt...

tlamponi 4y ago

Not disagreeing in general and disallowing password login for root is IMO really a no-brainer. But, it's nonetheless a fact that a (temporary) nft drop rule in the kernel is much more effective than traffic hitting a user space daemon like SSH. Some NICs even allow offloading that (e.g., in form of a bpf program) to the card itself, so that such traffic won't ever hit the system (CPU) at all. So yes, SSH can be made secure and rate-limited without anything else, but that won't be the most efficient solution; now fail2ban/sshguard/... ain't no free lunch either, so one needs to weight the added (IMO small, but still) complexity against benefits in a specific use case.

BoardsOfCanada 4y ago

Just to double check my sshd settings I logged in to a server I have, and while it had "PasswordAuthentication no" set in the normal place in the config file, there was a line added to the very end of it "PasswordAuthentication yes", which I guess overrides the previous one. The server is reinstalling the OS right now...

pferde 4y ago
FWIW, your guess is incorrect. From sshd_config(5): "For each keyword, the first obtained value will be used." Still, if you cannot explain how that second line got in there, it is probably prudent to reinstall (perhaps even reflash BIOS).