Any distro would do, but for my case, it is Arch because I have more control over the partitions. I would like the OS, so root, swap and others on 1 drive. The /home should be on a separate drive. The tricky thing is to have everything encrypted, except /boot and /efi of course.

Now, here is what I can do

  1. FDE on 1 drive. This is easy: you create /efi, /boot and then create a large LUKS partition. From there, you create LVM on that LUKS partition and get your: /, /home and swap. Then mount everything correctly and install.

In the grub config, you only need to set it so it knows the LUKS partitom and where the root is. For eg, if your LUKs partition is /dev/sda3, you do:

  • cryptdevice=UUID=<uuid of the /dev/sda3>: cryptlvm rootfs=/dev/vg/root.
  1. Unencrypted /home on another drive. This is like 1) but /home is mounted on a separate drive. Still need to do the grub config, but nothing is needed for /home. It is automatically mounted when you login.

Now for my case: Encrypt /home

The encryption and mount part is easy. But how to get the OS to recognize it? The Arch wiki has this weird thing where you create an encryption key, they called it home.key, using cryptsetup. You then store the key in /etc and then in your /etc/crypttab, you specifiy the drive with /home and location of the key. No need for any passphrase.

The problem I have with this is that keys are stored in root. So if my root system is corrupted, I cant even decrypt home…

Any advice is welcome…

  • mazzilius_marsti@lemmy.worldOP
    1·
    8 hours ago

    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

    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 [email protected] and [email protected] for giving me correct ideas about “rd.luks.uuid” and that LUKS can do both pass and keyfile.

  • TorJansenEnglish
    1·
    1 day ago

    Can you use a hardware key like a Yubikey instead?

  • Lemmchen@feddit.org
    7·
    3 days ago

    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.

    • mazzilius_marsti@lemmy.worldOP
      11·
      3 days ago

      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.

      • Lemmchen@feddit.org
        8·
        3 days ago

        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.

  • treesoid@lemmy.world
    7·
    3 days ago

    You could give the home partition two keys, one stored on the root as you described and the other stored somwhere else/remembered.

  • bodaciousFern@lemmy.dbzer0.com
    3·
    2 days ago

    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

  • mina86@lemmy.wtfEnglish
    2·
    2 days ago

    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.

  • hendrik@palaver.p3x.deEnglish
    1·
    2 days ago

    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.