Simultaneous passwordFile and secret.keyFile

[midirhee12]

0d39ae5

I think this commit has a bit of an error. This assumes that password files are an alternative to keyfiles. But in reality, many people use passwords as a backup in case they lose their file.

I'm not sure if this is intentional. So I don't know whether to state that this is a bug or a feature request. But here ya go :P

[Lassulus]

There is additionalKeyFiles? You can also set keyFile and askPassword at the same time? But then booting will fail if the keyFile is unavailable I guess.

[midirhee12]

My intuition was that additionalKeyFiles were for when you wanted more than just one key file. So you cannot use secret.keyFile and passwordFile together. Also, it looks like the if askPassword part is ignored if you set a secret.keyFile since it is in an else branch.

[aos]

I work around this by adding a postCreateHook on the volume I want to encrypt with a password and a key file simultaneously. Here's an example:

# part of the disko-config.nix
root = {
  size = "100%";
  content = {
    type = "luks";
    name = "cryptroot";
    extraOpenArgs = [ "--allow-discards" ];
    # Encrypt with the key first
    settings = {
      keyFile = "/dev/mapper/cryptkey";
      keyFileSize = 8192;
    };
    # Use a postCreateHook to add the passphrase from a file
    postCreateHook = ''
      cryptsetup luksAddKey --key-file /dev/mapper/cryptkey \
                            --keyfile-size 8192 \
                            /dev/disk/by-partlabel/dev-vda-root /tmp/disk.key
    '';
    content = {
    # ...
    };
};

There's probably a better way to do fill in the values in the hook, but this works for me.

The hooks are really powerful and you can do some fun stuff with them. I'll see if I can send a PR to document them better!

[aos]

After digging into it further - seems like the only reason my solution works is because we call cryptsetup luksOpen during the creation of the LUKS drive.

Unfortunately, {pre,post}MountHooks aren't implemented and I think these would be pretty beneficial. One good example is to add a hostKey to initrd for LUKS remote unlock after mounting the boot partition.

If I have time I'll send a PR for it.

[phaer]

Unfortunately, {pre,post}MountHooks aren't implemented and I think these would be pretty beneficial. One good example is to add a hostKey to initrd for LUKS remote unlock after mounting the boot partition.

I think --extra-files should work this?
So you would put the directory tree & files you want to copy into a temp dir e.g. /tmp/extra_files and then use --extra-files /tmp/extra_files to copy them into your target system during installtion. So if you have /tmp/extra_files/etc/ssh/initrd_ssh_host_rsa_key and set

boot.initrd.network.ssh.hostKeys = ["/etc/ssh/initrd_ssh_host_rsa_key"];

in your nixos config, you should have the right host key in your initrd config.

The hooks are really powerful and you can do some fun stuff with them. I'll see if I can send a PR to document them better!

That would be very welcome!

[midirhee12]

I see this more as a work around than actually fixing the issue.

[phaer]

I believe it might be easier to discuss the merits of this opinion if you could share with us why you regard it as a a workaround and what "actually fixing the issue" would look like from your perspective? :)

[midirhee12]

The actual issue is that secret.keyFile and passwordFile cannot be used simulateously. Not that is is impossible to set a keyfile using some hack or work around. It would be best if we fixed the issue so secret.keyFile and passwordFile can be used intuitively as expected. For the user, even just using additionalKeyFiles would be nicer than having to do a hook.

[midirhee12]

In the meantime, I've had a thought to make the disko options a bit more intuitive. You change additionalKeyFiles to secret.keyFiles (note the plurality b'c it's a list) and then remove secret.keyFile entirely. That way to add any additional let files, you just add more to the list. And by default, password files and key files are compatible.

Edit: I can start on a PR for this change if this behavior is desired.

[phaer]

The actual issue is that secret.keyFile and passwordFile cannot be used simulateously. Not that is is impossible to set a keyfile using some hack or work around.

Ah, without quotations or context it's rather hard to tell whether your posts refer to the one before you. So in my understanding that actually fixes the issue insofar as that you can simultaneously use a password an key file?

Getting the interface nicer would surely be appreciated, happy to review - and your proposal sounds like the right direction to me :)

[aos]

So if you have /tmp/extra_files/etc/ssh/initrd_ssh_host_rsa_key and set boot.initrd.network.ssh.hostKeys = ["/etc/ssh/initrd_ssh_host_rsa_key"]; iin your nixos config, you should have the right host key in your initrd config.

Yeah I could do that - but that would mean I generate the host key outside of the host that uses it. I wanted to generate the host key on the host that would be using it, hence the need for a postMount hook.

I've worked around this by writing my own subpar implementation of nixos-anywhere that runs the disko script on the target host, generates the key and places it into the defined location under boot.initrd.network.ssh.hostKeys and does the final nixos-install.

I think having it all in the disko config would make it much cleaner :-)

[iFreilicht]

@midirhee12 I agree with @phaer, your proposal sounds good, and a PR for this would be welcome.

If you (or anyone else) decide to implement this, please use mkRenamedOptionModule and mkRemovedOptionModule from the nixpkgs lib to ensure backwards compatibility. We can then remove the old options in the 2.x release.