git-collab-server setup locks out every key not in keydir #97

New issue

Closed

opened 2026-08-13 15:01:31 +00:00 by a73x · 0 comments

a73x commented

2026-08-13 15:01:31 +00:00

(Migrated from git.a73x.sh)

Not a defect in 0065cd95 — a consequence of governance that my issue text for 3733cccd got wrong, and that an operator must decide about before running setup on a live server.

I wrote: "Do not touch authorized_keys; the pre-governance path keeps working until the operator chooses otherwise." It does not. Confirmed at session.rs:536:

// `keydir/` supersedes the authorized_keys file when a settings
// repository exists: one roster, in git, or the old file — never both,
// so a key can never be enrolled in one and revoked in the other.

auth_publickey matches on GovernanceState: Active consults keydir/ only; authorized_keys is read only in the Absent arm. So the instant settings.git exists, every key not in keydir/ is refused SSH auth.

The supersession itself is right — two rosters that can disagree is worse. What is wrong is that setup is a one-key bootstrap, so running it on a populated server locks out everyone except the admin, immediately, with no warning at the point of decision. 0065cd95 reports it in setup's closing output and in the README, which is the honest minimum, but the operator still has to notice.

Live blast radius: the deployment's authorized_keys holds 2 keys, so running setup as it stands would lock out 1 of them.

Options:

Enrol existing authorized_keys entries into keydir/ during setup. Preserves access exactly, matching the no-op principle the rest of setup is built on — the whole point of that design is that enabling governance changes nothing until you choose to change it, and auth is the one axis where it currently does. The obstacle is naming: authorized_keys entries have no identity, and the keydir basename is the principal. Comments could seed a name, with a fallback like key1, key2 for the operator to rename.
A --enrol-existing flag, so the default stays a clean single-admin bootstrap and the migration case is explicit.
Leave it, and rely on the report and README. Defensible for a personal forge with two keys; less so for anyone else.

Recommend 1 or 2. As it stands, the safest command we ship has one sharp edge left, and it is the one that locks you out of your own server.

Migrated from git-collab issue 54b04c35342e149b9e9d92fb894c761ea79ab71f.

Original author: a73x dev@a73x.sh.

Close reason: merged in patch 65c569f3

Not a defect in `0065cd95` — a consequence of governance that my issue text for 3733cccd got **wrong**, and that an operator must decide about before running setup on a live server. I wrote: "Do not touch `authorized_keys`; the pre-governance path keeps working until the operator chooses otherwise." It does not. Confirmed at session.rs:536: ```rust // `keydir/` supersedes the authorized_keys file when a settings // repository exists: one roster, in git, or the old file — never both, // so a key can never be enrolled in one and revoked in the other. ``` `auth_publickey` matches on `GovernanceState`: `Active` consults `keydir/` **only**; `authorized_keys` is read only in the `Absent` arm. So the instant `settings.git` exists, every key not in `keydir/` is refused SSH auth. The supersession itself is right — two rosters that can disagree is worse. What is wrong is that setup is a **one-key bootstrap**, so running it on a populated server locks out everyone except the admin, immediately, with no warning at the point of decision. `0065cd95` reports it in setup's closing output and in the README, which is the honest minimum, but the operator still has to notice. Live blast radius: the deployment's `authorized_keys` holds **2 keys**, so running setup as it stands would lock out 1 of them. Options: 1. **Enrol existing `authorized_keys` entries into `keydir/` during setup.** Preserves access exactly, matching the no-op principle the rest of setup is built on — the whole point of that design is that enabling governance changes nothing until you choose to change it, and auth is the one axis where it currently does. The obstacle is naming: `authorized_keys` entries have no identity, and the keydir basename *is* the principal. Comments could seed a name, with a fallback like `key1`, `key2` for the operator to rename. 2. **A `--enrol-existing` flag**, so the default stays a clean single-admin bootstrap and the migration case is explicit. 3. **Leave it**, and rely on the report and README. Defensible for a personal forge with two keys; less so for anyone else. Recommend 1 or 2. As it stands, the safest command we ship has one sharp edge left, and it is the one that locks you out of your own server. --- Migrated from git-collab issue `54b04c35342e149b9e9d92fb894c761ea79ab71f`. Original author: a73x <dev@a73x.sh>. Close reason: merged in patch 65c569f3