The `forge` machine's identity and host key #42

New issue

Closed

opened 2026-10-07 05:08:05 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-10-07 05:08:05 +01:00

The secrets template gains the forge machine's identity and host key, which is what provisioning refuses to proceed without. With this, getting-started.sh generates the forge VM's host key on a fresh install with no change to the script.

Primary goals:

A serviceVMs.forge identity — fills the group allod/secrets#41 added, so vmUsernames resolves forge to root and every hypervisor script that logs in as the identity's username reaches it.
A host key entry — forge joins machine-host-keys.json, which is the list getting-started.sh iterates when it regenerates per-VM host keys, so a fresh deployment keys the forge VM automatically.
Its ciphertext recipients — secrets.nix gives the forge VM's host-key secret the same recipient shape every other guest's has, so the hypervisor can inject it at provisioning and the guest can decrypt what it carries.
The template stays forge-less where it should — forge-ssh-keys.json stays {} and forgeAccess stays false: the dev VM's forge key pair and the agent token belong to the bootstrap slice, not here.

Current state and specifics

machine-host-keys.json currently holds allod-dev and privacy-1. getting-started.sh in allod/deploy regenerates a key for each of its keys (for vm in $(jq -r 'keys[]' ...)), encrypts it to the hypervisor's key, and writes the public half back — so membership in that file, not a script change, is what makes a new machine's host key get generated on a fresh install.

allod/secrets#41 added identity.serviceVMs, empty, exported as lib.serviceIdentities with username = "root".

The four Forgejo application secrets are not secrets of this repository: in fresh-install mode nixpkgs' own unit generates them inside the VM on first boot, on the data disk.

Scope

In: the serviceVMs.forge identity, the machine-host-keys.json entry, the secrets.nix recipient wiring, and whatever the repository's own checks need to stay green. Out: the dev VM's forge key pair and the agent token ciphertext, both of which the bootstrap slice lands together with the forgeAccess flip; and any change to getting-started.sh, which needs none for this.

Part of allod/strategy#65

The secrets template gains the `forge` machine's identity and host key, which is what provisioning refuses to proceed without. With this, `getting-started.sh` generates the forge VM's host key on a fresh install with no change to the script. Primary goals: - **A `serviceVMs.forge` identity** — fills the group allod/secrets#41 added, so `vmUsernames` resolves `forge` to `root` and every hypervisor script that logs in as the identity's username reaches it. - **A host key entry** — `forge` joins `machine-host-keys.json`, which is the list `getting-started.sh` iterates when it regenerates per-VM host keys, so a fresh deployment keys the forge VM automatically. - **Its ciphertext recipients** — `secrets.nix` gives the forge VM's host-key secret the same recipient shape every other guest's has, so the hypervisor can inject it at provisioning and the guest can decrypt what it carries. - **The template stays forge-less where it should** — `forge-ssh-keys.json` stays `{}` and `forgeAccess` stays `false`: the dev VM's forge key pair and the agent token belong to the bootstrap slice, not here. ### Current state and specifics `machine-host-keys.json` currently holds `allod-dev` and `privacy-1`. `getting-started.sh` in `allod/deploy` regenerates a key for each of its keys (`for vm in $(jq -r 'keys[]' ...)`), encrypts it to the hypervisor's key, and writes the public half back — so membership in that file, not a script change, is what makes a new machine's host key get generated on a fresh install. allod/secrets#41 added `identity.serviceVMs`, empty, exported as `lib.serviceIdentities` with `username = "root"`. The four Forgejo application secrets are not secrets of this repository: in fresh-install mode nixpkgs' own unit generates them inside the VM on first boot, on the data disk. ### Scope In: the `serviceVMs.forge` identity, the `machine-host-keys.json` entry, the `secrets.nix` recipient wiring, and whatever the repository's own checks need to stay green. Out: the dev VM's forge key pair and the agent token ciphertext, both of which the bootstrap slice lands together with the `forgeAccess` flip; and any change to `getting-started.sh`, which needs none for this. Part of allod/strategy#65

vnprc-agent referenced this issue from allod/strategy

2026-10-07 05:08:19 +01:00

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

vnprc-agent referenced this issue

2026-10-07 18:40:19 +01:00

Host keys and identities are not checked against the inventory machine list #43

vnprc-agent referenced this issue from a commit

2026-10-07 18:49:50 +01:00

forge VM: the forge machine evaluates; two commits left to relay