How to setup Luks on Debian 7 here
https://dl.dropboxusercontent.com/u/40638984/how_to_lvm_debian_wheezy.pdf
Make sure to allow a root partition of 300mb, see note.
Debian w/LUKS root+key file on USB
https://dl.dropboxusercontent.com/u/40638984/how_to_lvm_debian_wheezy.pdf
Make sure to allow a root partition of 300mb, see note.
Debian w/LUKS root+key file on USB
There
are a few advantages to booting a system onto an encrypted root volume
using LUKS keyfiles instead of passphrases. Using keyfiles, booting to
an encrypted root volume can once again be automatic - no more
entering a passphrase at the console during each boot cycle.
Alternatively, the key-containing volume can be removed after boot and
kept secure, so that the system can only be rebooted by the owner.
Following this guide should be quite safe. It's possible to maintain secondary access via the original passphrase still in LUKS's keystore, and relatively trivial to restore the original crypttab configuration. Still, it's best to have complete backups before you begin! I'll give some troubleshooting tips following the setup instructions.
NOTE: All bets are off unless you're running Debian GNU/Linux version 7.4 ("Wheezy") with a LUKS-encrypted root partition for which you possess the passphrase. You'll also need a spare USB thumb drive formatted as FAT32.
Setup
First, plug in your FAT32 or ext2 formatted USB drive and create within it a file of random content, about four kilobytes should do nicely:
dd if=/dev/urandom of=/media/THUMBDRIVE/keyfile bs=1024 count=4
Next, add this key to the LUKS keystore:
sudo cryptsetup luksAddKey /dev/sda1 /media/THUMBDRIVE/keyfile
Now the container can be decrypted using the key file. Next we'll need to set up crypttab to inform LUKS about where this key can be found. To do that, first lets get the USB drive's UUID, so we can reliably refer to it in our configuration:
ls /dev/disk/by-uuid/ | grep sda
Next, we'll need to direct LUKS to use this keyfile upon booting. Edit /etc/crypttab and make the root partition's line look like this:
sda5_crypt UUID=<LUKS Container UUID> /dev/disk/by-uuid/<USB drive UUID>:<USB key file name> luks,keyscript=/lib/cryptsetup/scripts/passdev
The real magic is in that last bit about the passdev keyscript. Because the decryption must take place so early in the boot process, USB disks are not normally mounted. In the past, we'd had to carefully write our own scripts that would find and mount the USB volume, then include that script in the initramfs. The developers of cryptsetup have included a solution, these days: passdev. Supplied a block device path (we use by-uuid because it will remain consistent across hardware changes) and a file path, passdev will temporarily mount the device and stream the file to STDOUT.
Finally, lets prepare the new, USB keyfile-aware initramfs. We'll have to direct initramfs to load some new modules into future builds. We'll need these in order for the kernel to access USB devices so early in the boot process. Edit /etc/initramfs-tools/modules and add the following lines:
vfat
fat
nls_cp437
nls_iso8859_1
nls_utf8
sd_mod
scsi_mod
usb-storage
usb-hid
uhci-hcd
ohci-hcd
ehci-hcd
usbcore
If you want, you can trim this down a bit if you know what encoding is in use by your filesystem, and choosing ext2 over FAT32. Personally, I prefer to use the FAT32 format because it is the standard default of most thumb drives, allowing me to buy an off-the-shelf disk and copy the key onto it in an emergency. The downside to this is that we need to support the several encoding flavors that geographically local FAT32 typically comes in: UTF-8, iso8859_1, and codepage 437.
Now, lets rebuild our initramfs using these modules and our modified /etc/crypttab. Type this command at a shell:
update-initramfs -u
...that's it, we're done! During the next reboot, grub (or whatever bootloader you're using) will load the initramfs and stub kernel, which will source the initramfs version of /etc/crypttab, causing the initramfs version of /lib/cryptsetup/scripts/passdev to be run with correct arguments, temporarily mounting the USB disk and piping the keyfile into cryptsetup, mounting the encrypted root container, allowing the boot process to pivot away from initramfs and into your real file system.
Using the alternate passphrase
If the system can't find the keyfile at boot time, you'll find yourself at a BusyBox prompt running from within the system's initramfs. As long as your original passphrase is still loaded into a LUKS key slot (i.e. you haven't intentionally removed it), simply issue these commands at the BusyBox shell, replacing /dev/sda1 with your LUKS container's partition, sda1_crypt with your encrypted root volume's name within /dev/mapper, and entering the passphrase when prompted after issuing the first command:
cryptsetup luksOpen /dev/sda1 sda1_crypt
vgchange -ay
Restore /etc/crypttab to its working state, regenerate your initramfs, and then reboot. You should see the familiar LUKS passphrase prompt, as before we started.
Removing the alternate passphrase
It is also possible to remove the original passphrase from the LUKS keystore, leaving the keyfile as the only way of booting the system. Issue the following command and, when prompted, enter the passphrase to be removed:
cryptsetup luksRemoveKey /dev/sda1
Following this guide should be quite safe. It's possible to maintain secondary access via the original passphrase still in LUKS's keystore, and relatively trivial to restore the original crypttab configuration. Still, it's best to have complete backups before you begin! I'll give some troubleshooting tips following the setup instructions.
NOTE: All bets are off unless you're running Debian GNU/Linux version 7.4 ("Wheezy") with a LUKS-encrypted root partition for which you possess the passphrase. You'll also need a spare USB thumb drive formatted as FAT32.
Setup
First, plug in your FAT32 or ext2 formatted USB drive and create within it a file of random content, about four kilobytes should do nicely:
dd if=/dev/urandom of=/media/THUMBDRIVE/keyfile bs=1024 count=4
Next, add this key to the LUKS keystore:
sudo cryptsetup luksAddKey /dev/sda1 /media/THUMBDRIVE/keyfile
Now the container can be decrypted using the key file. Next we'll need to set up crypttab to inform LUKS about where this key can be found. To do that, first lets get the USB drive's UUID, so we can reliably refer to it in our configuration:
ls /dev/disk/by-uuid/ | grep sda
Next, we'll need to direct LUKS to use this keyfile upon booting. Edit /etc/crypttab and make the root partition's line look like this:
sda5_crypt UUID=<LUKS Container UUID> /dev/disk/by-uuid/<USB drive UUID>:<USB key file name> luks,keyscript=/lib/cryptsetup/scripts/passdev
The real magic is in that last bit about the passdev keyscript. Because the decryption must take place so early in the boot process, USB disks are not normally mounted. In the past, we'd had to carefully write our own scripts that would find and mount the USB volume, then include that script in the initramfs. The developers of cryptsetup have included a solution, these days: passdev. Supplied a block device path (we use by-uuid because it will remain consistent across hardware changes) and a file path, passdev will temporarily mount the device and stream the file to STDOUT.
Finally, lets prepare the new, USB keyfile-aware initramfs. We'll have to direct initramfs to load some new modules into future builds. We'll need these in order for the kernel to access USB devices so early in the boot process. Edit /etc/initramfs-tools/modules and add the following lines:
vfat
fat
nls_cp437
nls_iso8859_1
nls_utf8
sd_mod
scsi_mod
usb-storage
usb-hid
uhci-hcd
ohci-hcd
ehci-hcd
usbcore
If you want, you can trim this down a bit if you know what encoding is in use by your filesystem, and choosing ext2 over FAT32. Personally, I prefer to use the FAT32 format because it is the standard default of most thumb drives, allowing me to buy an off-the-shelf disk and copy the key onto it in an emergency. The downside to this is that we need to support the several encoding flavors that geographically local FAT32 typically comes in: UTF-8, iso8859_1, and codepage 437.
Now, lets rebuild our initramfs using these modules and our modified /etc/crypttab. Type this command at a shell:
update-initramfs -u
...that's it, we're done! During the next reboot, grub (or whatever bootloader you're using) will load the initramfs and stub kernel, which will source the initramfs version of /etc/crypttab, causing the initramfs version of /lib/cryptsetup/scripts/passdev to be run with correct arguments, temporarily mounting the USB disk and piping the keyfile into cryptsetup, mounting the encrypted root container, allowing the boot process to pivot away from initramfs and into your real file system.
Using the alternate passphrase
If the system can't find the keyfile at boot time, you'll find yourself at a BusyBox prompt running from within the system's initramfs. As long as your original passphrase is still loaded into a LUKS key slot (i.e. you haven't intentionally removed it), simply issue these commands at the BusyBox shell, replacing /dev/sda1 with your LUKS container's partition, sda1_crypt with your encrypted root volume's name within /dev/mapper, and entering the passphrase when prompted after issuing the first command:
cryptsetup luksOpen /dev/sda1 sda1_crypt
vgchange -ay
Restore /etc/crypttab to its working state, regenerate your initramfs, and then reboot. You should see the familiar LUKS passphrase prompt, as before we started.
Removing the alternate passphrase
It is also possible to remove the original passphrase from the LUKS keystore, leaving the keyfile as the only way of booting the system. Issue the following command and, when prompted, enter the passphrase to be removed:
cryptsetup luksRemoveKey /dev/sda1
I have posted this here because the original page is nolonger available and it should be kept because it works..
