Difference between revisions of "Talk:Dm-crypt"
(→Specifying skip and count in /etc/crypttab for /tmp) |
(Remove closed discussions.) |
||
(35 intermediate revisions by 9 users not shown) | |||
Line 11: | Line 11: | ||
Does anyone have objections to my plans, or should I just go ahead and we can revert back if it doesn't fit? | Does anyone have objections to my plans, or should I just go ahead and we can revert back if it doesn't fit? | ||
+ | [[User:WhiteMagic|WhiteMagic]] 12:56, 24 May 2007 (EDT) | ||
− | |||
: Clean up is really needed. Please someone with enough knowledge start the job. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 02:55, 8 June 2012 (UTC) | : Clean up is really needed. Please someone with enough knowledge start the job. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 02:55, 8 June 2012 (UTC) | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Luks and suspend2 == | == Luks and suspend2 == | ||
− | |||
Would it be worth adding a section on opening encrypted drives from the kernel command line, or more specifically on combining luks and suspend2? As far as I can tell opening a swap partition from crypttab doesn't make it available in time to resume from, but adding the following to a lilo append option does: | Would it be worth adding a section on opening encrypted drives from the kernel command line, or more specifically on combining luks and suspend2? As far as I can tell opening a swap partition from crypttab doesn't make it available in time to resume from, but adding the following to a lilo append option does: | ||
resume2=swap:/dev/mapper/swap cryptdevice=/dev/sda2:swap | resume2=swap:/dev/mapper/swap cryptdevice=/dev/sda2:swap | ||
I'm not sure if this is the correct/best way of doing this, though, and didn't see other documentation. | I'm not sure if this is the correct/best way of doing this, though, and didn't see other documentation. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Proposed update of the section 'Storing the key between MBR and 1st partition' == | == Proposed update of the section 'Storing the key between MBR and 1st partition' == | ||
− | |||
{| style="background-color: #f3f9ff; margin: 1em 2.5% 0 2.5%; padding: 3px 3px; border: 1px solid #aaa;" | {| style="background-color: #f3f9ff; margin: 1em 2.5% 0 2.5%; padding: 3px 3px; border: 1px solid #aaa;" | ||
|- | |- | ||
Line 171: | Line 66: | ||
That's all, reboot and have fun! And look if your partitions still work after that ;-). | That's all, reboot and have fun! And look if your partitions still work after that ;-). | ||
− | |||
− | |||
− | |||
− | |||
== LVM2 and LUKS == | == LVM2 and LUKS == | ||
− | |||
I'm quite sure this section is misleading. You have to setup up encryption ''before'' LVM2 partitions on the decrypted device. | I'm quite sure this section is misleading. You have to setup up encryption ''before'' LVM2 partitions on the decrypted device. | ||
Line 188: | Line 78: | ||
- This section is misleading. What the author meant was if you encrypt the contents of LVM partitions, THEN you have to move the lvm2 hook before the encrypt hook. I made a few small changes, so other newbies (like me) don't end up with an unbootable system. | - This section is misleading. What the author meant was if you encrypt the contents of LVM partitions, THEN you have to move the lvm2 hook before the encrypt hook. I made a few small changes, so other newbies (like me) don't end up with an unbootable system. | ||
+ | -- I also agree that the section needs a further overhaul, assuming here everyone commenting means the "Encrypting and LVM Setup" (because "LVM2 and LUKS" is not in the TOC). Having encrypt over (i.e. before) LVM is def the typical and easiest setup (and this should be expanded on more clearly in the wiki like in the link above I agree). However, all methods have a usecase. It depends what the user wants to achieve. Time permitting, the differences should be worked out. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:53, 18 September 2012 (UTC) | ||
− | == Prepare hard drive == | + | == <s> Prepare hard drive </s> == |
The actual text is: | The actual text is: | ||
Line 205: | Line 96: | ||
[/code] | [/code] | ||
When asked for {{ic|/}} (root) partition: is it {{ic|/dev/mapper/root}} or {{ic|/dev/mapper/lvm-root}}. I suppose it is the first one because the second one does not match. | When asked for {{ic|/}} (root) partition: is it {{ic|/dev/mapper/root}} or {{ic|/dev/mapper/lvm-root}}. I suppose it is the first one because the second one does not match. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Decryption of root during boot with the assistance of UDEV when key is stored on USB drive between MBR and 1st Partition == | == Decryption of root during boot with the assistance of UDEV when key is stored on USB drive between MBR and 1st Partition == | ||
− | |||
The instructions in the wiki were very helpful but a bit confusing/lacking when it comes to getting Decryption via USB keyfile stored between MBR and 1st Partition. | The instructions in the wiki were very helpful but a bit confusing/lacking when it comes to getting Decryption via USB keyfile stored between MBR and 1st Partition. | ||
Line 246: | Line 122: | ||
[[User:S0ma|S0ma]] 13:48, 16 December 2011 (EST) | [[User:S0ma|S0ma]] 13:48, 16 December 2011 (EST) | ||
− | == | + | == systemd addidtions == |
− | + | systemd requires lvm-on-cryptdevice.service active in order to open LVMs on cryptdevices that are not the root partition (which is handled by the initrd). | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | == after 2012.07.15 == | |
− | |||
− | : | + | What change with the new installation process and systemd change ? If I understand correctly parts related to /etc/rc.conf files are no longer useful but what's the correct way now ? thanks --[[User:Martvefun|Martvefun]] ([[User talk:Martvefun|talk]]) 00:27, 9 January 2013 (UTC) -> question and response asked[https://bbs.archlinux.org/viewtopic.php?id=155863|here] |
+ | :For reference - two more bbs threads covering the subject: [https://bbs.archlinux.org/viewtopic.php?pid=1212076#p1212076| with systemd] and [https://bbs.archlinux.org/viewtopic.php?pid=1170012#p1170012| with a nice backup script]--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:07, 9 January 2013 (UTC) | ||
− | + | == Encrypted swap With suspend-to-disk support == | |
+ | Shouldn't the openswap hook go after the encrypt hook? Otherwise you have to always open the root device prior to the swap, even on resume. | ||
+ | :You meant to write ".. the openswap go before encrypt ..?" which sounds like a reasonable suggestion. Have you tried it? (I have not). Maybe it works still (without manual unlocking of root) because of the kernel parameter resume=.. In Debian it would go after, but there the key for swap is derived by the hook from the root master key (hence not input extra for swap, which is elegant).--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:06, 6 February 2013 (UTC) |
Revision as of 05:46, 2 May 2013
Contents
- 1 Cleanup and Clarification
- 2 Luks and suspend2
- 3 Proposed update of the section 'Storing the key between MBR and 1st partition'
- 4 LVM2 and LUKS
- 5
Prepare hard drive - 6 Decryption of root during boot with the assistance of UDEV when key is stored on USB drive between MBR and 1st Partition
- 7 systemd addidtions
- 8 after 2012.07.15
- 9 Encrypted swap With suspend-to-disk support
Cleanup and Clarification
Hello. This wiki page while very exhaustive in content is tangenital with a fractured flow. It seems the prefered method for straight forward system encryption in single drive systems is to use a combination of Luks and LVM2 - this solution provides for an encrypted swap that does not have any issues with hibernation or suspend. I propose making this section the first part of the wiki page to follow the justification for using Luks with the rather large volume of detailed information to follow in other sections. If there are no objections I'll go ahead and structure this in the wiki page itself. Vinhsynd 9:55, 30 September 2010 (CDT)
Hey all, I was trying to encrypt my hd using this page as a reference, but it was a bit difficult to read. As such, I'm going to try to clean things up a bit. It would be nice if there were a clean set of instructions with tips along the way for specialized setups.
On a related note... would anyone mind if some of the posts on this page were erased? There are a number of posts from 2007, 2008... --Arcanazar 13:22, 21 August 2010 (EDT)
I'm considering to do some editing and rewriting of this page, mainly in part "4 The Steps". The content would mostly stay the same, safe for some changes introduced with the newer versions of arch, where less console switching and module loading is needed. On the same subject should we drop, or move to a subsection, the parts related to versions 0.72 of arch?
Does anyone have objections to my plans, or should I just go ahead and we can revert back if it doesn't fit? WhiteMagic 12:56, 24 May 2007 (EDT)
- Clean up is really needed. Please someone with enough knowledge start the job. -- Fengchao (talk) 02:55, 8 June 2012 (UTC)
Luks and suspend2
Would it be worth adding a section on opening encrypted drives from the kernel command line, or more specifically on combining luks and suspend2? As far as I can tell opening a swap partition from crypttab doesn't make it available in time to resume from, but adding the following to a lilo append option does:
resume2=swap:/dev/mapper/swap cryptdevice=/dev/sda2:swap
I'm not sure if this is the correct/best way of doing this, though, and didn't see other documentation.
Proposed update of the section 'Storing the key between MBR and 1st partition'
Background
I tried to setup automatic mount of my LUKS encrypted |
Add the temporary keyfile we created before with cryptsetup:
cryptsetup luksAddKey /dev/hda3 secretkey
That should return you output like this:
Enter any LUKS passphrase: key slot 0 unlocked. Command successful.
Next you'll have to write the key directly between MBR and first partition.
WARNING: you should only follow this step if you know what you are doing - it can cause data loss and damage your partitions or MBR on the stick!
If you have a bootloader installed on your drive you have to adjust the values. E.g. GRUB needs the first 16 sectors, you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your GRUB installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key.
Optional
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors hexcurse 64sectors # determine free space
Write your key to the disk:
dd if=secretkey of=/dev/usbstick bs=512 seek=4
If everything went fine you can now overwrite and delete your temporary secretkey:
shred --remove --zero secretkey
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.
Now you have to add a kernel parameter in your /boot/grub/menu.lst
(GRUB), it should look something like this:
kernel /vmlinuz-linux root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048 cryptdevice=/dev/hda4:home
Format for the cryptkey option:
cryptkey=BLOCKDEVICE:OFFSET:SIZE
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be (if you use skip=16 in the 'dd' command above to protect the bootloader)
kernel /vmlinuz-linux root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048 cryptdevice=/dev/hda4:home
Format for the cryptdevice option:
cryptdevice=BLOCKDEVICE:MAPPING_TARGET
The encrypted block device BLOCKDEVICE will then be mapped to /dev/mapper/MAPPING_TARGET
Note: You will _not_ need to have /etc/crypttab
setup for this device then (but maybe you want to use it for other encrypted devices where you want to enter the passphrase manually or e.g. use a keyfile stored on this afterwards decrypted partition)! But don't forget to activate the encrypt hook in /etc/mkinitcpio.conf
(_before_ the filesystems hook)
That's all, reboot and have fun! And look if your partitions still work after that ;-).
LVM2 and LUKS
I'm quite sure this section is misleading. You have to setup up encryption before LVM2 partitions on the decrypted device.
And you have to add the "encrypt" hook before the "lvm2" hook, because you need to make the decrypted device available before LVM2 imports volume groupe and makes logical volumes available.
Yet this chapter tends to tell the other way round. Is my English so bad ?
I agree.. I find this entire wiki article unnecessarily complicated .. this link for an LVM on top of an encrypted partition is MUCH!!! easier to follow, and for a laptop would be better. Arch Linux: LVM on top of an encrypted partition
- This section is misleading. What the author meant was if you encrypt the contents of LVM partitions, THEN you have to move the lvm2 hook before the encrypt hook. I made a few small changes, so other newbies (like me) don't end up with an unbootable system.
-- I also agree that the section needs a further overhaul, assuming here everyone commenting means the "Encrypting and LVM Setup" (because "LVM2 and LUKS" is not in the TOC). Having encrypt over (i.e. before) LVM is def the typical and easiest setup (and this should be expanded on more clearly in the wiki like in the link above I agree). However, all methods have a usecase. It depends what the user wants to achieve. Time permitting, the differences should be worked out. --Indigo (talk) 19:53, 18 September 2012 (UTC)
Prepare hard drive
The actual text is:
Skip the Partitioning and Auto-Prepare business and go straight to "Set Filesystem Mountpoints". When asked for your /
(root) partition, do NOT select /dev/sda3
as you normally would. Select /dev/mapper/root
instead. Similarly, use /dev/mapper/home
instead of /dev/sda4
as the partition to be mounted as /home
. The same is valid for a swap partition which is set up like the home partition. Make sure you mount /dev/sda1
as the /boot
partition or else the installer will not properly set up the bootloader.
but the Arch Linux installer says:
[code]
/dev/sda1
/dev/sda2
/dev/mapper/root
/dev/mapper/lvm-home
/dev/mapper/lvm-root
/dev/mapper/lvm-swap
/dev/mapper/lvm-tmp
[/code]
When asked for /
(root) partition: is it /dev/mapper/root
or /dev/mapper/lvm-root
. I suppose it is the first one because the second one does not match.
Decryption of root during boot with the assistance of UDEV when key is stored on USB drive between MBR and 1st Partition
The instructions in the wiki were very helpful but a bit confusing/lacking when it comes to getting Decryption via USB keyfile stored between MBR and 1st Partition.
System_Encryption_with_LUKS#Storing_the_key_between_MBR_and_1st_partition makes references to /dev/usbkey
but the previous instructions aren't entirely clear on how to ensure your usb drive can always be found at this location.
When modifying your bootloader you will be unable to use /dev/disk/by-uuid because you are not referencing a filesystem. You wouldn't want to use /dev/sd[x] because this can and will change depending on what other drives and media you have connected during boot. The best bet is to create a udev rule that will exist in early userspace to alias your usb drive to an arbitrary name, in this case "usbkey". The rule must be added to the initial ramdisk so it can be read and processed to alias your drive at /dev/usbkey before root decryption is attempted via the key hidden on the drive.
System_Encryption_with_LUKS#Using_udev runs you through the initial steps you need to create a basic rule based on the USB drive's serial number. That is the very same rule I used. I named the rules file "62-usbkey.rules" and placed it in /etc/udev/rules.d/
.
Now modify /etc/mkinitcpio.conf
, look for the "FILES" section and add the udev rule that you created above:
# FILES # This setting is similar to BINARIES above, however, files are added # as-is and are not parsed in any way. This is useful for config files. # Some users may wish to include modprobe.conf for custom module options # like so: # FILES="/etc/modprobe.d/modprobe.conf" FILES="/etc/udev/rules.d/62-usbkey.rules"
Run mkinitcpio ala Mkinitcpio#Image_creation_and_activation and rebuild your ramdisk with the new udev rule you've included. You can now continue to follow the instructions in System_Encryption_with_LUKS#Storing_the_key_between_MBR_and_1st_partition to modify your bootloader and substitute references to "usbkey" to whatever you named your drive alias above.
S0ma 13:48, 16 December 2011 (EST)
systemd addidtions
systemd requires lvm-on-cryptdevice.service active in order to open LVMs on cryptdevices that are not the root partition (which is handled by the initrd).
after 2012.07.15
What change with the new installation process and systemd change ? If I understand correctly parts related to /etc/rc.conf files are no longer useful but what's the correct way now ? thanks --Martvefun (talk) 00:27, 9 January 2013 (UTC) -> question and response asked[1]
- For reference - two more bbs threads covering the subject: with systemd and with a nice backup script--Indigo (talk) 20:07, 9 January 2013 (UTC)
Encrypted swap With suspend-to-disk support
Shouldn't the openswap hook go after the encrypt hook? Otherwise you have to always open the root device prior to the swap, even on resume.
- You meant to write ".. the openswap go before encrypt ..?" which sounds like a reasonable suggestion. Have you tried it? (I have not). Maybe it works still (without manual unlocking of root) because of the kernel parameter resume=.. In Debian it would go after, but there the key for swap is derived by the hook from the root master key (hence not input extra for swap, which is elegant).--Indigo (talk) 22:06, 6 February 2013 (UTC)