docs(runbook): document git-over-SSH client-IP limitation (#91) #153
Inga granskare
Etiketter
Inga etiketter
area/backups
area/ci
area/control-panel
area/identity
area/infra
area/observability
area/payments
area/security
area/storage
area/web
blocked
needs-info
needs-triage
ready-for-implementation
type
bug
type
chore
type
docs
type
epic
type
feature
type
task
wontfix
Ingen milstolpe
Inget projekt
Inga tilldelade
1 deltagare
Notiser
Förfallodatum
Inget förfallodatum satt.
Beroenden
Inga beroenden satta
Referens
bitborg/bitborg-infra!153
Läser in…
Hänvisa till i nytt ärende
Ingen beskrivning angiven.
Ta bort grenen "docs/91-ssh-client-ip-limitation"
Borttagning av en gren är permanent. Även om den borttagna grenen kan fortsätta existera en kort tid innan den faktiskt tas bort, kan det INTE ångras i de flesta fall. Vill du fortsätta?
Investigation — the two fix candidates aren't feasible in the current architecture
Option 1 (socket activation, like #81): not applicable. #81 works because Caddy natively consumes a systemd-passed fd (
bind fd/3in the Caddyfile). git-over-SSH here is served by the image's bundled OpenSSH (START_SSH_SERVER=false; the rootful image runs its ownsshd,PublishPort={{ git_ssh_port }}:22). OpenSSHsshdhas no way to consume a systemd-passed socket fd for its main listener — so the fd-passing trick that de-pasta'd Caddy can't de-pasta sshd.Option 2 (PROXY protocol): not applicable.
SSH_SERVER_PROXY_PROTOCOLgoverns Forgejo's built-in SSH server, which is disabled. OpenSSHsshddoesn't speak PROXY protocol.Resolution (option 3 for now) + recommendation
Documented as a known limitation in the runbook (this PR). A real fix requires a re-architecture of git-over-SSH, e.g.:
sshdwithAuthorizedKeysCommandproxying to Forgejo.Both are sizeable changes to a core function (git push/pull) and warrant their own ADR/epic + a maintenance-window rollout — not an incidental fix. Impact is bounded: SSH access is key-authenticated and unaffected; only IP attribution in logs/audit is degraded (abuse-tracing / rate-limiting gap, not an access-control hole).
Keeping #91 open as the tracker for that re-architecture. Runbook now documents the limitation so it isn't rediscovered.