How to unlock some luks devices with a keyfile on a first luks device

Just to give an update, creating the crypttab file via etc.environment did end up working!

For now I went with the simplest possible approach, which I’ve copied below:

  environment.etc.crypttab = {
    enable = true;
    text = ''
      # sda3_crypt UUID=2644f599-e320-4c60-bc1a-bc0d4cba7d46 none luks
      data_disk1_crypt UUID=2b7c47cb-a425-4493-8d7d-4227537a40d5 /root/keyfile luks
      data_disk2_crypt UUID=ebaf3ced-e0ec-4978-bf7c-839c30ba0051 /root/keyfile luks
      data_disk3_crypt UUID=353ce3c1-7c53-448a-909b-d239d210c99b /root/keyfile luks
      parity_disk1_crypt UUID=a7c2e0a5-c5ec-4dc9-94fd-4118890e6486 /root/keyfile luks
    '';
  };

The contents of the file are almost identical to the file I had on the Debian installation I’m moving away from. The key different is that the entry for the disk containing the the root filesystem (sda3_crypt) had to be commented out.

I’m guessing that’s unlocked by the Stage1 Bootloader via the preLVMCommands and that seems to interfere in minor ways with having it in the crypttab.

I use ssh in my initrd via the boot.initrd.network.ssh option. Having that first line in my crpyttab causes the boot sequence to ask for the password a second time, once when I’ve already unlocked it over ssh via cryptsetup-askpass.

I’ll investigate whether or not that double prompting behaviour is exclusive to ssh unlocking and report back tonight.

Thank you for the help @ElvishJerricco and @emmanuelrosa

4 Likes