sshd: enable fail2ban with default ssh jail (quick win, no exposure change) #104
Labels
No labels
burndown-2026-06
burndown-2026-08
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
coherence-core
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
qa-fixture
role/advocate
role/director
role/exec
role/frontend
role/gamedev
role/human
role/platform
role/qa
role/science
role/sysadmin
state
ambient
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
coilyco-flight-deck/infrastructure#104
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
fail2banandsshguardare bothinactiveon kai-server while sshd is listening on0.0.0.0:22andauth.logis taking active brute-force scans (2.57.122.177,89.134.210.182,213.35.128.24,161.35.139.3, etc., observed live during today's mobile-SSH debug). Nothing is throttling repeated failed-auth attempts.Proposed change
Lowest-risk immediate hardening that doesn't depend on resolving the broader exposure question:
Default jail config ships with the
sshdjail enabled and tuned for Ubuntu's auth.log format. No sshd binding changes, no firewall topology changes - just bans IPs after N failed-auth attempts.Verify after:
Why split this off from the bigger audit
The parent issue, infrastructure#103, needs decisions about router port-forwards and the tangled-knot git-SSH path before changing exposure. That's a real audit. fail2ban can ship in 5 minutes regardless of those decisions and immediately cuts bot scan effectiveness.
Parent
Filed by Claude.