Fedora Account System
Red Hat Associate
Red Hat Customer
While encrypting separate partitions (/home/*, /tmp etc.) is probably the best currently available solution for encrypting data on remote systems that may be rebooted, the full encrypted PV in F9 is simpler and works well when you have local access. There are also tricky choices with things like /var which are required on boot but can't be randomly encrypted as /tmp can. There's a Debian script available to enable networking and run dropbear ssh so that the passphrase for an encyrpted LV could be entered remotely on boot: http://www.debian-administration.org/articles/579 (and corrections in comments) and an Ubuntu adaptation: http://ubuntuforums.org/showthread.php?t=829768 The implementation would need to be adapted for Fedora, but the concept seems sound and very useful.
Well, I've managed to back-port what this scripts do, so far I can get a dropbear in my initrd up and running, things could've been much more messy however I chose to increase the initrd size by 2mb using busybox over copying every binary I need inside the initrd, it was easy as long as you know your network device modules and their dependencies, also I think things that should be put in mind is that when implementing such capability in fedora is.. 1. the case of a kernel update 2. the case of a hardware change (mostly the network card) other problems may apply but those are the ones in my mind now. May be if you want I could write you a how to or cook some script to do the job of hacking the initrd, and may be someone do a yum-crypsetup plug-in. /* || Thanks, Ahmed Medhat || ultimatetux [at] gmail [dot] com || In a world without walls and fences, who needs Windows and Gates? */
I tried to create my own initrd environment for unlocking encrypted disk (from default initrd img created by FC10). I added some binaries busybox, dropbear, and my network modules (currently testing in vmware so added e1000). I could get eth0 up, dropbear listen and connect. Almost fine but dropbear gives an "access denied" to the client and complains about a nonexistent user on server. I have passwd and shadow in initrd /etc folder. Any help on how you managed to create the script would be much appreciated. Thank you.
This isn't something we're going to add to current mkinitrd as its pretty complex to do securely.
In the comments at this page http://www.howtoforge.com/unlock-a-luks-encrypted-root-partition-via-ssh-on-ubuntu is patch for CentOS which will do exactly what is asked for here. Also see this http://www.phys.uconn.edu/Members/rozman/unlocking-luks-encrypted-partition-via-ssh-on-fedora In my opinion the explanation from Jeremy why this request was closed is not entirely fair, just because something is difficult to do but it is very useful and doable. In relation to this request I also suggest looking at request https://bugzilla.redhat.com/show_bug.cgi?id=580807 which requests ability to unlock LUKS root volume using USB key. The patch for mkinitrd to accomplish this again in CentOS is available here http://www.gno.org/~gdr/sysadmin/centos/5.4/usb-crypto-key.html These two requests combined would provide very useful way of protecting ones system.
Created attachment 474522 [details] Patch to enable dropbear in mkinitrd to allow unlocking LUKS encrypted root partition over SSH Copied from http://www.howtoforge.com/unlock-a-luks-encrypted-root-partition-via-ssh-on-ubuntu#comment-23372
Created attachment 474523 [details] Improvement to the previously submitted patch to enable dropbear in mkinitrd to allow unlocking LUKS encrypted root partition over SSH Copied from http://www.howtoforge.com/unlock-a-luks-encrypted-root-partition-via-ssh-on-ubuntu#comment-24307