I have some LUKS-encrypted drives in use for backups. The ‘mount at system startup’ option in the Gnome disks app (configured for both ‘encryption’ and ‘mount’ options) doesn’t prompt for a password after logging in, thus the drive remains inaccessible until several manual steps have been completed in the said app after each reboot.
I only need the password prompt to appear when the desktop environment starts (better if several drives can be configured to be unlocked at once, provided that they use the same password). The passphare file should under no circumstances be stored on disk — I’m fine with typing the password manually at every boot (until I fully understand the security implications).
Someone else asked this same question yesterday:
As for the multiple luks volumes, the way this is handles most commonly is to open one of them with your password and then store a keyfile(not your password) on that volume which opens the rest. Because the keyfile lives in an exncrypted filesystem, you can’t unlock the other volumes without first decrypting that one.
I see, I searched relatively thoroughly a couple of weeks ago.
I only use internal drives (due to S.M.A.R.T. access and heat concerns) — are internal and external drives any different in this context?
To be fair, that question hasn’t been answered yet so finding it wouldn’t have helped you much.
From a luks perspective, I don’t think it matters. Generally speaking, it is almost never harder to work with internal drives.
Yes - I asked the same question as @dalto mentioned.
I found for me a solution by using
pam_mount, more or less the same procedure as I am doing with Ubuntu.
sudo dnf install pam_mount
Find the right UUID of the encrypted disk you would like to automount after login.
Insert following row after comment row:
<!-- Volume definitions -->
<volume user="your_login_user" fstype="crypt" path="/dev/disk/by-uuid/the_uuid_of_encrypted_disk" mountpoint="path_to_your_mount_point" options="relatime" />
According to here:
Insert first row:
auth optional pam_mount.so try_first_pass
Insert first row in block
session optional pam_mount.so
Important additional note:
As said in the Ubuntu forums one of your passphrases of your LUKS encrypted disk must be the same then your login password! I did not check if this is also true for Fedora.
As I am new to Fedora can somebody confirm this procedure. Thanks.
For myself I usually use this method:
- Check devices hierarchy with
Find your device name, like “sda1”.
- Get UUID for your device with
sudo cryptsetup luksUUID /dev/sda1.
UUID will be like “1234567a-b890-1c23-45de-f67f8gh90i12”.
- Edit /etc/crypttab with sudo and add new line:
PartitionName UUID=12345 none
Where “PartitionName” - name for your encrypted partition for crypttab (change it to your),
“12345” - your UUID from step 2.
This config needed for decryption on boot stage.
- Edit /etc/fstab with sudo and add new line:
/dev/mapper/PartitionName /run/media/YOUR_USER/PartitionName/ ext4 defaults,noatime,discard,rw 0 2
Where “PartitionName” - name from step 3,
“/run/media/YOUR_USER/PartitionName/” - path for mounting your partition (change it to your),
and other usual settings for fstab mounting.
This works for me and on Fedora 36 Kinoite, and on several other distro.
The decryption password will be requested at the boot stage, even before SDDM.
This is not an automated method, but only requires running two commands per-drive (and is easy to understand) — in addition to typing the disk passphrase and the user account password. Can be saved as an
.sh script, add any drives you’d like:
# SATA SSD (1)
udisksctl unlock --block-device /dev/sdc1
udisksctl mount --block-device /dev/mapper/luks-[...]
The block device paths are examples (I’ve truncated the latter), they can be verified in Gnome Disks for instance.