Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have a Debian Linux system (amd64) installed on a RAID-1 system encrypted device (LVM on LUKS) and will have a RAID-6 of >=4 disks where I'll put my data (LUKS and maybe LVM).

I think the basic idea is to unlock the system encrypted partition (at boot at local or via ssh) and to store a keyfile in /etc/crypttab for the RAID-6 encrypted partition. Does that pose a security risk ? I mean ... it's pretty useless if anybody can just enter my system locally / remotely and I think there are plenty of services running on servers that are vulnerable to "rooting" (e.g. SSH). Is there an alternative (beside unlocking the partition via SSH which may be a problem since e.g. backup operations start even before the data partition is mounted).

On another machine I'll use multiple disks with LUKS+greyhole (no RAID-6) for Backups and it'll be a real pain to unlock 10 disks by enterning 10 times the same password ...

share|improve this question
If someone can break into your system and become root, they don't need to get the key to your encrypted partition. There's no point in protecting it from root (and it's not possible without special hardware such as a TPM or running in a virtual machine). –  Gilles Feb 24 '12 at 23:29
Excuse me ? Even if I'm root I have to give the keyfile / passphrase to unlock LUKS partitions. I suppose you mean that if somebody becomes root it has full access to my encrypted data. Unfortunately that is simply true because once the encrypted partition is mounted, it makes no difference if it's encrypted or not. What would the advantage of a virtual machine be then ? So why should encryption help at all ? Is the only solution to deny access to root via SSH and similar services ? But still if a hacker gets into the system as a normal user he typically has read access to every file,isn't it? –  user51166 Feb 25 '12 at 7:06
Exactly, if someone is root on your system, they have access to everything. A VM can mean that they have access to everything in the VM. The only use of encryption is if someone steals your hardware. –  Gilles Feb 25 '12 at 20:14
Yeah well ... in that case we can argue that the only almost safe way to store data is in an encrypted computer disconnected from all network and integrated in the building. Then still anybody could come with a keyboard and steal your data without rebooting your system. I might as well isolate my systems from the internet since it will be a backup server therefore LAN access is all it needs. Then again ... should a VPN be used or one of the LAN machines gets infected the backup machine would be exposed as well. What would you do to solve these problems ? –  user51166 Feb 25 '12 at 21:35

1 Answer 1

You can use /lib/cryptsetup/scripts/decrypt_derived in your crypttab to automatically use the key from one disk for another.

The decrypt_derived script is part of Debian's cryptsetup package.

Small example to add the key from sda6crypt to sda5:

/lib/cryptsetup/scripts/decrypt_derived sda6crypt > /path/to/mykeyfile
cryptsetup luksAddKey /dev/sda5 /path/to/mykeyfile
ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab
shred -u /path/to/mykeyfile # remove the keyfile

As it is nowadays very difficult to really delete a file, ensure that /path/to/mykeyfile is on a encrypted drive (sda6crypt would be in my example a good solution).

In general, you can add an additional security layer by using user space filesystem encryption e.g. via encfs.

share|improve this answer
That way I shouldn't need to store the keyfile on disk. That would be nice. However do you think it's worth the trouble (i.e. storing the keyfile on the encrypted root device is "safe enough") ? I'm asking an opinion since I have some doubts. Thanks for the suggestion. –  user51166 Feb 24 '12 at 8:38
The solution with decrypt_derived has the only advantage, that there is no key file. If someone can get root access, you are normally lost anyway. Reading a key files could be a little bit easier for an intruder than running a script. To get more security, you can harden your system by using e.g. TOMOYO Linux, AppAmor, SMACK, SELinux, grsecurity,... but this takes additional efforts. And the question if it is worth is then more important. Please do not forget to have a backup of the key or a separate key for the case that the drive crashes where the key is derived from/stored on. –  jofel Feb 24 '12 at 9:19
I planned on using grsecurity or similar softwares as well (not at the start, but when I'll have time I'd secure it). I'm thinking of using only passwords and not keyfiles if possible. Well the password will be stored in RAM, so I guess you can argue about that as well. –  user51166 Feb 24 '12 at 18:02
There is no good way to delete a key file anywhere, short of overwriting the whole filesystem (and perhaps not even then if the disk fails). A journaling filesystem does not make things markedly worse. –  Gilles Feb 24 '12 at 23:27
@Gilles Since I am not an expert of safe file deletion, I edited my answer. I recommend now to store the keyfile on the encrypted drive. –  jofel Feb 25 '12 at 9:56

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.