feat: Step CA SSH certificates as a host authentication type (#1340)

* feat: Step CA SSH certificates as a host authentication type

Issue short-lived SSH user certificates from a smallstep CA through its
OIDC provisioner, over the CA's HTTP API rather than the step binary.
Everything after issuance reuses the OPKSSH plumbing: the same encrypted
per-user/host token store, WebSocket dialog and ssh2 certificate
injection, with the connect paths branching on a shared
usesIssuedCertificate() predicate. Instance-wide CA settings live in the
admin panel, with a private-host allowlist for the SSRF guard.

* fix: harden Step CA callback flow

* style: format Step CA changes
This commit is contained in:
ZacharyZcR
2026-08-25 02:56:44 +08:00
committed by GitHub
parent 0ab7cf2ab8
commit 32d77fc6d0
38 changed files with 1791 additions and 48 deletions
+6 -3
View File
@@ -356,9 +356,12 @@ networks:
For multiple Termix backend instances, set the same `REDIS_URL` and optional
`TERMIX_REDIS_PREFIX` on every instance. Redis synchronizes collaboration room
presence, control requests, controller state, and events; keep WebSocket session
affinity enabled because live SSH and remote desktop transports remain attached
to the backend instance that opened them. A single instance needs no Redis.
presence, control requests, controller state, and events. It also routes Step CA
OAuth callbacks back to the instance holding the user's terminal; the optional
`TERMIX_STEP_CA_REDIS_PREFIX` isolates those short-lived encrypted messages.
Keep WebSocket session affinity enabled because live SSH and remote desktop
transports remain attached to the backend instance that opened them. A single
instance needs no Redis.
### Command Line Interface