You can always have a copy of the keyfile somewhere else, on an USB drive for example.
Alternative is to also add a passphrase to the /home luks partition.
Linux
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
yeh if I encrypt /home using luks with passphrase, so cryptsetup. How do I tell the OS to decrypt it? I tried passphrase before and it cannot boot because /home cannot be mounted. That is why I searched and found out about the Arch wiki way: using keyfile stored in root.
LUKS does offer multiple key slots. You can have the OS unlock it with a keyfile and be able to manually unlock it with a keyphrase when you don't have access to that file.
I'm not sure if you can tell the OS to unlock it with a passphrase on boot like with the root partition.
You can.
I honestly can't remember the details, but I followed an Arch guide somewhere (probably the wiki). It definitely prompts me for passphrase on boot.
That's the simplest answer.
You could give the home partition two keys, one stored on the root as you described and the other stored somwhere else/remembered.
But how to get the OS to recognize it?
My approach for doing this in Gentoo with an encrypted /home is to configure dracut to make a slightly customized initrd.
Thanks to dracut modules, not too much configuration is needed - it prompts on boot for the password to decrypt, and then fstab is just configured to mount the decrypted uuid.
Someone else mentioned using multiple key slots, but I think this is your only real secure option.
Edit: on second thought, you may be able to get this to work in grub simply by adding rd.luks.uuid=xxx
as a kernel boot parameter, and then having the decrypted /dev/mapper uuid in fstab for /home
If you go with adding a passphrase to the drive keep in mind that if it’s a unique one you may end up forgetting it since you won’t normally be using it. Even if you set it to the same passphrase as root partition, if you ever change passphrase for root you might forget to change home passphrase.
I would probably just make a physical copy of the key file. It’s just 32 bytes (no, larger key file doesn’t make things any more secure) so you can hexdump -C
it and copy the key on a piece of paper.
Well thanks everyone. I finally managed to get it to work on Arch. System has separate encrypted root and swap in LVM, and a separate encrypted home. It can suspend and hibernate. Below are my steps
DISK PREP
-
partition the main drive for your swap and root first. For me, it is a boot partition + an EFI + a LUKS container with LVM on top. Create your volumes. I use Arch, so format and mount them appropriately before pacstrap. Leave out mount point for /home.
-
Go to your other drive, follow: https://www.cyberciti.biz/hardware/cryptsetup-add-enable-luks-disk-encryption-keyfile-linux/
to create a LUKS container that is encrypted with: a keyfile and a password. Test both to make sure you can open the locked drive. Format and mount it at /mnt/home or where you want the /home to be.
- Pacstrap and then genfstab.
Important: Make sure to copy the keyfile from your archiso environment to your chroot environment aka your system. Otherwise, when reboot, the keyfile is gone. I put it in /root and set permission so only root can read.
AUTOMATIC UNLOCK
-
First, fstab. When you do genfstab, things should be fine. But just double check the UUID is correct for /home. Note in fstab, the UUID is the unlocked one: so the one with /dev/mapper/home. Change to noatime if you desire.
-
Second, crypttab. Assume you decrypt your LUKS home as "home". Add this:
home uuid of the unencrypted home drive location of the keyfile luks
The link above said to just use /dev/sda, but imo UUID is safer if you have a removable drive.
- Third, grub. Edit your /etc/default/grub and append the following to GRUB_CMD_LINUX:
"rd.luks.uuid=UUID of the locked luks home drive"
FOR HIBERNATION
For some reasons, hibernation doesnt work out of the box. It works when I have everything in 1 drive, i.e 1 boot, 1 efi, 1 lvm on luks for /home, swap and /. The fix is simple:
-
add "resume" to /etc/mkinitcpio.conf. Add before "filesystems" . Rebuild your initramfs with mkinitcpio -P.
-
add to /etc/default/grub: "resume= uuid of the unlocked swap partition". Or if you do LVM, just use "resume=/dev/vg/swap".
Special thanks to bodaciousFern@lemmy.dbzer0.com and Lemmchen@feddit.org for giving me correct ideas about "rd.luks.uuid" and that LUKS can do both pass and keyfile.
I went with the option with keyfiles. I keep backups of LUKS headers and keyfile in case a harddisk gets damaged. Currently have that stored as a file attachment in my password manager.
Can you use a hardware key like a Yubikey instead?
Why do you need /home to be on a separate drive?
3 ... 2 ... 1 ...
What?
Sorry, was expecting a flood that didn't happen I guess. Why a separate partition for home (or var, or whatever you want to split off)? See
Because you can format your system without deleting your personal files
I am aware of the perks of having your /home not tied to your root filesystem. In my case, I have a single LUKS2 encrypted btrfs partition with separate subvolumes for root and home.
I just don't see the reasoning for having it on a separate drive, as the OP explicitly states in their post. Both drives would have the same likelyhood of failing and it makes encryption (though, only slightly) harder.
Well then, carry on Ethan!