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.
This commit is contained in:
Brian Pooe 2026-07-19 15:09:55 +02:00
parent 0ff2df7033
commit 9dfde294cb
3 changed files with 21 additions and 5 deletions

View file

@ -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

View file

@ -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

View file

@ -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 HA to Forgejo SSH` | `IoT` | `10.0.30.6` | `TRUSTED` | `10.0.10.18` | `2222` | git-over-SSH from homeassistant |
| `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` | `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.