Description of problem: Since Fedora 9, during installation we can select to encrypt our installation partition. When this is done, the installer creates an unencrypted /boot partition and a Logical Group which in turns contains a swap partition and the encrypted / root partition. When booting, we are asked for the passphrase in order to unlock the encrypted root partition and continue booting. Unfortunately, on servers with no keyboard or monitor, it is impractical or impossible to boot by typing a password directly into the computer. One solution is to use a USB stick as a "key", which is fully supported by LUKS by creating a key file and then using that instead of asking for the user to type anything. Thus, on servers without keyboards or monitors, we can just stick a USB stick at one of the USB ports, turn on the server, wait for it to boot and remove the stick. This solution can be done manually, which is described here: http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedVarWithUSBKey It would be better if this was integrated in some way into Fedora. Thank you. Version-Release number of selected component (if applicable): Fedora 9 and rawhide. How reproducible: Always. Steps to Reproduce: 1. Install on encrypted partition 2. Boot 3. Boot fails if you don't have a keyboard/monitor Actual results: Can't boot without a passphrase being typed. Expected results: Boot without keyboard. Additional info:
It supports key files (see /etc/crypttab). This may need wiring into the initrd and/or the installer.
Unfortunately, /etc/crypttab is within the encrypted partition. When i install F9 with the option to create a default layout of partitions, it creates a /boot partition and an LVM group (which in turn contains the swap and the root). Thus, only the /boot and the swap partitions are unencrypted and before the decryption is done the /etc is not visible, which means the /etc/crypttab is useless. As you suggested above, the solution is probably in initrd, which should load usb-storage and then look for a key in the mounted USB stick(s). The name of the key should probably be pre-defined (static or by asking the user to enter the name of the key during installation. Any help would be much appreciated.
This bug has been triaged
It shouldn't be hard to implement this feature properly. Here is one idea: - Allow the user to install on an encrypted partition (no changes during installation). - After installation, a simple script (or even a graphical interface) would allow the user to generate a key, add the key to the partition chain via LUKS and finally copy the key to a USB stick. The initrd should then be able to load usb_storage on boot and check if there are keys within the plugged devices.
This is a mass edit of all mkinitrd bugs. Thanks for taking the time to file this bug report (and/or commenting on it). As you may have heard in Fedora 12 mkinitrd has been replaced by dracut. In Fedora 12 the mkinitrd package is still around as some programs depend on certain libraries it provides, but mkinitrd itself is no longer used. In Fedora 13 mkinitrd will be removed completely. This means that all work on initrd has stopped. Rather then keeping mkinitrd bugs open and giving false hope they might get fixed we are mass closing them, so as to clearly communicate that no more work will be done on mkinitrd. We apologize for any inconvenience this may cause. If you are using Fedora 11 and are experiencing a mkinitrd bug you cannot work around, please upgrade to Fedora 12. If you experience problems with the initrd in Fedora 12, please file a bug against dracut.
I'd still like to see this feature wouldn't other folks? Should this be changed to dracut and reopened?
that would be nice. I had it working as I already mentioned above, so it is doable.
Reopening as this RFE is still warranted.
I would /very/ much like to see this functionality added. It would be great if, upon boot, the system could look for a LUKS keyfile on any attached USB device and if it fails to find such keyfile, to then prompt for the LUKS password. I have seen where this can be done on other distributions by adding vfat, usb, and other modules to the initrd and then using a script to poll for usb devices and the keyfile.
I'm also missing this feature. I would like you to be inspired by Archlinux way: http://wiki.archlinux.org/index.php/System_Encryption_with_LUKS_for_dm-crypt#Storing_the_key_externally_.28USB_stick.29 I especially like the way of storing the key between the MBR and the first partition. If it is stored there it cannot happen by accident that key is copied as a file somewhere by mistake.
There is similar request with patches https://bugzilla.redhat.com/show_bug.cgi?id=580807
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Has this RFE been implemented at all in later Fedora versions. I'm interested in this too.
Nope, it was never implemented. I managed to get it working on a very old version, but then things changed considerably so I didn't continue development.
I am missing this feature too... as an alternative or a more advanced feature to add it will be usefull to be able to supply a key stored on a nfs remote storage. The last comment before this was dated 2012-08-26, now I hope that this feature/features will be added to Fedora.
Does the manual way which worked on RHEL7 still work on newer Fedora (and any upcoming RHEL)? Mine was derived from (as I remember): https://bugzilla.redhat.com/show_bug.cgi?id=905683 Involved not using dracut systemd modules and on an existing encrypted system. 1/ Generated keyfile dd if=/dev/urandom of=/root/disk.key bs=4096 count=1 Copied disk.key to an ext4 formatted USB stick with a set UUID that we'll need later for the kernel command line. 2/ Edited /etc/crypttab to add /root/disk.key for /home and swap UUID's as the decrypt key. e.g. cryptsetup luksAddKey /dev/mapper/machine-home /root/disk.key cryptsetup luksAddKey /dev/mapper/machine-swap /root/disk.key cryptsetup luksAddKey /dev/mapper/machine-root /root/disk.key 3/ Added the ability to unlock with USB stick. Using dracut in non-systemd mode: Added /etc/dracut.conf.d/luks-workaround.conf containing: omit_dracutmodules+=" systemd " add_drivers+=" ext4" add_dracutmodules+=' lvm crypt ' dracut -f Edited /etc/grub2.cfg and added to the kernel line: rd.luks.crypttab=0 rd.luks.key.tout=10 rd.luks.key=/disk.key:UUID=UUIDvalue UUIDvalue is the value UUID we made the ext4 on the the USB key with.
careful: add_drivers+=" ext4 " surround with spaces... Your solution might still work. Preferred solution would with clevis one day: https://github.com/latchset/clevis You might want to file a PR to unlock clevis with a USB key
This change in systemd 240 should finally allow this to happen. https://github.com/systemd/systemd/commit/70f5f48eb891b12e969577b464de61e15a2593da It will be as simple as adding 'rd.luks.key' to your kernel arguments.