LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   How to unlock (Luks) encrypted root, during boot, when key-file is on USB?? (http://www.linuxquestions.org/questions/slackware-14/how-to-unlock-luks-encrypted-root-during-boot-when-key-file-is-on-usb-909413/)

pizzar0 10-21-2011 03:52 PM

How to unlock (Luks) encrypted root, during boot, when key-file is on USB??
 
Greetings. Being fresh out of ideas regarding the following problem any advise would be much appreciated;

How to enable a USB drive, containing cryptsetup's "--key-file" to unlock the encrypted root partition - whether its on the same (usb) drive or on an other drive (sdX) - during boot, making it unnecessary to physically enter a pass-phrase during the boot process??

What's been tried so far (aside form collecting probably the largest body of "solutions" known to Google, none of which appears to fix this issue, temporarily or otherwise);

Upon building the initrd with the "-K" switch, such as:
Code:

mkinitrd -c -k 2.6.37 -r cryptroot -C /dev/sdb2 -w 10 -o usb.gz -K LABEL=usboot:/boot/keyfile.luks
... as an example...

given the "LABEL" [or UUID] variable with the "-K" switch, cryptsetup is unable to locate the "--key-file" and thus proceeds with the pass-phrase prompt to open the encrypted root partition. Once the pass-phrase is manually entered the rest of the boot process is flawless. (Incidentally, we remain unable to boot a system by-label or by-uuid references alone, even when its not encrypted.)
Also, we checked the /initrd-tree/init script line by line and were unable to isolate any obvious issues in the original. (Slack 13.37)

Tested (and encountered the same problem) on the following setups:
Boot Loaders: Lilo, Syslinux, Extlinux (the last being the production system)
Kernels: 2.6.3[7,8].[6,4]-[huge,generic,custom]
Hardware: 12 different BIOS mfrs. [all Intel].
ALL necessary modules are compiled into the kernel (file system -> xfs + all necessary usb drivers etc., in the kernel.)

extlinux.conf [example]

Code:

default huge
prompt 0
timeout 30
display message.txt
label huge
  kernel ../vmlinuz
  append initrd=../initrd.gz vga=791

mkninitrd [example]
Code:

mkinitrd -c -k 2.6.38.4.-generic -r cryptroot -C /dev/sdb2 -w 10 -K LABEL=usboot:/boot/extlinux/lukskey.file -o test-initrd.gz
tried a large number of permutation of the obvious variables, such as the "-w" 5-30 secs.; LABEL=\"part. label\":"/" (e.g. with our w/o the quotes, followed by absolute AND/OR relative path references - and about an other million things, too long to reference all of it here.
However no GRUB, please, as we cant/dont use it - should that be a proposed solution.

Incidentally, the /dev/disk/by-label list devices appear to also have a strange habit of disappearing - seemingly randomly -, especially after particularly simple kernel customizations (like removing audio drivers) and recompiles. (could not isolate it, yet, despite ~20 different kernels built on ~12 different platforms, all seem to be working fine otherwise.)
the "blkid" driver is always present (as is the unbroken util-linux), yet, "by-label" seem to come-and-go. HOWEVER, despite it not being visible, never have any problem referencing the devices by label or uuid in /etc/fstab!!! It all just works. However, one is Not able to reference anything "by-label" in any scripts - obviously?! - when "by-label" decides to just plain disappear. (Someone, please, explain this to us if that person has a free moment. All "expert advice" so far came back the same: "something is broken with kernel/install. Just reinstall.")

Thank you all and help is much appreciated!

Alien Bob 10-22-2011 06:27 AM

First of all: the use of a LUKS keyfile on a USB stick for booting a fully encrypted Slackware system only works if the USB key has a (V)FAT filesystem. If the USB stick has your LUKS keyfile on an ext partition then it will not work.

A likely scenario with that custom kernel of yours is that you did not enable all the bits and pieces that are required to support a USB drive with a VFAT filesystem. The following modules are added to your initrd image when you run mkinitd with the "-K" option:

Code:

ehci-hcd:uhci-hcd:usb-storage:hid:usbhid:fat:nls_cp437:nls_iso8859-1:msdos:vfat
Make sure you have those enabled in your kernel (as modules or built-in)

Eric

pizzar0 10-22-2011 07:14 AM

thanks Alien Bob - we hoped that you (the author) would address this issue
 
Thanks again!
That is the key sentence!! - curiously missing from the mkinitrd README(s).
After a lot of trying to implement it with a non-(v)fat USB, we figured that much, that:
Quote:

the use of a LUKS keyfile on a USB stick for booting a fully encrypted Slackware system only works if the USB key has a (V)FAT filesystem
Allow us take the liberty and suggest that if this - above - singular sentence were included (added) in the README.initrd or other appropriate file it would prevent the >100 identical inquiries we have collected so far off the Net. (Most of them by Gentoo and Arch people! - Imagine that. They seem to want to know it, too?! :-)
- Because currently the "-K" instructions read "For example [if your key file is on ...vfat...]" as opposed to the above, categorical warning. ("For example" vs "IFF the partition is (v)FAT", makes all the difference.)

Any suggestion how this could be made to work with the ext(2,4) filesystems? (Or what pitfalls may there exist if we did it ourselves.)

Thanks for all your excellent work!! - It is very much appreciated.


All times are GMT -5. The time now is 03:50 AM.