Hi Daniel, On Tue, Mar 03 2026, Daniel Littlewood via wrote: > However I still get "unauthorized key" in this case. If instead I add > my local key automagically with the following procedure: > >> (define (add-deploy-machine os) >> (let ((%authorized-keys >> (cons (local-file "/etc/guix/signing-key.pub")))) >> (modify-service os guix >> (authorized-keys %authorized-keys)))) > everything works perfectly - I get a completely successful deployment > and everything seems to be updated correctly. [...]
I think this snippet has a slight mistake, but in principle this is what I have in my configuration, too. My understanding as to why this is necessary is that the deployment happens in multiple steps (in deploy-managed-host): 1. authorize the deploying machine's ACL on the target 2. switch to the new system on the target 3. upgrade live shepherd services on the target 4. set up kexec on the target 5. install the bootloader on the target I expect the issue is that step (2) writes /etc/guix/acl in the new system's activation script, undoing the change of (1). If we don't list the deploying machine's key in the config that we switch to in (2) then we lock ourselves out of being able to do (3), (4), and (5). I expect (1) creates a new generation, but without completing (3) or (5) we can't properly enter it: we can't "herd restart" services to get the new config, and we can't reboot into the new system. This seems wrong - thanks for pointing it out! Presumably I've run into this in the past and fixed it in my config. Now the question is, what should the fix be? I can see two options: 1. make "guix deploy" modify the operating-system it's deploying to add the deploying machine's key into target's guix-daemon authorized keys 2. document that the deploying machine's key needs to be explicitly present in the configuration of the target machine I have an inclination towards (1), but what do other people think? Carlo
