George myglc2 Clemmer <myg...@gmail.com> skribis:

> I want to set the host key in 'guix system vm-image' so that updating a
> VM config does not break that VM's host key entry in my client machine
> ~/.ssh/knownhosts files.  AFAIK there is no direct way to do this. I
> tried this ...
>   (services (cons*
>   [...]
>            (extra-special-file "/etc/ssh/ssh_host_ed25519_key"
>                                (local-file "ssh_host_ed25519_key"))
>            (extra-special-file "/etc/ssh/ssh_host_ed25519_key.pub"
>                                (local-file "ssh_host_ed25519_key.pub"))
>   )
> ... which does work but naturally throws errors ...
> localhost sshd[236]: error: 
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> localhost sshd[236]: error: @         WARNING: UNPROTECTED PRIVATE KEY FILE!  
>         @
> localhost sshd[236]: error: 
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

You should *not* do that, indeed, because the private key file ends up
in the store, and every file in the store is world-readable.  There’s no
way around it, currently at least.

The recommendation in this case is to use “out-of-band” storage—i.e.,
have the secrets stored in a place other than the store.

For example, you could have an activation snippet that copies secret
files directly to /etc, along these lines (untested):

  (simple-service 'copy-private-key activation-service-type
                  (with-imported-modules '((guix build utils))
                        (use-modules (guix build utils))
                        (mkdir-p "/etc/ssh")
                        (copy-file "/root/secrets/ssh_host_ed25519_key"

That means you have to arrange for /root/secrets/ssh_host_ed25519_key to
exist in the first place, but that’s pretty much all we can do.



Reply via email to