feat(forgejo): move git-over-SSH to standard port 22

Relocated LXC 114's own admin sshd to port 2200 (systemd ssh.socket
override) to free port 22 for Forgejo's git-SSH, dropping the ugly
:2222 from every clone URL. Updated the 5 hosts' remotes/SSH config
and the corresponding UniFi rules to match.

docker-compose-files/forgejo/.env.sample

@@ -1,6 +1,10 @@
 # Forgejo
 FORGEJO_VERSION=10
 FORGEJO_HTTP_PORT=3000
+# Defaults to 2222 because the LXC's own system sshd already owns port 22.
+# To use the standard port 22 for git-over-SSH instead, first move the LXC's
+# own admin sshd off 22 (e.g. via a systemd ssh.socket override setting
+# ListenStream to another port), then set FORGEJO_SSH_PORT=22 here.
 FORGEJO_SSH_PORT=2222
 FORGEJO_BIND_IP=0.0.0.0
 FORGEJO_MEM_LIMIT=1G

docker-compose-files/forgejo/README.md

@@ -74,6 +74,12 @@ Add a block for `git.<domain>` (port `FORGEJO_HTTP_PORT`) to
 Git-over-SSH (`FORGEJO_SSH_PORT`) is not proxyable through Caddy — expose that
 port directly if you want SSH clone/push from outside the LAN.
 
+`FORGEJO_SSH_PORT` defaults to `2222` because the LXC's own admin sshd
+already owns port 22. This instance was later moved to the standard port —
+the LXC's admin sshd got relocated to 2200 first (systemd `ssh.socket`
+override), freeing 22 for Forgejo's git-SSH. See `.env.sample` for the
+one-time steps if you want to do the same elsewhere.
+
 ## Notes
 
 - Pin `FORGEJO_VERSION` to a specific major (as shipped, `10`) rather than

docs/network/allow-caddy-to-apps.md

@@ -99,7 +99,7 @@ Every policy in this table uses:
 | `ALLOW CADDY to Bento PDF` | `10.0.10.6` | `8080` | Bento PDF |
 | `ALLOW CADDY to Koffan` | `10.0.10.12` | `8080` | Koffan (LXC 111) |
 | `ALLOW CADDY to Hermes` | `10.0.10.19` | `9119` | Hermes Agent dashboard (LXC 113) |
-| `ALLOW CADDY to Forgejo` | `10.0.10.18` | `3000,2222` | Forgejo web UI (LXC 114) and git-over-SSH for hosts pulling from raspberrypi's zone |
+| `ALLOW CADDY to Forgejo` | `10.0.10.18` | `3000,22` | Forgejo web UI (LXC 114) and git-over-SSH for hosts pulling from raspberrypi's zone |
 
 ---
 
@@ -152,20 +152,26 @@ allow it, and both were found misconfigured while wiring this up:**
    sudo ufw allow from 10.0.30.0/24 to any port 80,443 proto tcp
    ```
 
-## 3b. CADDY / IoT → Forgejo git-over-SSH (port 2222)
+## 3b. CADDY / IoT → Forgejo git-over-SSH (port 22)
 
 Both raspberrypi (CADDY zone) and Home Assistant (IoT zone) clone
 `homelab-blueprint` over SSH directly against the Forgejo LXC
-(`10.0.10.18:2222`), bypassing Caddy entirely — SSH can't be proxied
+(`10.0.10.18:22`), bypassing Caddy entirely — SSH can't be proxied
 through Caddy (HTTP/S only), so this traffic goes straight to the TRUSTED
 zone. `10.0.10.18` has no host-level firewall (`ufw` not installed,
 `iptables INPUT` policy `ACCEPT`), so only the UniFi zone rule matters
 here — no second enforcement layer to fight, unlike the Caddy host above.
 
+Forgejo's git-SSH runs on the standard port 22 on this LXC, not the usual
+`2222` (see `docker-compose-files/forgejo/README.md`) — the LXC's own
+admin sshd was relocated to port **2200** (systemd `ssh.socket` override)
+to free 22 up. Direct admin SSH to this LXC now needs `-p 2200`; `pct exec
+114` from the Proxmox host is unaffected and still works normally.
+
 | Policy name | Source zone | Source IP | Destination zone | Destination IP | Destination port(s) | Purpose |
 |---|---|---|---|---|---|---|
-| `ALLOW CADDY to Forgejo` (existing rule, port added) | `CADDY` | `10.0.15.5` | `TRUSTED` | `10.0.10.18` | `3000,2222` | Forgejo web UI + git-over-SSH from raspberrypi |
+| `ALLOW CADDY to Forgejo` (existing rule, port added) | `CADDY` | `10.0.15.5` | `TRUSTED` | `10.0.10.18` | `3000,22` | Forgejo web UI + git-over-SSH from raspberrypi |
-| `Allow HA to Forgejo SSH` | `IoT` | `10.0.30.6` | `TRUSTED` | `10.0.10.18` | `2222` | git-over-SSH from homeassistant |
+| `Allow HA to Forgejo SSH` | `IoT` | `10.0.30.6` | `TRUSTED` | `10.0.10.18` | `22` | git-over-SSH from homeassistant |
 
    `ufw status` on that host is the fastest way to check which subnets can
    already reach it before assuming a UniFi rule is the problem.