OpenSSH introduces options to penalize undesirable behavior

Original Article ↗ Hacker News Discussion ↗

OpenSSH is adding built‑in rate‑limiting and penalty options to slow or block clients that repeatedly fail authentication, aiming to reduce brute‑force SSH attacks without relying on external tools. Commenters compare the feature to fail2ban and similar firewall‑based approaches, debating whether such logic belongs inside sshd, how it interacts with IPv4 CGNAT and IPv6, and whether it may create new denial‑of‑service or lockout risks. A recurring theme is that robust SSH key–based or hardware‑backed authentication, often behind VPNs like WireGuard or Tailscale, remains more important than password hardening and per‑IP penalties, which are seen as defense‑in‑depth and log‑noise reduction rather than a primary security control.

Feature and Relationship to Fail2ban / Firewalls

  • Many see the new OpenSSH penalties (PerSourcePenalties, PerSourceNetBlockSize, etc.) as built‑in “fail2ban‑like” behavior.
  • Some welcome having this directly in sshd: fewer moving parts, no regex log parsing, no Python daemon changing firewall rules.
  • Others argue it violates “do one thing well”; they prefer centralized tools (fail2ban, iptables/ufw throttling, xt_recent, Crowdsec) that can protect multiple services.
  • There is concern that embedding more logic in sshd increases complexity and the surface area that can break or misbehave.

Security Posture: Passwords, Keys, Certificates, MFA

  • Strong consensus that Internet‑facing SSH should avoid password-only auth; keys, hardware tokens (FIDO2/Yubikey), or SSH certificates are favored.
  • Some argue strong passwords plus basic rate limiting are still adequate; others call passwords “obsolete” and too easy to steal or reuse.
  • Debate over usability: keys and hardware tokens are more secure but less convenient for ad‑hoc access or when devices are lost.
  • SSH certificates and CAs are praised for scalability but criticized for complex revocation and distribution processes.

CGNAT, IPv6, and Risk of Lockouts

  • Several worry per‑IP or per‑subnet penalties will punish innocent users behind CGNAT or large shared IPv6 blocks.
  • Attackers with botnets can rotate IPs or subnets, reducing the effectiveness of per‑source penalties.
  • Risk: a compromised host in the same NAT/subnet could effectively lock a legitimate admin out of their own server.
  • Exemption lists and careful netblock sizing help but don’t fully remove this risk; enabling by default is seen as especially dangerous.

DDoS, Stability, and Do‑Nothing vs. Layered Security

  • Past experiences: fail2ban causing huge iptables tables, high memory use, and even turning into a DDoS amplifier.
  • Some view this feature as another partial, potentially abusable mitigation rather than a robust anti‑botnet measure.
  • Others emphasize defense‑in‑depth: even if keys are used, penalties still reduce log noise and slow down opportunistic attacks.

OpenBSD/OpenSSH Philosophy and Alternatives

  • Debate over whether OpenBSD/OpenSSH add too many knobs instead of removing risky features (e.g., password auth, legacy ciphers).
  • Counter‑argument: OpenBSD actually removes a lot of code and features; portable OpenSSH must serve diverse platforms and needs.
  • Many suggest alternatives or complements: VPN/WireGuard/Tailscale fronting SSH, nonstandard ports, bastion/jump hosts, Kerberos/SSO.