agent prepare-join-key returns the old server's key digest on an enrolled machine; join then refuses with a generic error #384

New issue

Open

opened 2026-11-06 02:35:10 +00:00 by kayg · 0 comments

kayg commented

2026-11-06 02:35:10 +00:00

Owner

Found by J267 (#375); J80c hit the same trap on #265 (comment 76774). Severity P3 (setup UX; no security impact: the refusal is correct).

On a machine already enrolled with server A, infraternal agent --data <dir> prepare-join-key https://B succeeds and prints KEY-DIGEST <digest of A's identity key>, because remote.rs prepared_key (line 291) reuses identity.json whatever the origin. An invitation from B bound to that digest is then refused by design by agent join (remote.rs:471-475: host id and server name differ), with only:

{"ok":false,"state":"refused","message":"Remote infraternal agent operation failed","next":["Check the server address and that this machine is still enrolled, then run the command again."]}

The documented two-step path (prepare, then join) produces a digest that can never work, and nothing explains why or what to do: move or retire the old identity, or use a fresh --data.

Repro (Mac VM, J267): enrol with server #1, then for a new server #2 at the same origin name run prepare-join-key → old digest 9b81131b…. Issue a key-bound invitation and agent join → refused. After moving identity.json aside, prepare-join-key prints a new digest (950a4914…) and join succeeds.

Expected (wording or behaviour, owner's choice): prepare-join-key refuses or warns when an identity for a different server exists, saying how to re-point the machine, or join says "this machine is enrolled with ; …" instead of the generic refusal.

Links: #375, #265, #263.

Found by J267 (#375); J80c hit the same trap on #265 (comment 76774). Severity **P3** (setup UX; no security impact: the refusal is correct). On a machine already enrolled with server A, `infraternal agent --data <dir> prepare-join-key https://B` succeeds and prints `KEY-DIGEST <digest of A's identity key>`, because `remote.rs` `prepared_key` (line 291) reuses `identity.json` whatever the origin. An invitation from B bound to that digest is then **refused by design** by `agent join` (`remote.rs:471-475`: host id and server name differ), with only: ``` {"ok":false,"state":"refused","message":"Remote infraternal agent operation failed","next":["Check the server address and that this machine is still enrolled, then run the command again."]} ``` The documented two-step path (prepare, then join) produces a digest that can never work, and nothing explains why or what to do: move or retire the old identity, or use a fresh `--data`. **Repro (Mac VM, J267):** enrol with server #1, then for a new server #2 at the same origin name run `prepare-join-key` → old digest `9b81131b…`. Issue a key-bound invitation and `agent join` → refused. After moving `identity.json` aside, `prepare-join-key` prints a new digest (`950a4914…`) and join succeeds. **Expected** (wording or behaviour, owner's choice): `prepare-join-key` refuses or warns when an identity for a different server exists, saying how to re-point the machine, or `join` says "this machine is enrolled with <server>; …" instead of the generic refusal. Links: #375, #265, #263.

kayg referenced this issue

2026-11-06 02:38:15 +00:00

Mac mesh break-it on dev 9b0c731e8 (J267) #375

No labels

launch-qa

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

kayg/infraternal#384

No description provided.

Rows
Columns