fail2ban vs CrowdSec vs Turning Off Passwords: How to Actually Protect SSH

Every server with SSH on the internet logs thousands of failed logins a day, and the reflex is to install fail2ban. It helps, but it answers the wrong question. Interviewers like this topic because it separates people who know which control does the protecting from people who know tool names.

What the tools do

fail2ban reads logs through jails: a filter extracts the source address from failure lines, and after maxretry failures within findtime it bans the address for bantime with a firewall rule. CrowdSec turns logs into events, runs leaky-bucket scenarios to make decisions, and hands them to bouncers that enforce at a host firewall, nginx or a CDN. It can share the addresses it bans and subscribe to a community list, which is a data flow to decide on deliberately.

What neither stops

• A correct stolen password or key: success writes no failure line.
• Guessing spread across thousands of addresses, each staying under the threshold.
• IPv6 attackers rotating through a /64 unless you ban by prefix.
• A bug in sshd itself exploited before authentication; the 2024 regreSSHion flaw (CVE-2024-6387) was exactly that.
• Attacks through a CDN or load balancer, where the logged address is the proxy unless you parse the forwarded header from trusted proxies only.

What actually protects SSH

1. PasswordAuthentication no and KbdInteractiveAuthentication no, no direct root login.
2. SSH reachable only through a VPN, a mesh network or an identity-aware proxy, not the open internet.
3. At scale, SSH certificates: short-lived, issued after SSO and MFA, with principals per role, and host certificates so clients stop trusting fingerprints on first use.
4. Hardware-backed keys (FIDO2 -sk keys) for administrators.
5. Prompt patching of OpenSSH.

With those in place, fail2ban or CrowdSec is still worth running for log hygiene and as a signal: a burst of bans against a single host is a useful alert. For web applications behind a CDN, enforce bans at the edge where the real client address is visible.

Running it well if you run it

Keep bans short and escalating for repeat offenders rather than permanent, allowlist your monitoring and office ranges, and make lifting a ban a quick, documented action. Watch the number of bans per hour as a metric: a sudden jump against one host is worth an alert even though each ban is routine. For CrowdSec, decide what you share and which community lists you consume, and keep a local override list so an address you depend on is never blocked by someone else's decision. Behind a proxy, configure the real client address only from the proxy's ranges, or attackers will write arbitrary addresses into your logs and get your own users banned.

A one-paragraph interview answer

"fail2ban and CrowdSec are detection-triggered IP rate limits: they react to logged failures. They do not authenticate anyone, they miss distributed and correct-credential attacks, and they misfire behind proxies. I would disable password authentication, put SSH behind a VPN or identity-aware proxy, use short-lived SSH certificates from SSO, patch OpenSSH quickly, and keep fail2ban as noise reduction with allowlists and expiring bans."

Go deeper

The full worked answers are how fail2ban and CrowdSec work and securing SSH access at scale. For getting SSH off the internet, see how mesh VPNs work, and for the host around it, hardening a Linux server.