fix: fail2ban silently skipped when ssh_hardening is disabled#23
Open
rlei-odes wants to merge 1 commit into
Open
fix: fail2ban silently skipped when ssh_hardening is disabled#23rlei-odes wants to merge 1 commit into
rlei-odes wants to merge 1 commit into
Conversation
module_fail2ban() reads /etc/ssh/sshd_config directly to check whether password auth is active and sets the SSH jail accordingly. It does not rely on any state from ssh_hardening. The dependency caused fail2ban to be silently skipped when ssh_hardening was disabled — exactly when fail2ban is most needed (password auth still on). Contradicts both the README and the module's own logic.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hey, great project.
Ran the script on a Debian 13 server where we kept password auth on — so
ssh_hardeningwas disabled in the config. Even withENABLE_FAIL2BAN=true, fail2ban got silently skipped. That's the opposite of what you want: password auth on, no brute-force protection.Traced it to
MODULE_DEPS: fail2ban listsssh_hardeningas a required dependency, so disabling one kills the other.Looked at
module_fail2ban()— it reads/etc/ssh/sshd_configdirectly to check whether password auth is active and decide which jails to configure. It doesn't use any state or output fromssh_hardening. The dependency isn't doing anything useful.The README describes exactly this split: fail2ban is the protection layer for password-based setups, ssh_hardening is what you enable once you've moved to key-only auth. They're intended as alternatives for different phases of hardening, not as a chain.
Fix is a one-liner: drop
ssh_hardeningfrom fail2ban's dependency list.