How do I mount encrypted drives automatically?

Ask Fedora
, , ,
1

I accomplished this on my laptop a few months ago, but I can’t figure it out again and I can’t find guides I used at the time.
Here is what I vaguely remember from my work on the laptop.
I used some command that gave me a line of code for the encrypted partition.
I used that code to avoid using the password each time.
The only downside is that since then autologin doesn’t work anymore and I have to put my password.

I would like to accomplish the name on my desktop now that I switched to fedora on that too.
I know my informations are vague at best but it’s what I remember.

As of now when I turn on my pc I have to put passwords 4 times, the encryption one, the login one and two more for the encrypted drives. It just gets a little redundant so I was hoping someone would be able to help me out in this.

Thanks in advance for any help or even just for reading this far.

1 Like
2

If the partitions are LUKS encrypted, you can use cryptsetup to add a keyfile as an additional unlocking method, as documented here: How to add a passphrase, key, or keyfile to an existing LUKS device - Red Hat Customer Portal

You can store the keyfile somewhere only accessible to root (such as /root) on the first encrypted partition that you unlock manually with a password, and then edit the /etc/crypttab entry to use that keyfile to unlock it automatically. You’ll still need to enter the decryption password for the root partition, as well as your login password once the system boots to the login screen, but that’s it—the rest should unlock automatically.

1 Like
3

Thank you for your time Amaranth, and sorry it took me a while to reply, I’ve been overworked T_T
I was reading the page and something I am unsure about is, should the keyfile be one for each encrypted drive?
Also, why create the tile using
dd if=/dev/random bs=32 count=1 of=/root/random_data_keyfile1
instead of just touch /root/random_data_keyfile1 ?

5

I didn’t analyze your approach in total but your question about dd / touch catched my eye. Keep in mind that your “compromise” of security uses a key file to decrypt devices so that you do not have to type a password. The result is, that the key file acts as password: the key file has to be always the exact same as all its content is effectively used as password. However, that also means that everyone who has access to this key file, has automatically access to your devices. Therefore, the key file should contain arbitrary content that cannot be predicted by attackers (just like a password): if the attacker can predict the key file, they can try to create it themselves (just like guessing a password).

A touch command would create an empty file, which effectively is an empty password: so it would be the same security as having no encryption at all. I am indeed not sure if cryptsetup would accept an empty file (that is like giving no value when you have to enter your password, but I am not 100% sure if the file name is considered in dm-crypt too), but even if so, encryption would be effectively “broken by design” if you use an empty file.

Keep in mind that the key file has to be stored securely, and once it is stored in a way that an attacker has access to it, the encryption of devices has no longer any value and is effectively disabled (as the attacker can use the key file to decrypt the devices the same way you can).

Anyway, if you have no storage shortage on an embedded device or so, I think bs=32 count=1 is a bit weak too: use bigger files! Just like long passwords. I am not sure off the cuff if a key file is used with a key derivation function by dm-crypt, which means I suggest to use at least 256 bit (unless someone can say for sure otherwise). If you have the space, you can use more to further mitigate potential advances with regards to the circumstances you use this. I massively simplified, but I hope that makes somehow sense :classic_smiley:

6

bs=32 count=1 does create a 256-bit (= 32-byte) passkey, which seems plenty strong, far stronger than the vast majority of passwords. Certainly I don’t think anyone would say a password consisting of 32 randomly generated keyboard characters is too weak, and this is much stronger than that since the bytes are arbitrary (8 bits each) rather than being restricted to the characters available on a standard English keyboard.

But if you want the extra security margin, of course it’d be harmless enough to use 64 bytes instead of 32…

1 Like
7

Indeed, dd bs= uses byte, not bit. Off the cuff I mixed it up. Once I am in crypto, I have only bits in mind :classic_smiley: Obviously, I didn’t use dd for some time. So yeah, 32 byte is fine if it is assumed that the content is arbitrary.

→

So yeah, 32 byte is fine as it is 256 bit.

However, the circumstances I meant refer to the quality of the random numbers: 256 bit is fine and there is no need to go beyond that IF numbers are purely arbitrary. This refers to the possibility if a random number generator can be predicted or guessed to some extent. This used to be a real risk that was debated (more sources of entropy to get more entropy - so higher quality, so unpredictability, of random numbers - also increased attack vectors to corrupt the entropy, etc.), but if you use a current Linux kernel (with Fedora, I presume you have a 6+ kernel), the random number generator you have is unlikely to produce random numbers that can be predicted (more precisely, it is unlikely that the input of the random number generator can be predicted to a level that allows predicting output of the output): the generator of the current kernel is simple and very effective, and incorporates many security guarantees. Therefore, as I mentioned in my last post, 256 bit is fine, and it is unlikely that this will be broken if it is produced by a current number generator (such as the one of the current kernel).

Obviously, the major attack vectors to key files are different anyway (get them where the user stores them - key management and such) …

Indeed, if you have the space, why not → just don’t go to the gigabytes, as this needs to be processed on each luksOpen :classic_smiley:

8

Gnome-disks makes it very easy to auto-mount encrypted (and non-encrypted) drives automatically during boot/login.
You would just need to type your encryption password, if you haven’t integrated it with TPM to by pass it and your user password. Gnome-disks only asks for your encryption passphrase and your user password to unencrypt and mount the partition and saves it (for each drive). So it won’t ask for it each time you start your system.

9

I once again apologize for the long gap between replies but lately I have only a few hours in the morning before working all day.

Anyway, my drives are already encrypted and already have data in them, so I wouldn’t need to create a password. Using

dd if=/dev/random bs=32 count=1 of=/root/random_data_keyfile1

would create a random password, am I correct? The reason why I was wondering why I shouldn’t just use touch is because already having a password it felt redundant to create a file full of “noise” to just delete the content and replace with my own password.

And Marcelo, I tried to use gnome disk for that but when I login I still have to manually enter 4 password. The encryption password for the drives followed by my user password, once for each drive.
So, booting my pc as of now looks like this:
Boot. Enter encryption password. Enter user password. Encryption password2. User password. Encryption password3. User password.

10

Don’t worry. There is no no need to stress :classic_smiley:

it takes once (count=1) 32 byte (bs=32) (=256 bit) from the output of /dev/random and puts in /root/random_data_keyfile1.

/dev/random is the random number generator of the kernel. This means, it is arbitrary numbers that are output by this generator and at the best, they have no structure that can be predicted or so (which obviously is the major disadvantage of human made passwords). The random number generator of the kernel can be considered a secure one, and it is unlikely that any attacker would be able to predict its output. With dd (but also with other commands), you can take as much random numbers from this generator as you want. And these random numbers are then used as content for the key file.

I assume you use a key configuration/setup that involves dm-crypt/luks2/cryptsetup. This allows you to use multiple passwords and/or key files. Each is on itself able to decrypt the device. So you need any one of them to decrypt, never all. If you currently use a password and you add a key file, then you need either one of them to decrypt. For the device, both are the same: each (password or key file) is a way to decrypt the actual key of the device, and then the actual key of the device is used to decrypt the device (your password or the key file just encrypt/decrypt the actual key for the encryption/decryption of the device, they are not themselves the actual key for the device).

You can keep both the password and the key file, so that you can use both to decrypt. This, for example, can help to still decrypt your data with the password if you loose your key file, and vice versa. But you can also remove any one of them: cryptsetup will accept adding and deletion of passwords/key-files as long as there is at least 1 variant to decrypt remaining after the deletion. I don’t know if that has been updated in the mean time, but I assume the limit of passwords/key-files is 32.

I already wrote it above, but want to highlight that if you remove your password after you added the /dev/random-derived key file, you will depend on this file, and if it gets lost, your data of the device is lost too. So if your password is secure, and if you can remember it, then it is a good way to mitigate that risk. On the other hand of course, if there is a key file AND a password, any potential attacker would need only one of the two in order to get access. Typical security compromise :classic_smiley:

This link refers to a setup of luks1. If you use Fedora, I expect you already use luks2. I presume that the command is still the same, and the command is formulated in a way that does not alter the standard attributes (which your Fedora correspondingly will do itself based on current standardization). So I presume that is fine. But you might want to verify it before going to an irreversible production case. Arch wiki has good documentation of cryptsetup/luks2, but that is quite detailed and technical, but there is much available on the Internet about cryptsetup, and maybe arch wiki is sufficient to verify the commands. I remember that some commands have been replaced in the past years, but the old ones are still accepted I think, only with a warning or so. Or just man cryptsetup. Anyway, I just wanted to raise awareness.

1 Like
11

Thank you very much for the help, it’s much appreciated :slight_smile:

1 Like