forge-sync: the target host key is never pinned, so the admin probe is refused until the budget runs out #89

New issue

Closed

opened 2026-10-09 20:18:43 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-10-09 20:18:43 +01:00

forge-sync forge on a hypervisor built from the public template waits out its SSH budget and dies, with the forge VM up and answering.

Evidence, laptop, second fresh install with every earlier fix pinned through, provision-vm forge clean, 2026-10-09:

$ forge-sync forge
Error: admin SSH on 'forge' did not become ready within 60s
Nothing else was changed. Re-running forge-sync 'forge' converges.

Cause, read from the scripts: forge-sync probes the admin port with StrictHostKeyChecking=yes against ~/.ssh/known_hosts_vms. The only writer of that file is bootstrap-vm, and provision-vm runs it only for a VM with a forge key or repositories; the forge has neither, so its host key is never pinned and every probe is refused as an unknown host. The two-node witness in allod/archetypes checks/forge-sync.nix did not catch it because the test driver writes known_hosts_vms by hand before running the command.

Workaround: append <forge ip> <forge active key> from machine-host-keys.json to ~/.ssh/known_hosts_vms, then rerun.

`forge-sync forge` on a hypervisor built from the public template waits out its SSH budget and dies, with the forge VM up and answering. Evidence, laptop, second fresh install with every earlier fix pinned through, `provision-vm forge` clean, 2026-10-09: $ forge-sync forge Error: admin SSH on 'forge' did not become ready within 60s Nothing else was changed. Re-running forge-sync 'forge' converges. Cause, read from the scripts: `forge-sync` probes the admin port with `StrictHostKeyChecking=yes` against `~/.ssh/known_hosts_vms`. The only writer of that file is `bootstrap-vm`, and `provision-vm` runs it only for a VM with a forge key or repositories; the forge has neither, so its host key is never pinned and every probe is refused as an unknown host. The two-node witness in `allod/archetypes` `checks/forge-sync.nix` did not catch it because the test driver writes `known_hosts_vms` by hand before running the command. Workaround: append `<forge ip> <forge active key>` from `machine-host-keys.json` to `~/.ssh/known_hosts_vms`, then rerun.

vnprc referenced this issue from a commit

2026-10-09 20:22:32 +01:00

forge-sync: pin the target host key from the secrets state before probing

vnprc-agent referenced this issue from allod/strategy

2026-10-09 23:10:21 +01:00

A Forgejo VM on the hypervisor: PRs and issues for a forge-less deployment #65

vnprc-agent commented

2026-10-10 13:42:58 +01:00

Author

Landed on allod/nexus master 00bec0a: forge-sync pins the target's host key from machine-host-keys.json before its first probe. Pinned through the deploy template. Witnessed on the third clean install, 2026-10-09: the probe reached the forge with no hand step. Dropping the archetypes witness driver's known_hosts_vms pre-write is tracked in the forge VM status report.

Landed on allod/nexus master 00bec0a: forge-sync pins the target's host key from machine-host-keys.json before its first probe. Pinned through the deploy template. Witnessed on the third clean install, 2026-10-09: the probe reached the forge with no hand step. Dropping the archetypes witness driver's known_hosts_vms pre-write is tracked in the forge VM status report.

vnprc-agent closed this issue

2026-10-10 13:42:58 +01:00