How to unlock all LUKS volumes with single password?

Hey, newbie here.

I have LUKS encrypted root and swap partitions. Each time on boot, I’m prompted to enter passwords for each of the partitions. My question is, how can I skip entering password for swap? I tried to mess around with /etc/crypttab but to avail.

Thanks :slight_smile:

It would probably be useful for anyone trying to help if you shared your partition and filesystem setup. Can you share the output of the following commands?

cat /etc/fstab
lsblk -f
1 Like

Hey @Cphusion :slight_smile:

UUID=8A2F-4076                            /efi           vfat    defaults,noatime 0 2
/dev/mapper/luks-81733cbe-81f5-4506-8369-1c9b62e7d6be /              ext4    defaults,noatime 0 1
/dev/mapper/luks-9715a3f9-f701-47b8-9b55-5143ca88dcd8 swap           swap    defaults   0 0
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
NAME                                          FSTYPE      FSVER LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
├─nvme0n1p1                                   vfat        FAT32             8A2F-4076                             915.6M     8% /efi
├─nvme0n1p2                                   crypto_LUKS 1                 81733cbe-81f5-4506-8369-1c9b62e7d6be                
│ └─luks-81733cbe-81f5-4506-8369-1c9b62e7d6be ext4        1.0   endeavouros d8d14c59-8704-4fb8-ad02-7d20a26bc1e1  840.2G     2% /
└─nvme0n1p3                                   crypto_LUKS 1                 9715a3f9-f701-47b8-9b55-5143ca88dcd8                
  └─luks-9715a3f9-f701-47b8-9b55-5143ca88dcd8 swap        1     swap        b003ea64-a38d-464c-8609-7278e21f8a0f                [SWAP]

Looking at your output it shows that your root and your swap partition are both on separate partitions/partitions, so I don’t think that would be possible since they are separated luks devices using their own encryption keys(but I’m no encryption expert). So the easier option probably would be not use a swap partition but a swap file or zram or zswap, then you could remove the swap partition. If you do decide to do that it’s also useful to know it’s not possible to shrink/grow an encrypted partition with gparted, I have tried, because being it’s a locked partition and can’t move around the blocks that way.

I almost forgot, another option would be to recreate your current swap partition but without using encryption. I’m not sure how much added security an encrypted swap adds to your system.

So in short you have two options:

  1. Use a swap file, zram or zwap instead of your current encrypted swap partition.
  2. Recreate your swap partition but as an unencrypted swap partition.

I do believe its possible to unlock the swap partition according to this anwer, by using a keyfile accessible after unlocking the root partition. I did try to do some different things, however they simply did not work as they probably are some details im not too familiar with.

With regards to your first proposed option, i agree, i should have been using a swapfile from the start. However, i do not have too much experience with changing partition sizes etc.

With regards to your second proposed option, that would basically invalidate disk encryption if im doing hibernation (in some cases).

I didn’t know that, thanks for sharing! Like I said I’m no encryption expert, I just use it. But looking at the answer of that person it looks like they used a keyscript(decrypt_keyctl) in their /etc/crypttab file which caches the first password so that the second time you get a passphrase it passes it to for the next passphrase prompt or something like that. But I checked both the Ach repos and the AUR and that script is not available for Arch.

Yeah it would would. Then it will probably be best to go for option 1 and disable your current encrypted swap option from your fstab. To then use a swap file, zram or zswap.

I believe the second part of the answer addresses distributions that isn’t shipped with that script. In that case, the keyfile is identified after the root directory has been mounted. However, this is what i suspect the my problem to be: the volume not being mounted after entering LUKS password for the root partition… not sure.

It’s been a long day, I only saw the first half. Let me read the second part.

To expand on this: I do think the EndeavorOS is meant to use this feature. After installing the OS, and selecting the option that I did want a swap partition, the swap partition has a keyslot in addition to the passphrase which is the file /crypto_keyfile.bin, located in /. In addition, /etc/crypttab looks like this:

# <name>               <device>                         <password> <options>
luks-81733cbe-81f5-4506-8369-1c9b62e7d6be UUID=81733cbe-81f5-4506-8369-1c9b62e7d6be     /crypto_keyfile.bin luks
luks-9715a3f9-f701-47b8-9b55-5143ca88dcd8 UUID=9715a3f9-f701-47b8-9b55-5143ca88dcd8     /crypto_keyfile.bin luks

which tells me that the EndeavorOS guys wanted to toggle this feature (or it may simply be a just a backup-key).

Eitherway, i get this weird message in the logs, even though the file is clearly there:

$ journalctl -xb | grep crypto_
Jul 18 18:31:23 mthinkpad systemd-cryptsetup[475]: Failed to activate, key file '/crypto_keyfile.bin' missing.

It happens automatically for grub but it is more complicated for systemd-boot because you can’t put the decryption key inside the boot image.

Oh, why is that?

It looks like in the second part they generated a key for the second partition and then added that key to the luksdevice of that partition. Then to finally add that partition to /etc/crypttab and the location where that key is store. So that when you unlock the root partition with the passphrase for the root partition the crypttab can then find the location of the key and then unlock the second partition, I think that key should then have no passphrase on it as well.

Because with systemd-boot the boot image is stored in an unencrypted location. Putting your encryption key in an unencryption location would be a bad idea.

Oh, i see. I misunderstood your first comment, sorry. But the encryption key for the swap partition is stored on an encrypted device (root device) in this case. Should not be any problem with that?

Then it probably would better and easiest to go with the option where you disable the original encrypted swap partition and going for a swap file, zram or zswap.

Yes. However, does not work :frowning:

The second part shows how to do it for non Debian/Ubuntu distributions. Where it’s possible to create a key on your root filesystem. Add that key to your luks device and then point to the location of that key your crypttab, so that when you enter the passhprase for your root filesystem, it will then have access to unlock your second partition using that key defined for that luksdevice in your crypttab.

I will have to setup an EndeavourOS with with your partition setup to try it out to see what happens. But the easier option would probably to go with first option. It will take a bit for me to install vm with your setup.

It looks like no matter what I do the swap partition always gets decrypted first, even though it’s the second option in the crypttab. So probably the same reason why it didn’t work for you, not sure if there is a way to force the order of decryption for the devices in crypttab. Although that stackexchange answer you linked to said devices in crypttab are decryped in the the order that are listed.

Yes, iirc it has been somewhat inconsistent with me as well. That is ultimately why I decided to come on here to figure this out. Thanx for ur help tho <3

1 Like