Bug 905683 - rd.luks.key is ignored
Summary: rd.luks.key is ignored
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jan Synacek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-29 23:08 UTC by Daniel Laczi
Modified: 2018-12-14 17:13 UTC (History)
35 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-17 07:24:25 UTC


Attachments (Terms of Use)
journalctl_systemd-201-2.fx18.6_20130509 (18.23 KB, text/plain)
2013-05-09 21:16 UTC, Daniel Laczi
no flags Details
proposd patch for the issue (27.44 KB, application/x-gzip)
2014-04-20 21:42 UTC, prudy
no flags Details
patch adding WantsMountsFor with typo fixed (18.09 KB, patch)
2014-07-18 15:18 UTC, Zbigniew Jędrzejewski-Szmek
no flags Details | Diff

Description Daniel Laczi 2013-01-29 23:08:11 UTC
Description of problem:
In Fedora 18 kernel switch rd.luks.key is ignored. Therefore it is not possible to encrypt a system with a keyfile.

Version-Release number of selected component (if applicable):
All kernel images build with Fedora 18 cannot encrypt the system using a keyfile. My current version of dracut is 024-23.git20130118.fc18.x86_64. Old Fedora 17 kernels still work.
  
Actual results:
Keyfiles are ignored in kernel images built with F18. I found the following line in journalctl:
systemd-cryptsetup-generator[239]: Unknown kernel switch rd.luks.key=XYZ. Ignoring.

Expected results:
As in Fedora 17 it should be possible to encrypt a system with a keyfile.

Additional info:
Referring to the manual systemd-cryptsetup-generator does not support keyfiles (http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html). As far as I can tell dracut directly uses some cryptsetup command to encrypt the filesystem in the Fedora 17 kernelimages. Why was this changed within Fedora 18? It has worked fine ;)

Comment 1 Harald Hoyer 2013-01-30 11:56:46 UTC
This workaround might work, until this is fixed:

# echo 'omit_dracutmodules+=" systemd "' > /etc/dracut.conf.d/luks-workaround.conf
# dracut -f

Comment 2 Daniel Laczi 2013-01-30 19:37:59 UTC
Thank your for your replay. This works. However the graphical output is send to nowhere. Any passwords must be entered blindly as there is no input prompt or any other graphical output while booting.

Comment 3 Daniel Laczi 2013-02-26 16:47:40 UTC
This issue still exists in dracut-024-25.git20130205.fc18.x86_64 which I have just installed.

Comment 4 Harald Hoyer 2013-02-28 11:39:27 UTC
working on it

Comment 5 Jeff Makey 2013-04-10 16:24:34 UTC
The modification in comment 1 works very nicely when "rhgb quiet" is removed from the kernel command line.  dracut prompts for the passphrase if the key file is not found.

Comment 6 Harald Hoyer 2013-04-11 11:13:51 UTC
Patch sent to systemd mailing list:
http://lists.freedesktop.org/archives/systemd-devel/2013-April/010333.html

Comment 7 trivial+rhbugzilla 2013-05-01 17:56:11 UTC
That patch has been committed, will we see this in Fedora 18?
It would be great!

Comment 8 Fedora Update System 2013-05-07 13:44:48 UTC
systemd-201-2.fc18.6 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6

Comment 9 Fedora Update System 2013-05-09 10:05:41 UTC
Package systemd-201-2.fc18.6:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
then log in and leave karma (feedback).

Comment 10 Daniel Laczi 2013-05-09 21:16:25 UTC
Created attachment 745820 [details]
journalctl_systemd-201-2.fx18.6_20130509

Comment 11 Daniel Laczi 2013-05-09 21:16:42 UTC
Hi,

I've just tested systemd-201-2.fc18.6 but it still doesn't work. The journalctl is attached. It shows that some characters aren't translated right.

Comment 12 Michal Schmidt 2013-05-10 09:14:10 UTC
Looks like Harald's patch did not add support for the "rd.luks.key=<keypath>:<keydev>" syntax.

Comment 13 prudy 2013-07-03 20:25:29 UTC
This bug is valid for f19 too. Please update to f19 so it won't be closed together with f18 life cycle.

Comment 14 prudy 2013-07-03 22:09:25 UTC
Extra workaround, for f19:

# echo 'add_drivers+=" vfat"' >> /etc/dracut.conf.d/luks-workaround.conf
# dracut -f

Comment 15 Mateusz Marzantowicz 2013-07-15 22:12:21 UTC
(In reply to prudy from comment #14)
> Extra workaround, for f19:
> 
> # echo 'add_drivers+=" vfat"' >> /etc/dracut.conf.d/luks-workaround.conf
> # dracut -f

Does it mean, I need following two lines in deacut's config files to be albe to use LUKS key from file?

omit_dracutmodules+=" systemd "
add_drivers+=" vfat"

Comment 16 prudy 2013-07-16 07:24:03 UTC
Yes, two lines, the vfat is not added by default so thy cannot be read (well, unless you use different filesystem on the key storage).

Comment 17 tonyabg 2013-07-23 20:15:59 UTC
FYI:
For my F19 build in /etc/dracut.conf in addition ot omitting 'systemd',
I needed to put:

add_dracutmodules+=' lvm crypt '

LVM - because my volumes are under LVM control, but I also had to add 'crypt'
or cryptsetup was not in the initramfs.

Comment 18 Leho Kraav 2013-11-24 01:25:53 UTC
(In reply to Michal Schmidt from comment #12)
> Looks like Harald's patch did not add support for the
> "rd.luks.key=<keypath>:<keydev>" syntax.

So this is still unresolved? I was using keypath:keydev syntax on OpenRC and am now unable to to use the keydev part. USB stick is not automatically getting mounted either. This is on dracut-034.

Comment 19 Fedora End Of Life 2013-12-21 15:20:17 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 20 prudy 2013-12-27 12:49:10 UTC
Actually this seems to be solved. The thing is that it must be used differently with systemd. See some guide here:
http://forums.fedoraforum.org/showpost.php?p=1681988&postcount=43

Comment 21 Daniel Laczi 2013-12-31 15:44:48 UTC
Hi prudy,

thanks for the guide, but I don't see how I can get it to work.

My system looks like the following:
- unencrypted partition /boot
- encrypted lvm with systempatition
- unencrypted vfat partition on a usb key with a keyfile

Imho the fstab method won't work here as systemd is reading /etc/fstab and fstab is encrypted on my system. Have you any other idea, how I can tell systemd where the keyfile is? The old method - I'm currently using rd.luks.key=/keyfile.gpg:UUID=12345678-1234-1234-1234-123456789012 - doesn't work with systemd.

Comment 22 prudy 2013-12-31 17:21:34 UTC
(In reply to Daniel L. from comment #21)
> Hi prudy,
> 
> thanks for the guide, but I don't see how I can get it to work.
> 
> My system looks like the following:
> - unencrypted partition /boot
> - encrypted lvm with systempatition
For this 'lvm' must be added to dracut modules as mentioned before.

> - unencrypted vfat partition on a usb key with a keyfile
> 
> Imho the fstab method won't work here as systemd is reading /etc/fstab and
> fstab is encrypted on my system. Have you any other idea, how I can tell
The fstab is taken from initramfs, this is not encrypted. Could it be?

> systemd where the keyfile is? The old method - I'm currently using
> rd.luks.key=/keyfile.gpg:UUID=12345678-1234-1234-1234-123456789012 - doesn't
> work with systemd.
Yes, this is not compatible as I mentioned, simply use luks.key= (only the key path here on your mounted UUID device), or via crypttab. Key device must be mounted using fstab or systemd *.mount file (I have not used this one).

Comment 23 prudy 2013-12-31 17:26:37 UTC
I just noticed you use gpg-ed keyfile, I have not tried this as it would require a password I presume.

Comment 24 Daniel Laczi 2014-01-03 23:14:24 UTC
Sorry, but I still don't get it to work. The problem is that it doesn't mount the USB key (I was using fstab method). In my opinion this is not solved with your tips and still a bug, because the system stops booting and goes to the emergency mode if it doesn't find a keyfile. I would expect it to prompt for a password instead of stopping the boot process. AFAIK the guys above still use omit_dracutmodules+=" systemd " which works for me too...

Comment 25 prudy 2014-01-05 18:46:14 UTC
Can you unpack the initramfs you use to see if the valid fstab is there (with the proper entry for the key device)? I presume you can mount it manually to using  fstab (well, creating the mount path, the systemd will do it automatically if it does not exist). You could increase the mount timeout there, example 5s was enough for me but your device might need bit more. What are the actual entries in cmdline/fstab/crypttab?
The 'omit_dracutmodules=' works but my point was to try with systemd.

Comment 26 prudy 2014-01-07 17:09:35 UTC
Daniel, I have just checked the behaviour and you are right - asking for the password when key device is not found is not working. The guide I wrote is fine to ensure longer timeout for the key device mount. But if the key device is not inserted there will be no password request after this timeout.

Looking at the code of systemd I see the patch above adds the key option support (so you can give the key in command line). The implementation tries attaching the luks using given key file, if it fails it would fall back to the password dialogue.
However, when key device is not present, all this logic is not even started. The reason of this is not satisfied dependency of systemd internally generated option 'RequiresMountsFor'.

Comment 27 prudy 2014-04-19 21:07:45 UTC
Before there is a systemd code fix, I described the workaround in here:
http://forums.fedoraforum.org/showpost.php?p=1696031&postcount=44

Comment 28 prudy 2014-04-20 21:42:07 UTC
Created attachment 887979 [details]
proposd patch for the issue

Attaching the poposed patch for this problem.

Comment 29 prudy 2014-04-20 22:20:05 UTC
(In reply to prudy from comment #28)
> Created attachment 887979 [details]
> proposd patch for the issue
> 
> Attaching the poposed patch for this problem.

One note - the key device must be specified in fstab with "auto,nofail"

Comment 30 secondary 2014-06-28 05:28:52 UTC
A much more direct workaround, if the keyfile is stored locally. In other words, only if you want to "remove" encryption:

While the keyfile is specified in /etc/crypttab, it isn't copied into the initramfs by dracut. The option '--include' to dracut is only a temporary workaround; any additional initramfs rebuilds or kernel upgrades will remove the additional files instead. Instead to preserve changes across both kernel and (probably any) dracut upgrades, use:

/etc/dracut.conf.d/crypttab
    push include_src "/path/to/local/keyfile/as/per/etc/crypttab"
    push include_target "/path/to/local/keyfile/as/per/etc/crypttab"
    PARMS_TO_STORE+=" --include '/path/to/local/keyfile/as/per/etc/crypttab' '/path/to/local/keyfile/as/per/etc/crypttab'"

Note: for some strange reason dracut strips the SWAP luks partition from crypttab when generating the initramfs. Since a keyfile isn't specified, you might still receive a password prompt. Remove the luks swap partition from the kernel command line (/etc/boot/grub) and regenerate grub.cfg (grub2-mkconfig) to solve this.

===========

Anyway, the only real fix (as per comment 12) is to implement "rd.luks.key=<keypath>:<keydev>" syntax in cryptsetup-generate.c (systemd).

Comment 31 prudy 2014-06-28 18:50:47 UTC
The real fix has been submitted to systemd already.

Comment 32 Harald Hoyer 2014-07-08 14:24:06 UTC
(In reply to prudy from comment #31)
> The real fix has been submitted to systemd already.

so, should this be reassigned to systemd?

Comment 33 prudy 2014-07-08 20:14:12 UTC
Yes Harald, systemd.

Comment 34 Harald Hoyer 2014-07-18 08:09:35 UTC
(In reply to prudy from comment #28)
> Created attachment 887979 [details]
> proposd patch for the issue
> 
> Attaching the poposed patch for this problem.

Typo... 
+        { "WantssMountsFor",....

double "s"

Best to post this patch to the systemd-devel mailing list.

http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Comment 35 Zbigniew Jędrzejewski-Szmek 2014-07-18 15:18:55 UTC
Created attachment 919119 [details]
patch adding WantsMountsFor with typo fixed

Please do not compress small attachements.

Comment 36 prudy 2014-07-21 10:06:49 UTC
Yes, this patch has a typo, please refer to comment #31 instead.

Comment 37 Daniel Laczi 2014-11-04 14:16:32 UTC
prudy, it's still not working with a gpged keyfile, is it? Can I provide any additional information? I think somebody should close this ticket as fixed. I'll open a new report for the gpged keyfile then.

Comment 38 prudy 2014-11-04 14:36:15 UTC
I have not touched the gpg-ed keyfile problem.
I focused on solving the systemd not able to issue the passphrase request when device with a key file is not present. Proposed patch was sent to systemd mailing list, however it was not merged due to implementation change requests that I had no time for. But functionally it is fully working and tested. 
The patch in this ticket is also working but is a proof of concept only, the systemd mailing list patch is more accurate. 
Still a dracut workaround for this can be used as in Comment 27 above.

Comment 39 Jan Synacek 2014-12-15 13:22:30 UTC
I don't think that specifying rd.luks.key= works as it should:

        linux16 /vmlinuz-3.17.4-301.fc21.x86_64 root=/dev/mapper/luks-f6e9b3ee-3cdd-484b-8bce-7e06b080a986 ro rd.luks.uuid=luks-f6e9b3ee-3cdd-484b-8bce-7e06b080a986 rhgb quiet LANG=en_US.UTF-8 rd.luks.crypttab=0 rd.luks.key=/key:UUID=04779efa-4c0e-42c3-b325-56c0d925b3e9

I'm always prompted for a password even though I specified the keyfile. Adding "rd.break" still prompts for a password, and then breaks. This looks like a dracut problem to me.

# rpm -q dracut systemd
dracut-038-30.git20140903.fc21.x86_64
systemd-216-12.fc21.x86_64

Comment 40 prudy 2014-12-15 14:00:20 UTC
Hi Jan,
Please see my note in https://bugzilla.redhat.com/show_bug.cgi?id=905683#c20
abut incompatibility for rd.luks.key between dracut and systemd.
In short - if you use it for systemd it must contain only the full-path.

I have not tested yet with fedora 21, maybe there is something new.

Comment 41 prudy 2015-01-21 21:29:33 UTC
It is still not fixed in Fedora 21.
Workaraoud is posted here:
http://forums.fedoraforum.org/showpost.php?p=1721369&postcount=45

Comment 42 Jan Synacek 2015-02-11 13:11:20 UTC
Zbyszek, are you working on this one? If not, I'd like to give it a shot.

Comment 43 Zbigniew Jędrzejewski-Szmek 2015-02-13 02:00:08 UTC
Go ahead. I totally forgot about it.

Comment 44 David Santamaría Rogado 2015-02-13 19:13:57 UTC
Nice to read this. I'm using the workaround of omitting systemd in dracut config, but that makes me face another bugs with initramfs without systemd like keyboard layout not working at boot or console font not setting up (it only setup during boot if plymouth is in text mode).

Jan Synacek I could test packages in fedora testing if you need.

Comment 45 prudy 2015-02-13 20:59:01 UTC
(In reply to David Santamaría Rogado from comment #44)
> Nice to read this. I'm using the workaround of omitting systemd in dracut
> [...]
With my latest workaround you don't have to skip systemd, it is fully functional.
But yes, will be good to have this solved.

Comment 46 Jan Synacek 2015-02-26 09:15:29 UTC
For the brave: you can test this dracut version:

https://jsynacek.fedorapeople.org/dracut/12.git20140402.fc20.wip/

Dracut already provides code that handles cryptsetup related stuff. My patch removes systemd-crypt-setup related code from dracut, thus leaving all the processing to dracut itself.

From my limited testing, dracut now correctly falls back to password prompt even though when the keyfile device is not present.

Comment 47 David Santamaría Rogado 2015-03-03 19:43:24 UTC
I'm using fedora 21.

This doesn't contradict with the purpose of using systemd with dracut? Can't be systemd make aware of rd.luks.key with the same behaviour?

Comment 48 Jan Synacek 2015-03-04 07:38:38 UTC
(In reply to David Santamaría Rogado from comment #47)
> This doesn't contradict with the purpose of using systemd with dracut? Can't
> be systemd make aware of rd.luks.key with the same behaviour?

Dracut already has code to deal with encrypted root partition and the key files, there's probably no reason to do this directly in systemd. Once the root is mounted and switched to, systemd handles key files as well, just not on possibly unmounted partitions. If you already have your encrypted root mounted, you can put the keys there, so there's probably no reason to support such use case in systemd itself.

Comment 49 Tim Waugh 2015-04-02 10:47:40 UTC
How long would the 'don't use systemd' approach wait for you to plug in the USB device?

Comment 50 prudy 2015-04-02 11:07:29 UTC
In dracut 10s, or number of seconds defined by rd.luks.key.tout=

Comment 51 Fedora End Of Life 2015-05-29 08:52:47 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 52 Daniel Laczi 2015-06-04 00:19:02 UTC
Hi Harald,

I'm still omitting systemd as I'm using a gpged keyfile. Since F22 this doesn't work anymore though. Have you changed anything in 041-10.fc22.1 affecting this? Even fallback mode doesn't work. It says "crypt: unknown target type".

It would be nice if you could drop any information ;) Thanks in advance.

Comment 53 Eric Renfro 2015-06-05 19:08:01 UTC
I can confirm this completely fails all workarounds for Fedora 22 as well, and has basically become completely unusable, and this is very sad, especially after 2 years.

Comment 54 Daniel Laczi 2015-06-05 20:03:59 UTC
Jan Synacek told us in comment #48 that this probably won't be added to systemd as dracut can already handle this.

So, can anybody tell us if this will still be maintained in dracut?

If not, I will open a bug against systemd.

If it will still be maintained, getting some information and help with troubleshooting would be nice. I downgraded dracut, dracut-config-rescue and dracut-network, but it didn't help.

Comment 55 prudy 2015-06-06 10:20:50 UTC
For the whole '/' encryption dracut will probably do, however having separate partitions it still must be supported in systemd.
The bugfix has been noticed to systemd mailing list but reasonably there are only 30 people watching this thread, so not many, and so low priority probably...

Beside my systemd workaround (no recompilation, only scripts, works for F22), you can also find quite nice grub level solution. With patches it allows full (including /boot) encryption and key from external device. It needs rpm recompilation but once installed it does not have to be modified every kernel update.

Comment 56 Daniel Laczi 2015-06-06 16:16:27 UTC
Thanks for your replay, but let me explain the problem again:

My partition layout isn't really anything specific. I have an unencrypted /boot partition and an encrypted LVM that contains /swap and /. My keyfile is GPGED and on a USB drive.

My grub.cfg looks like
linux   /vmlinuz-4.0.4-201.fc21.x86_64 root=/dev/mapper/VolGroup00-LogVol01 ro rd.md=0 rd.dm=0  rd.luks.uuid=luks-XXX...XXX rd.lvm.lv=VolGroup00/LogVol01 rd.lvm.lv=VolGroup00/LogVol00 rd.luks.key=/key.gpg:UUID=YYY...YYY vconsole.keymap=de LANG=de_DE.UTF-8

I added the following lines to dracut.conf:
add_dracutmodules+="crypt-gpg"
omit_dracutmodules+="systemd"
The first line adds the gpg module to dracut, so it can encrypt the gpged keyfile. The second line omits systemd.

Old F21 kernels build with this configuration still boot F22 systems.

Until F22 this configuration has been working and was still maintained in dracut, as said in comment #48. So, will this still be maintained in dracut or will this move over to systemd?

I'm aware that the subject of this bug is keyfiles in general and not gpged ones. I will open a new bug report if anyone tells me were this will be maintained ;)

Also thanks for your workaround. I know the thread on the forum. I'm aware that systemd doesn't accept 'rd' parameters etc. but I didn't get it to work with a gpged keyfile though.

Comment 57 Jan Synacek 2015-06-08 06:04:02 UTC
Has anybody ever tried the patched version of dracut from comment 46?

Comment 58 Daniel Laczi 2015-06-13 20:13:18 UTC
(In reply to Jan Synacek from comment #57)
> Has anybody ever tried the patched version of dracut from comment 46?

Sorry, sadly not. I just tried downgrading dracut to that version, but it seems like the 4.X kernels need dracut 0.38 or newer. Can the patches be applied to current dracut version as well?

Comment 59 Jan Synacek 2015-06-15 08:07:00 UTC
Yes, the patch can be applied. You can find it at https://github.com/jsynacek/dracut/tree/crypto-keys. Let me know if I should create a testing F21/F22 packages.

Comment 60 Daniel Laczi 2015-06-15 15:05:10 UTC
(In reply to Jan Synacek from comment #59)
> Yes, the patch can be applied. You can find it at
> https://github.com/jsynacek/dracut/tree/crypto-keys. Let me know if I should
> create a testing F21/F22 packages.

It would be great if you created the testing packages, because I'm not very familiar with this process.

Comment 61 Jan Synacek 2015-06-16 11:26:28 UTC
Packages for Fedora 22 can be found at https://jsynacek.fedorapeople.org/dracut/11.fc22.1.luks/. Fedora 21 version is in the works.

Comment 63 Daniel Laczi 2015-06-16 16:56:34 UTC
Thank you! In F21 it works flawlessly. As you said, dracut is handling the encryption stuff and I don't need to omit systemd.

In F22 it doesn't work though. It is doing the same thing as it is with the current stable version. It finds my keyfile, however it is falling back to passphrase mode. When I type in the correct passphrase, it says:

device-mapper: table: 253:0: crypt: unknown target type
device-mapper: ioctl: error adding target to table
dracut-initqueue[313]: device-mapper: reload ioctl on luks-ABC...XYZ failed: Invalid argument

Comment 64 Daniel Laczi 2015-06-16 18:24:27 UTC
I tried downgrading device-mapper to F21 version, added several modules to dracut, but it didn't help. Any other ideas? Shall I open a bug against device-mapper?

Comment 65 Milan Broz 2015-06-16 20:37:34 UTC
(In reply to Daniel L. from comment #63)

> device-mapper: table: 253:0: crypt: unknown target type

This looks like the dm-crypt.ko kernel module is missing in initramdisk.
(It will need also some crypto modules but the error message above would be different in that case.)

Comment 66 Jan Synacek 2015-06-17 07:24:25 UTC
Well, the patch will probably not make it into any Fedora version anyway: https://github.com/haraldh/dracut/pull/72. I don't think it makes sense to file bugs when you are using a testing package.

Upstream isn't really fond of supporting such use case (http://lists.freedesktop.org/archives/systemd-devel/2015-April/031137.html), so there's nothing that I can really do right now.

Comment 67 Bill McGonigle 2015-06-18 16:11:38 UTC
@Daniel: were you looking for GPG support?  The upstream comment I'm reading says:

"I'd be willing to merge a patch that supports basic
rd.luks.key=<keypath>:<keydev>, even though I think it's usecase is
more security theater than really useful."

The systemd maintainer doesn't have to understand physical security if he's willing to merge the patch. ;)

Comment 68 Daniel Laczi 2015-06-18 16:32:25 UTC
(In reply to Bill McGonigle from comment #67)
> @Daniel: were you looking for GPG support?  The upstream comment I'm reading
> says:
> 
> "I'd be willing to merge a patch that supports basic
> rd.luks.key=<keypath>:<keydev>, even though I think it's usecase is
> more security theater than really useful."
> 
> The systemd maintainer doesn't have to understand physical security if he's
> willing to merge the patch. ;)

Hi Bill,

yes, GPG support is exactly what I'm looking for :)

Comment 69 Daniel Laczi 2015-07-02 11:01:05 UTC
@Bill: can you provide a link to the upstream discussion/the feature request?

Comment 70 Bill McGonigle 2015-07-02 21:18:40 UTC
@Daniel: I think I was just reading the second link in comment#66.

Comment 71 Daniel Laczi 2015-08-09 23:10:17 UTC
Hi,

just a short update to anyone who is still watching this:

I just applied the new kernel and systemd updates. My gpged keyfile is working again by adding crypt-gpg module to dracut and omitting systemd!

Package versions are: kernel.x86_64 4.1.3-201.fc22 and systemd.x86_64 219-20.fc22.

Comment 72 Kyle Marek 2016-12-15 04:29:16 UTC
I'd like to note that omitting systemd from dracut is still necessary to use rd.luks.key in in Fedora 25.

Is systemd tracking this issue in any way besides that mail thread?

Comment 73 Ken Coar 2016-12-15 17:01:04 UTC
This BZ is marked as 'closed upstream' yet still apparently is an issue as of F25.

Is there a newer BZ for this, or does the 'closed upstream' tag mean 'nothing more is going to be done about this'?

Thanks

Comment 74 Kyle Marek 2016-12-15 18:01:03 UTC
I imagined it meant it was upstream's responsibility to fix.

While it still appears to be systemd that needs to implement rd.luks.key for keyfiles, dracut has an open bug for this issue: https://github.com/dracutdevs/dracut/issues/147

Comment 75 prudy 2016-12-15 18:15:58 UTC
The patches to systemd are not applied. But still individual the systemd unit/mount files can be used to achieve key on external device.

Comment 76 Piergiorgio Sartor 2017-11-03 20:19:20 UTC
Hi all,

is there any working solution to unlock a system from file key (USB stick, for example)?

I tried everything mentioned here, but it did not work.

Any suggestions?

Thanks,

bye,

pg

Comment 77 Daniel Laczi 2017-11-04 00:00:32 UTC
(In reply to Piergiorgio Sartor from comment #76)
> Hi all,
> 
> is there any working solution to unlock a system from file key (USB stick,
> for example)?
> 
> I tried everything mentioned here, but it did not work.
> 
> Any suggestions?
> 
> Thanks,
> 
> bye,
> 
> pg

What exactly have you tried? Any error? Using a gpged keyfile definitely works. However you need a workaround and might need to play with the kernel parameters.

Check comment #1. Also add add_dracutmodules+="crypt-gpg" to the config as mentioned in comment #56.

Also see comment #56 for kernel parameters. Add the parameters to /etc/default/grub using GRUB_CMDLINE_LINUX="<parameters>" and rebuild grub running 'grub2-mkconfig -o /boot/grub2/grub.cfg'. rd.luks.key contains your gpged keyfile and the UUID of the device the file is located (for example USB stick). AFAIR you will also need rd.luks.uuid, which is the luks device you want to unlock.

Comment 78 Kyle Marek 2017-11-04 00:03:55 UTC
(In reply to Piergiorgio Sartor from comment #76)
> Hi all,
> 
> is there any working solution to unlock a system from file key (USB stick,
> for example)?
> 
> I tried everything mentioned here, but it did not work.
> 
> Any suggestions?
> 
> Thanks,
> 
> bye,
> 
> pg

To date, I am omitting systemd from my initrd in order to use the dracut scripts for this, instead.

$ cat /etc/dracut.conf.d/crypt-keydev-fix.conf
omit_dracutmodules+="systemd systemd-initrd dracut-systemd"

Rebuild all initrds with the new configuration using with `sudo dracut --regenerate-all --force`

Then make sure your cmdline contains:
rd.luks.key=/${key_file}:UUID=${key_device_uuid}:UUID=${luks_device_uuid}

Comment 79 Piergiorgio Sartor 2017-11-04 11:39:29 UTC
(In reply to Daniel Laczi from comment #77)
[...]
> What exactly have you tried? Any error? Using a gpged keyfile definitely

If I got it correctly, gpg-ed keyfile requires a
password, which I do not want.
I want to have an encrypted system, which can be unlock by password *or* by keyfile on USB stick (like a car / home key).

That's it, and that does not seem to work.

> works. However you need a workaround and might need to play with the kernel
> parameters.

Which leads to the second issue. There is no *clear* or *official* setup for that.
IMHO, once the rd.luks.key parameter is given, it should work, without playing with other things.

Anyway thanks,

bye,

pg

Comment 80 Piergiorgio Sartor 2017-11-04 11:42:46 UTC
(In reply to Kyle Marek from comment #78)
[...]
> To date, I am omitting systemd from my initrd in order to use the dracut
> scripts for this, instead.

I think I tried this, but it did not work.

Furthermore, what are the consequences of omitting systemd from initrd?
I guess if systemd is not relevant to initrd, then why add it in the first place?

This is an other issue I've with this.
It is mentioned to omit systemd, but it is never clarified what are the drawbacks.

> $ cat /etc/dracut.conf.d/crypt-keydev-fix.conf
> omit_dracutmodules+="systemd systemd-initrd dracut-systemd"
> 
> Rebuild all initrds with the new configuration using with `sudo dracut
> --regenerate-all --force`
> 
> Then make sure your cmdline contains:
> rd.luks.key=/${key_file}:UUID=${key_device_uuid}:UUID=${luks_device_uuid}

I'll try again, maybe something was wrong in this syntax.

Thanks,

bye,

pg

Comment 81 prudy 2017-11-04 16:59:21 UTC
(In reply to Piergiorgio Sartor from comment #76)
If you want to keep systemd during startup and create a number of files I updated the forum with some solution:
https://forums.fedoraforum.org/showpost.php?p=1797174&postcount=46

Comment 82 Kyle Marek 2017-11-04 22:28:38 UTC
(In reply to Piergiorgio Sartor from comment #80)
> (In reply to Kyle Marek from comment #78)
> [...]
> > To date, I am omitting systemd from my initrd in order to use the dracut
> > scripts for this, instead.
> 
> I think I tried this, but it did not work.

Well, from your other comments, it sounds like you're trying to decrypt with a GPG-encrypted file. As you pointed out, this requires a password to decrypt, defeating the purpose. GPG-encrypting the key is *optional*. Remember that there is no real distinction between the contents of a key file and what you type on decryption prompt. You can, in fact, decrypt with a file containing nothing more than the exact password you would type if you were to decrypt without a key file.

Personally, to make a key file "revoke"-able, I use LUKS's multiple key slots to generate a random key, and put that in the key-file instead of what I have to memorize to type. This way, if I lose my key device, I don't have to memorize a new password in addition to changing the key I lost.

Steps to do this include:
# Mount file system being used to decrypt
sudo mount ${key_device} /mnt

# Write random 256 bytes to a key file
head /dev/urandom -c 256 | sudo tee /mnt/luks-${luks_device_uuid}.key > /dev/null

# Add key file as acceptable key *in addition* to your existing passphrase
# (will prompt for existing key)
sudo cryptsetup luksAddKey /dev/disk/by-uuid/${luks_device_uuid} /mnt/luks-${luks_device_uuid}.key

> Furthermore, what are the consequences of omitting systemd from initrd?
> I guess if systemd is not relevant to initrd, then why add it in the first
> place?
>
> This is an other issue I've with this.
> It is mentioned to omit systemd, but it is never clarified what are the
> drawbacks.

It isn't simply that systemd is irrelevant; systemd provides a lot of benefits, but is being used *instead of* the scripts that used to be used, in order to re-implement the features provided by those scripts (hence the current UPSTREAM status of the bug). systemd and the dracut scripts accomplish the same things, just in different ways.

The reason why systemd was brought into the initrd, as far as I understand, is because it allows for a better event-driven architecture which gives developers more flexibility in addition to speeding up the boot process and eliminating a lot of the CPU-usage of script interpretation. In addition, systemd's integration with other projects like udev brings the abilities of these projects to initrd services automatically.

An example of a drawback to not using systemd in the initrd is using the "old" dracut script for key file searches. The old script is 10 iterations of searching for your block device, separated by 1 second pauses. If it takes longer than 10 seconds for your block device to show up (which is unlikely), I believe you will be prompted for the password as a fallback (which works in your favor, I guess). systemd would probably wait for a trigger from block device creation instead of constantly surveying the available block devices, and support an arbitrary timeout.
 
> > $ cat /etc/dracut.conf.d/crypt-keydev-fix.conf
> > omit_dracutmodules+="systemd systemd-initrd dracut-systemd"
> > 
> > Rebuild all initrds with the new configuration using with `sudo dracut
> > --regenerate-all --force`
> > 
> > Then make sure your cmdline contains:
> > rd.luks.key=/${key_file}:UUID=${key_device_uuid}:UUID=${luks_device_uuid}
> 
> I'll try again, maybe something was wrong in this syntax.

Remember to reconsider what's actually in the key file. While there is support for decrypting keys encrypted with GPG, what you probably want is a plain key stored in a file.

> Thanks,
> 
> bye,
> 
> pg

Comment 83 Piergiorgio Sartor 2017-11-04 22:39:51 UTC
(In reply to Kyle Marek from comment #82)
[...]
> Well, from your other comments, it sounds like you're trying to decrypt with
> a GPG-encrypted file. As you pointed out, this requires a password to
> decrypt, defeating the purpose. GPG-encrypting the key is *optional*.

No, I do not use gpg, I just put the plain keyfile into some storage.
For testing, this was even in the /boot partition, at a certain point.

[...]
> Personally, to make a key file "revoke"-able, I use LUKS's multiple key
> slots to generate a random key, and put that in the key-file instead of what
> I have to memorize to type. This way, if I lose my key device, I don't have
> to memorize a new password in addition to changing the key I lost.

The current requirement is to be able to boot, using full disk encryption (except /boot, of course), using an external USB device (key) *or* password from console.
The problem is that the console is far away, the disk has to be encrypted, merely for disposal purposes.

[...]
> It isn't simply that systemd is irrelevant; systemd provides a lot of
> benefits, but is being used *instead of* the scripts that used to be used,
> in order to re-implement the features provided by those scripts (hence the
> current UPSTREAM status of the bug). systemd and the dracut scripts
> accomplish the same things, just in different ways.

So, if I understand this correctly, there is no _standard_ solution, currently.
Either we sabotage the system by removing systemd from initrd or we cannot have the unlock key on some storage.

[...]
> Remember to reconsider what's actually in the key file. While there is
> support for decrypting keys encrypted with GPG, what you probably want is a
> plain key stored in a file.

That's exactly what I want, what I tested and it did not work...

bye,

pg

Comment 84 Piergiorgio Sartor 2017-11-04 22:41:17 UTC
(In reply to prudy from comment #81)
> (In reply to Piergiorgio Sartor from comment #76)
> If you want to keep systemd during startup and create a number of files I
> updated the forum with some solution:
> https://forums.fedoraforum.org/showpost.php?p=1797174&postcount=46

Thanks for the link.

I had a look, but it seems to me a too custom solution.

I would prefer more off-the-shelf ones.

Anyway thanks again,

bye,

pg

Comment 85 Kyle Marek 2017-11-05 02:15:30 UTC
(In reply to Piergiorgio Sartor from comment #83)
> (In reply to Kyle Marek from comment #82)
> [...]
> > Well, from your other comments, it sounds like you're trying to decrypt with
> > a GPG-encrypted file. As you pointed out, this requires a password to
> > decrypt, defeating the purpose. GPG-encrypting the key is *optional*.
> 
> No, I do not use gpg, I just put the plain keyfile into some storage.
> For testing, this was even in the /boot partition, at a certain point.

This is good.

> [...]
> > Personally, to make a key file "revoke"-able, I use LUKS's multiple key
> > slots to generate a random key, and put that in the key-file instead of what
> > I have to memorize to type. This way, if I lose my key device, I don't have
> > to memorize a new password in addition to changing the key I lost.
> 
> The current requirement is to be able to boot, using full disk encryption
> (except /boot, of course), using an external USB device (key) *or* password
> from console.
> The problem is that the console is far away, the disk has to be encrypted,
> merely for disposal purposes.

Similar situation here, except I have it working on five machines. However, they were all initially Fedora 25. The significance of this will be discussed later.

> [...]
> > It isn't simply that systemd is irrelevant; systemd provides a lot of
> > benefits, but is being used *instead of* the scripts that used to be used,
> > in order to re-implement the features provided by those scripts (hence the
> > current UPSTREAM status of the bug). systemd and the dracut scripts
> > accomplish the same things, just in different ways.
> 
> So, if I understand this correctly, there is no _standard_ solution,
> currently.
> Either we sabotage the system by removing systemd from initrd or we cannot
> have the unlock key on some storage.

Almost correct. There is no "standard" solution, as it is your initrd's responsibility/design choice.

You're not exactly sabotaging your initrd by removing systemd. They were initially designed to be agnostic of the init you use, by using *whatever means* necessary to mount your root partition, and exec PID 1 to /sbin/init (systemd in your case). Executing systemd from the initrd is just a convenience from an initrd developer point of view.

Remember that all of these things (the non-systemd scripts) needed to work before systemd existed. They should still work.

> [...]
> > Remember to reconsider what's actually in the key file. While there is
> > support for decrypting keys encrypted with GPG, what you probably want is a
> > plain key stored in a file.
> 
> That's exactly what I want, what I tested and it did not work...

In order to identify any missing steps, I started fresh in a VM in order to produce a list of every action taken in order to accomplish this, and then I tried my list of actions again on another clean VM.

While I was doing this, I discovered a potential issue. `dracut --force --regenerate-all` does not actually put the initrds in the right place in Fedora 26. I have filed a bug on this. See: https://bugzilla.redhat.com/show_bug.cgi?id=1509599

In addition, it was my own choice to format my flash drives with FAT32. By default, dracut generates "host-only" images, meaning they include only the modules necessary to boot *your* system on *your current* hardware. In my case, it seems to be forgetting the vfat module. While you can include specific missing modules, it might be easier and better for future hardware changes to generate a complete initrd.

Here is my complete process to go from a minimal Fedora 26 install to automatically decrypting with a key file, including a workaround for initrd regenration and initrd modules. I worked in shell variables and non-interactive commands for easy copy-paste:

1. Install Fedora 26 "Minimal install" from network installer disk <https://download.fedoraproject.org/pub/fedora/linux/releases/26/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-26-1.5.iso>, using automatic partitioning and enabling encryption (automatically installs onto LVM on LUKS, defaulting to prompting for decryption).

2. Install necessary packages:
   - dosfstools for mkfs.vfat

3. Plug in flash drive, monitor what block device it is (I watch output of dmesg -w). In my case it was /dev/vdb (a virtio device)
   $ key_device="/dev/vdb"

4. Determine your LUKS device UUID. In my case, my LUKS block device (not the decrypting one) is /dev/vda2:
   $ luks_device="/dev/vda2"
   $ luks_device_uuid="$(sudo blkid -o value -s UUID "$luks_device")"

5. Format and mount flash drive:
   $ sudo mkfs.vfat -F32 -I "$key_device"
   $ sudo mkdir /root/mnt # mounting here for root-only readability
   $ sudo mount "$key_device" /root/mnt

6. Determine your key device's UUID:
   $ key_device_uuid="$(sudo blkid -o value -s UUID "$key_device")"

7. Create key file:
   $ head /dev/urandom -c 256 | sudo tee /root/mnt/luks-${luks_device_uuid}.key > /dev/null

8. Configure LUKS to accept the key file as a key:
   $ sudo cryptsetup luksAddKey /dev/disk/by-uuid/${luks_device_uuid} /root/mnt/luks-${luks_device_uuid}.key

9.1. You can verify by trying to open your LUKS volume a second time:
     $ sudo cryptsetup open --type luks --readonly --key-file /root/mnt/luks-${luks_device_uuid}.key /dev/disk/by-uuid/${luks_device_uuid} tmp

     Note that the following message indicates success in using the key file: Cannot use device /dev/disk/by-uuid/3765552b-fddf-4b37-839c-942cc0059c12 which is in use (already mapped or mounted).

     Opening with an invalid keyfile (/dev/null, for example) results in no message, but a return value of 1 (`echo $?` to see return value).

10. Unmount flash drive
    $ sync
    $ sudo umount /root/mnt
    $ sudo rmdir /root/mnt

11. Configure dracut to omit systemd modules, due to systemd *not yet* implementing rd.luks.key:
    $ echo 'omit_dracutmodules+="systemd systemd-initrd dracut-systemd"' | sudo tee /etc/dracut.conf.d/crypt-keydev-fix.conf > /dev/null

12. Configure dracut to generate a complete generic initrd:
    $ echo 'hostonly="no"' | sudo tee /etc/dracut.conf.d/no-hostonly.conf > /dev/null

13. Regenerate all initrds using the new configuration:
    $ for kernel in /boot/vmlinuz-*; do kver="$(echo "$kernel" | sed -ne 's:^/boot/vmlinuz-\(.*\)$:\1:p')"; sudo dracut --force /boot/initramfs-"$kver".img "$kver"; done

14. Put the *output* of the following command onto your kernel cmdline:
    $ echo "rd.luks.key=/luks-${luks_device_uuid}.key:UUID=${key_device_uuid}:UUID=${luks_device_uuid}"

14.1. For GRUB2 cmdline configuration:
      In /etc/default/grub:
        GRUB_CMDLINE_LINUX="... paste here"
      Regenerate GRUB2 configuration
        $ for file in /etc/grub2.cfg /etc/grub2-efi.cfg; do test -L "$file" && sudo grub2-mkconfig -o "$file"; done

15. Reboot to test
   
> bye,
> 
> pg

Comment 86 shamim.islam 2018-06-24 06:32:11 UTC
We have a new problem. As for Fedora 28, removing systemd invokes warnings about systemd-initrd and other systemd modules in dracut. As much as I'd like to follow the simpler solution of not using systemd in initrd, I'm not sure how to proceed in Fedora 28 since the init process itself seems to be dependent on systemd. There seems to be no workaround other than Prudy's option. Can I reboot properly with the systemd-initrd errors reported? Or do I need to follow Prudy's answer?

Can I simply use the following?


omit_dracutmodules+=" systemd "
add_drivers+=" vfat lvm crypt "

Comment 87 Kyle Marek 2018-06-26 09:24:15 UTC
(In reply to shamim.islam from comment #86)
> We have a new problem. As for Fedora 28, removing systemd invokes warnings
> about systemd-initrd and other systemd modules in dracut. As much as I'd
> like to follow the simpler solution of not using systemd in initrd, I'm not
> sure how to proceed in Fedora 28 since the init process itself seems to be
> dependent on systemd. There seems to be no workaround other than Prudy's
> option. Can I reboot properly with the systemd-initrd errors reported? Or do
> I need to follow Prudy's answer?
> 
> Can I simply use the following?
> 
> 
> omit_dracutmodules+=" systemd "
> add_drivers+=" vfat lvm crypt "

Nothing's new, here. Change to:

omit_dracutmodules+="systemd systemd-initrd dracut-systemd"
add_drivers+="vfat"

Was tested with success on a F28 VM.

Comment 88 Kyle Marek 2018-06-26 09:32:57 UTC
(In reply to Kyle Marek from comment #87)
> (In reply to shamim.islam from comment #86)
> > We have a new problem. As for Fedora 28, removing systemd invokes warnings
> > about systemd-initrd and other systemd modules in dracut. As much as I'd
> > like to follow the simpler solution of not using systemd in initrd, I'm not
> > sure how to proceed in Fedora 28 since the init process itself seems to be
> > dependent on systemd. There seems to be no workaround other than Prudy's
> > option. Can I reboot properly with the systemd-initrd errors reported? Or do
> > I need to follow Prudy's answer?
> > 
> > Can I simply use the following?
> > 
> > 
> > omit_dracutmodules+=" systemd "
> > add_drivers+=" vfat lvm crypt "
> 
> Nothing's new, here. Change to:
> 
> omit_dracutmodules+="systemd systemd-initrd dracut-systemd"
> add_drivers+="vfat"
> 
> Was tested with success on a F28 VM.

Though, do use the spaces in the +=. I just noticed...


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