summaryrefslogtreecommitdiff
path: root/Rexfile
diff options
context:
space:
mode:
authorPaul Buetow <paul@buetow.org>2026-07-26 11:37:47 +0300
committerPaul Buetow <paul@buetow.org>2026-07-26 11:37:47 +0300
commit0bcc97a819d6578d41754512376b31fff66b1bce (patch)
tree75c33af205dd7517d172e3760a8d9e8d3393aa40 /Rexfile
parenta3692f68bace2dc171dbceed274bc26eeadd38aa (diff)
forgejo: reach git+ssh from off-LAN via a relayd TCP relay on 2022
The NodePort is LAN-only, so the advertised clone URL (ssh://git@r0.lan.buetow.org:30222/...) did not work from outside. Add a plain TCP relay on the gateways forwarding 2022 to NodePort 30222, and have Forgejo advertise code.f3s.buetow.org:2022. Port 2022 rather than 22: the gateways run their own sshd on port 2, so 22 was in fact free, but leaving the forge off the default port keeps it clear of the mass scanning that port attracts. That is noise reduction and not security -- the real protection is that Forgejo's SSH does key-only auth for git operations and offers no shell. 2222 would have been the conventional choice but dserver (DTail) already holds it on the gateways; verified 2022 free on both. The relay carries no "protocol" line, so relayd forwards the stream untouched. TLS must not be involved: SSH secures its own transport and the client verifies Forgejo's host key at the far end. A dedicated <forgejo_ssh> table keeps the health check on the SSH port, since the web UI can be up while SSH is not. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Diffstat (limited to 'Rexfile')
0 files changed, 0 insertions, 0 deletions