This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 459485 - Support for USB key
Support for USB key
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: dracut (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: dracut-maint
Fedora Extras Quality Assurance
: FutureFeature, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-19 06:51 EDT by Dimitris
Modified: 2015-01-13 04:09 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-12 10:31:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dimitris 2008-08-19 06:51:59 EDT
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-20 20:44:18 EDT
It supports key files (see /etc/crypttab). This may need wiring into the initrd and/or the installer.
Comment 2 Dimitris 2008-08-21 03:07:05 EDT
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-19 19:32:04 EST
This bug has been triaged
Comment 4 Dimitris 2008-11-20 01:38:37 EST
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 10:31:09 EST
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 01:24:55 EST
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 06:36:36 EST
that would be nice.

I had it working as I already mentioned above, so it is doable.
Comment 8 Michael Cronenworth 2010-02-07 23:34:32 EST
Reopening as this RFE is still warranted.
Comment 9 Chess Griffin 2010-02-12 22:56:27 EST
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-21 19:46:57 EST
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 09:35:00 EDT
There is similar request with patches https://bugzilla.redhat.com/show_bug.cgi?id=580807
Comment 12 Fedora Admin XMLRPC Client 2011-10-20 12:19:18 EDT
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 16:01:46 EDT
Has this RFE been implemented at all in later Fedora versions. I'm interested in this too.
Comment 14 Dimitris 2012-08-26 16:56:26 EDT
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-27 19:09:20 EST
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.

Note You need to log in before you can comment on or make changes to this bug.