initramfs should try password against other devices

This might actually make sense. But this implies that we store the passphrase in-memory while trying all devices, which may have security implications.

Have you considered using a key-file on a removal storage and make all volumes unlock using that key-file?

This functionality already exists. Please see:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/cryptsetup/quantal/view/head:/debian/README.keyctl

If it doesn't work, please file a new bug or repoen this one with updated details.

I'm trying that, and especially need to verify it will work from initramfs as my root is encrypted. Ironically it stores the passphrase in the kernel forever, whereas something that temporarily stores the passphrase while the initramfs is running would have it available for considerably less time!

It turns out that the script is already in the right place and all the initramfs hooks are in place etc. It is merely necessary to add keyscript=decrypt_keyctl into the relevant places in crypttab.

Unfortunately doing so causes update-initramfs to fail with the cryptkeyctl hook giving error code 1.

Still investigating.

Ok, more progress. keyctl must be installed otherwise update-initramfs fails and you have to guess why.

And with everything plumbed in, I can't actually enter my passphrase and the machine is unusable. The reason is decrypt_keyctl is not using whatever means is correct for prompting for the passphrase. Before I would get the prompt on the main Ubuntu screen (logo and 5 animated dots).

That screen just animates forever. If I switch consoles I do end up on one that says "Caching passphrase for ....:" as what looks like a prompt, but I can't get it to accept anything.

In recovery mode the animated ubuntu screen is not present, instead just a text mode. I get a prompt this time, but again can't get it to accept anything. If I switch to the dmesg console, nothing is echoed until I hit return. At that point decrypt_keyctl just says "No key available for this passphrase" against the UUID of each encrypted device and then I am dumped out at the (initramfs) shell.

So yeah, using it as things stand is a solution in spirit but in practise leaves you with an unbootable machine.

I got everything working. The README you pointed to is very misleading since the script is already in the correct place. I'd be inclined to just delete the README, and mention all the different scripts in /lib/cryptsetup/scripts in the main crypttab page.

decrypt_keyctl doesn't seem like 'none' as the third column in crypttab (either that or the ordering confuses it). I changed the ordering so swap was last, and the third column from 'none' to avoid multiple prompts.

In cryptdisk.functions there is a section that tries to work out what program to use for prompting (look for plymouth). In decrypt_keyctl there is a similar section at the top trying to do the same thing, but it doesn't look for plymouth. I made two changes:

1) Added code to make plymouth be probed and used. At the top section as the last entry:

      test -x /bin/plymouth && plymouth --ping && PW_READER_='plymouth'

In the case $PW_READER_ section:

    plymouth)
            KEY_=$(plymouth ask-for-password --prompt "$PROMPT_") || die "Error executing plymouth"
            ;;

That makes things work perfectly when plymouth is present.

2) In recovery mode things were unusable. That was because it was using askpass. I commented out the line beginning test -x "$ASKPASS_" which means that in a non-plymouth environment the stty mode is being used. The stty mode worked just fine in recovery mode.

In any event as things currently are shipped on Ubuntu you will have an unbootable system if you follow the README instructions. Either decrypt_keyctl should be removed, or fixed.

The documentation should at least mention the script, and also mention that keyutils must be installed. It should also mention having to run update-initramfs on changing /etc/crypttab

askpass is broken. It should really be fixed to be able to do plymouth if it is running, or the various things (eg stty method that the decrypt_keyctl is doing).

Then everything can just use askpass. Failing that the logic for picking a password prompt program should be unified into one place. For example it could be put into a function in cryptdisk.functions and that sourced/used by decrypt_keyctl.

Status changed to 'Confirmed' because the bug affects multiple users.

Just an FYI, RHEL and CentOS v6.x for sure and I believe also v5.x does this by default. I have several encrypted disks and have to answer my password only once. If there are any doubts about security of storing password in memory, I would say if it is good for RHEL, it is good enough for Ubuntu.

When I examined the code it actually only stores the password in the system keyring for 60 seconds.

Another Ubuntu release and this is still broken. To reiterate - in theory using decrypt_keyctl as shipped by Ubuntu solves the problem. In practise it results in an unbootable machine because the mechanisms used to ask for the password do not work.

#7 provides the fix.

Roger, can you attach the files you have modified? It is very hard for me to follow what changes you have actually done. Thank you.

@bastafidli - it's not so hard, just follow his words carefully.

Regardless, I've attached the modified version, here. You'll find comments where it was modified.

@rogerbinns - please see this thread, which explains where bugs & feature requests should be made for the cryptsetup scripts:
http://www.saout.de/pipermail/dm-crypt/2012-October/002852.html

Perhaps you'd like to follow the advice there?

(In that case the author is offering a patch allowing support for root filesystems with detached luks headers:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1223622)

The attachment "decrypt_keyctl, diff" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Here is the patch to the file /lib/cryptsetup/scripts/decrypt_keyctl, as it appears in cryptsetup 1.4.1, found in ubuntu 12.04 (precise).

(Reposting as I've just learned about context diffs! :-P)

Another Ubuntu release and this is still broken. As a reminder if you use the keyscript then you will *not* be able to enter passwords, either in graphical mode (plymouth) or text mode (recovery).

@RigerBinns - Roger, thanks for the update. I actually reported this to the Debian bug tracker early this year, and included the patched file. It doesn't seem to have gone anywhere as yet.

@RigerBinns
For some reason I still cannot make it work in 14.04.1. Here is what I have done
1. I have install keyutils
2. I have applied the patch
3. I have edited /etc/crypttab similar to this
root_crypt UUID=d9d75d59-6722-49f1-b6f0-20cd54aecbf5 desktop_key luks,keyscript=decrypt_keyctl
home_crypt UUID=f3dab441-cbbc-4602-948b-24b4c323f102 desktop_key luks,keyscript=decrypt_keyctl
4. Updated boot fies
update-initramfs -u -k all

After reboot I am still being asked multiple times for the same passphrase. Any idea what I might be missing?

I tried again and I can confirm that #20 works on 14.04.02

This is still unfixed in 15.10. Here comes the patch.

Just a quick note: with the (yet to be released) version 2:1.7.0-1 of cryptsetup packages, the patch will not be necessary any longer as askpass[1] supports plymouth natively. Version 2:1.7.0-1 of cryptsetup packages is prepared in the Debian SVN repository[2] at the moment and will be uploaded to Debian Unstable soon.

[1] https://anonscm.debian.org/viewvc/pkg-cryptsetup/cryptsetup/trunk/debian/askpass.c
[2] https://anonscm.debian.org/viewvc/pkg-cryptsetup/cryptsetup/trunk

The patch I linked in #22 works for 16.04 too.

Yes, ditto here. I've also got it working. And, it works fine in tandem with the patches for detached headers: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1223622

As far as I can tell, the situation in 16.04 has improved quite a bit. I don't need this patch anymore, since all 4+ encrypted drives get unlocked with entering password only once. I still have to enter the same password again to unlock all encrypted swap.