Bug 459485

Summary: Support for USB key
Product: [Fedora] Fedora Reporter: Dimitris <centos>
Component: dracutAssignee: dracut-maint
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: chess, Colin.Simpson, fedora-bugs, fedoraproject, harald, jaivuk, jan, jan.kratochvil, jonathan, mgarski, mike, myroslav, odiegit, twaugh, vezza, wtogami
Target Milestone: ---Keywords: FutureFeature, Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-01-12 15:31:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dimitris 2008-08-19 10:51:59 UTC
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:

Comment 1 Bill Nottingham 2008-08-21 00:44:18 UTC
It supports key files (see /etc/crypttab). This may need wiring into the initrd and/or the installer.

Comment 2 Dimitris 2008-08-21 07:07:05 UTC
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.

Comment 3 TK009 2008-11-20 00:32:04 UTC
This bug has been triaged

Comment 4 Dimitris 2008-11-20 06:38:37 UTC
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.

Comment 5 Hans de Goede 2010-01-12 15:31:09 UTC
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.

Comment 6 Michael Cronenworth 2010-02-07 06:24:55 UTC
I'd still like to see this feature wouldn't other folks? Should this be changed to dracut and reopened?

Comment 7 Dimitris 2010-02-07 11:36:36 UTC
that would be nice.

I had it working as I already mentioned above, so it is doable.

Comment 8 Michael Cronenworth 2010-02-08 04:34:32 UTC
Reopening as this RFE is still warranted.

Comment 9 Chess Griffin 2010-02-13 03:56:27 UTC
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.

Comment 10 Jaiv 2010-02-22 00:46:57 UTC
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.

Comment 11 Myroslav Opyr 2011-07-09 13:35:00 UTC
There is similar request with patches https://bugzilla.redhat.com/show_bug.cgi?id=580807

Comment 12 Fedora Admin XMLRPC Client 2011-10-20 16:19:18 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 13 Colin.Simpson 2012-08-26 20:01:46 UTC
Has this RFE been implemented at all in later Fedora versions. I'm interested in this too.

Comment 14 Dimitris 2012-08-26 20:56:26 UTC
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.

Comment 15 Andrea V. 2014-02-28 00:09:20 UTC
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.

Comment 16 Colin.Simpson 2018-07-26 11:02:03 UTC
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.

Comment 17 Harald Hoyer 2018-07-26 11:41:22 UTC
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

Comment 18 Michael Cronenworth 2018-09-05 23:05:53 UTC
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.