magnetite: confine the builder account's key to the nix protocol

[cameronraysmith]

What changes

Magnetite's builder account, in modules/machines/nixos/magnetite/default.nix, receives two edits.

The nix-remote-build public key held by stibnite is now wrapped with restrict and a forced nix-daemon --stdio command, following the construction in modules/system/stibnite-access.nix on the fm/vx-stibnite-darwin-builder branch, which does the same for the opposite direction of this builder pair. The forced command interpolates config.nix.package rather than a bare program name, so it resolves to the nix actually deployed on magnetite, and the account keeps its default bash shell because sshd runs a forced command through the account's login shell.

The second edit removes inputs.self.users.crs58.meta.sshKeys from the same account, leaving the machine key as its only entry.

Why

Before this change the key authorized an unrestricted shell on an account that is a nix trusted user, on a host whose sshd accepts connections from the public internet (networking.firewall.allowedTCPPorts includes 22). The private half of that key is a file deployed on a second machine, so the credential's reach was wider than the one protocol it exists to serve.

Removing the personal keys costs no access. The only automated consumer of the account authenticates with the machine key: modules/system/magnetite-builder.nix:69 sets sshKey to the nix-remote-build generator's key path, and :99-100 writes an ssh config block pinning that User and IdentityFile. Interactive access is independent, through modules/system/admins.nix, where crs58 is in wheel with those same keys, root inherits keys from every wheel user, and wheel has passwordless sudo, so sudo -u builder still reaches the account when debugging needs it.

What the forced command does not bound

It restricts which program the key can start. It does not restrict that program's authority. The account remains in nix.settings.trusted-users, which is deliberately unchanged here: removing it requires per-machine store signing, because an untrusted build account rejects unsigned caller-evaluated store paths. That migration is tracked separately as vx-nix-store-signing-untrust-builders, and folding it into a one-line confinement would couple two changes with unrelated failure modes.

Verification, and its ceiling

Evaluation of magnetite's host configuration renders the account's key list as exactly one entry:

restrict,command="/nix/store/g1k5iczz0l8i8d7kk5bk8rwv139g3l02-nix-2.34.8/bin/nix-daemon --stdio" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMQQEF+XYbWt+R1Gd/CGKljcdw4qBrTNaG/bfGymaT8s nix-remote-build

restrict and the forced command are present, the command names a store path rather than a bare program, and the personal keys are gone. Two supporting evaluations confirm the surrounding assumptions: the account's shell is bash-interactive, so it can execute the forced command, and crs58's own account still carries both of his keys.

Three flake checks were run and pass: treefmt, which covers formatting of the edited file; structure-nixos-configurations, which evaluates the NixOS configurations including magnetite; and deployment-safety. The rest of the check set was left out because nothing else evaluates this file, and the rendered value above is the direct evidence for what changed.

Evaluation is the ceiling of what this branch demonstrates. It shows that magnetite will be configured with the intended authorized_keys entry. It does not show that a remote build over the confined key succeeds, because that requires deploying to the live host, which this branch does not do. A forced command breaks any use of the key other than the nix protocol; the only configured use is the ssh-ng buildMachines entry above, and a search for nix-remote-build across the repository finds no other consumer, but the first deployment is where that holds or does not.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request