sshd: the daemon it owns starts at boot

The module said the service must be running and nothing about boot, so the machine's own way back in was enabled only because something before the mesh had enabled it. All four machines happen to be enabled today; none of them is enabled because the mesh says so, and a machine adopted tomorrow would run ssh until its first reboot. Not `state: running` alone for the same reason the module exists: this is the one daemon whose absence cannot be fixed remotely.
Merge pull request 'fail2ban bans through an action every machine has' (#135 ) from fix/fail2ban-bans-through-what-every-machine-has into main
2026-09-28 21:43:27 +02:00 · 2026-09-28 18:48:26 +00:00 · 2026-09-28 20:48:24 +02:00 · 2026-09-28 18:45:34 +00:00
2 changed files with 2 additions and 1 deletions
@@ -33,7 +33,7 @@
      "type": "file",
      "path": "/etc/fail2ban/jail.local",
      "mode": "0644",
-      "content": "[INCLUDES]\n\nbefore = paths-arch.conf\n\n[DEFAULT]\n\n# Never act on the machine itself or on a tunnel peer: the mesh's private range is\n# ${machine:mesh-range}, named here rather than written as a value the module cannot\n# know (novox/hq ADR 0112). Without this, fail2ban could ban the mesh's own nodes.\nignoreip = 127.0.0.1/8 ::1 ${machine:mesh-range}\n\nbantime  = 10m\nfindtime = 10m\nmaxretry = 5\n\nbanaction = ufw\nbanaction_allports = iptables-allports\n\n[sshd]\nenabled = true\nport    = ssh\nlogpath = %(sshd_log)s\nbackend = %(sshd_backend)s\n"
+      "content": "[INCLUDES]\n\nbefore = paths-arch.conf\n\n[DEFAULT]\n\n# Never act on the machine itself or on a tunnel peer: the mesh's private range is\n# ${machine:mesh-range}, named here rather than written as a value the module cannot\n# know (novox/hq ADR 0112). Without this, fail2ban could ban the mesh's own nodes.\nignoreip = 127.0.0.1/8 ::1 ${machine:mesh-range}\n\nbantime  = 10m\nfindtime = 10m\nmaxretry = 5\n\n# Ban through iptables, not through a firewall front-end the machine may not have. ufw is\n# installed on two of this mesh's machines and absent on the other two, and fail2ban finds out\n# only at ban time: the service reports healthy, the jail counts the attempt, the ban command\n# exits 127, and nothing is blocked. Proven on 2026-09-28 -- 'ufw: command not found' on a\n# machine the mesh reported as protected.\n#\n# The action below is this module's own, already used by the recidive jail on every machine\n# here, and it bans in DOCKER-USER as well as INPUT, so a container's published port is\n# covered too.\nbanaction = iptables-allports-dualchain\nbanaction_allports = iptables-allports-dualchain\n\n[sshd]\nenabled = true\nport    = ssh\nlogpath = %(sshd_log)s\nbackend = %(sshd_backend)s\n"
    },
    {
      "id": "jail-sshd",
@@ -31,6 +31,7 @@
      "type": "service",
      "unit": "sshd.service",
      "state": "running",
+      "boot": "enabled",
      "restart-on": [
        "config"
      ]
Author	SHA1	Message	Date
jschoubben	e145e2236c	sshd: the daemon it owns starts at boot The module said the service must be running and nothing about boot, so the machine's own way back in was enabled only because something before the mesh had enabled it. All four machines happen to be enabled today; none of them is enabled because the mesh says so, and a machine adopted tomorrow would run ssh until its first reboot. Not `state: running` alone for the same reason the module exists: this is the one daemon whose absence cannot be fixed remotely.	2026-09-28 21:43:27 +02:00
mesh-admin	4d7e37e319	Merge pull request 'fail2ban bans through an action every machine has' (#135 ) from fix/fail2ban-bans-through-what-every-machine-has into main	2026-09-28 18:48:26 +00:00
jschoubben	026421fd6e	fail2ban: ban through an action every machine has jail.local named ufw as the ban action. Two machines on this mesh have no ufw, and fail2ban does not check: it starts, the jail reads the log, counts the attempts, runs the ban command, gets 127 -- 'ufw: command not found' -- and logs an error nobody reads. The service is active, the mesh reports the module applied, and the machine is not protected. Proven by banning a documentation address on such a machine today. The replacement is this module's own dualchain action, already used by the recidive jail on all four machines, so it is not a new dependency. It bans in DOCKER-USER as well as INPUT, which ufw's action did not, and it bans all ports, which ufw's action did.	2026-09-28 20:48:24 +02:00
mesh-admin	af89bb11ff	Merge pull request 'fail2ban declares the log its own recidive jail reads' (#134 ) from fix/fail2ban-declares-the-log-its-own-jail-reads into main	2026-09-28 18:45:34 +00:00