OpenSSH introduces options to penalize undesirable behavior

Original Article ↗ Hacker News Discussion ↗

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.