Make Forge SSH key rotation runtime-aware for microVMs #22

Open
opened 2026-07-28 21:39:43 +01:00 by vnprc-agent · 0 comments

Keep per-VM Forge SSH key rotation working when the private key is delivered to a microVM per boot instead of installed in the guest home directory.

Primary goals:

  • Preserve Forge identity state — keep forge-ssh-keys.json, staged/active public keys, account ownership, and Forgejo UI gates authoritative.
  • Dispatch by runtime — retain the current libvirt install-and-verify path while refreshing the host-side credential and restarting a microVM target.
  • Avoid durable guest plaintext — verify microVM-side git-over-SSH through the runtime credential path without writing ~/.ssh/<key>.
  • Prove both paths — add generated and behavioral fixtures for libvirt and microVM stage, activate, and retire operations.

Current state and specifics

forge-ssh-key activate currently proves Forgejo accepts the staged key, installs it at ~/.ssh/<forge-key> inside the VM, and proves VM-side access. That matches the libvirt runtime, but it bypasses per-boot systemd-credential delivery and leaves durable plaintext in a microVM guest. The stage and retire state machine remains valid; only delivery, activation, and verification must dispatch by runtime.

Scope

Part of allod/strategy#20.

In scope: runtime-aware behavior in the public Forge SSH rotation tool and fixtures, using the runtime fact and host credential-delivery interface supplied by that arc.

Out of scope: changing Forgejo accounts or key authority, private machine mappings, brokering short-lived Forge credentials, and deployment cutover.

Keep per-VM Forge SSH key rotation working when the private key is delivered to a microVM per boot instead of installed in the guest home directory. Primary goals: - **Preserve Forge identity state** — keep `forge-ssh-keys.json`, staged/active public keys, account ownership, and Forgejo UI gates authoritative. - **Dispatch by runtime** — retain the current libvirt install-and-verify path while refreshing the host-side credential and restarting a microVM target. - **Avoid durable guest plaintext** — verify microVM-side git-over-SSH through the runtime credential path without writing `~/.ssh/<key>`. - **Prove both paths** — add generated and behavioral fixtures for libvirt and microVM stage, activate, and retire operations. ### Current state and specifics `forge-ssh-key activate` currently proves Forgejo accepts the staged key, installs it at `~/.ssh/<forge-key>` inside the VM, and proves VM-side access. That matches the libvirt runtime, but it bypasses per-boot systemd-credential delivery and leaves durable plaintext in a microVM guest. The stage and retire state machine remains valid; only delivery, activation, and verification must dispatch by runtime. ### Scope Part of allod/strategy#20. In scope: runtime-aware behavior in the public Forge SSH rotation tool and fixtures, using the runtime fact and host credential-delivery interface supplied by that arc. Out of scope: changing Forgejo accounts or key authority, private machine mappings, brokering short-lived Forge credentials, and deployment cutover.
Sign in to join this conversation.
No description provided.