Remote unlocking not possible if plymouth is active (Bug or Feature?)

Reported by hal2100 on 2010-06-17
This bug affects 28 people
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
plymouth (Ubuntu)

Bug Description

Binary package hint: cryptsetup

If plymouth is active, it is no longer possible in an easy way to remotely unlock the disc(s).
Which means that with a standard Ubuntu setup the README.remote is wrong or incomplete.

Reason: Plymouth is "stealing" the password prompt because the cryptroot script checks if plymouth is active:

if [ -z "$cryptkeyscript" ]; then
   cryptkey="Unlocking the disk $cryptsource ($crypttarget)\nEnter passphrase: "
   if [ -x /bin/plymouth ] && plymouth --ping; then
    cryptkeyscript="plymouth ask-for-password --prompt"
    cryptkey=$(echo -e "$cryptkey")

but only askpass has a feature which is checking for a file with a password in it.

Because I am not so good in writing startup fixes, I am proposing this as a bug.
Possible solutions:
1. Include a new script, which doesn't use plymouth at all.
2. Use command line switches to use askpass instead of plymouth.
3. Patch plymouth, e.g. to include a "pass-as-password" option, which is passing the password along to a running plymouth(d?).

My knowledge about the inner workings of the startup process is limited, I would prefer solution no. 3.
Any suggestions?

Steve Langasek (vorlon) wrote :

You're correct that the documentation is now out of date. However, plymouth is only the /default/ interface used by cryptsetup; you can probably get the same effect as before by using a 'keyscript=' option in /etc/crypttab. Though plymouth is still going to control the console, so you'll have to do some further tuning if you want to be able to unlock using either local console or a remote unlock command.

Changed in cryptsetup (Ubuntu):
importance: Undecided → Low
status: New → Triaged
tags: added: bitesize
hal2100 (hal-from-2001) wrote :

Sorry, but I think we have a misunderstanding here.
We should aim for a solution which enables both ways. With the introduction of plymouth also a bug was introduced, because the old behavior was canceled without notice. The solution with the keyscript is not feasible, as far as I understand, because this would disable plymouth completely, which is not the goal.

From my point of view this could be easily fixed if someone who knows the startup procedure very well could just post the necessary steps to disable plymouth just for this "one" startup when remote unlocking is desired. My problem is I do not know the side effects if I just do a:
$killall plymouthd
$killall plymouth
$/bin/sh /path/to/cryptroot

Perhaps there is a way to stop plymouth without the killall, but I simply do not know the cleanest ways.
I think this bug can be fixed without a single line of code, just with a better documentation. I would write one, but I do not know the consequences...

On Mon, Jun 21, 2010 at 05:34:54PM -0000, hal2100 wrote:
> We should aim for a solution which enables both ways.

I agree that's the optimum, but that's not possible today, so I'm suggesting
a workaround that would work for anyone who exclusively unlocks their system

> With the introduction of plymouth also a bug was introduced

I'm not disputing that, but this is not nearly so easy to fix as you
suppose, and we're certainly not going to revert the plymouth support which
fixed many other, much higher-impact bugs.

> I think this bug can be fixed without a single line of code

Sorry, but you're mistaken. The cryptsetup "askpass" helper doesn't support
plymouth, instead cryptsetup uses the plymouth client directly, and that's
currently mutually exclusive with remote unlocks without writing some
significant code.

Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

hal2100 (hal-from-2001) wrote :

>I'm not disputing that, but this is not nearly so easy to fix as you
>suppose, and we're certainly not going to revert the plymouth support which
>fixed many other, much higher-impact bugs.

This is the point I don't understand. Why is a "killall plymouth*" bad?
This would allow for an easy solution, kill plymouth after remote log in and use the askpass "fallback" as it is currently implemented. Leave everything as it is if I am sitting in front of the machine using plymouth to unlock.
I do not want to disable plymouth completely, just for the remote sessions.

An more complicated solution would be to introduce a "--accept-pass SECRET" option to plymouth to inject the password from a second console (the remote login) into the currently waiting plymouth(d?) process which asks for the password.
Alternatively plymouth could check for the same file askpass is checking, but I would prefer the first solution.

But this would definitely mean some more lines of code, I agree.

DW (derwolf111) wrote :

if I comment the lines in /usr/share/initramfs-tools/scripts/local-top/cryptroot like this:

if [ -z "$cryptkeyscript" ]; then
   cryptkey="Unlocking the disk $cryptsource ($crypttarget)\nEnter passphrase: "
   #if [ -x /bin/plymouth ] && plymouth --ping; then
   # cryptkeyscript="plymouth ask-for-password --prompt"
   # cryptkey=$(echo -e "$cryptkey")

then remote unlocking works again

ingo (ingo-steiner) wrote :

Check this bug report how to de-install plymouth:

daniel_L (daniel-das-grauen) wrote :

@DW / #5:
I cannot confirm this, I still can't unlock my disk via ssh when commenting out the mentioned lines. Can you pleasy explain how exactly you unlock the disk?

DW (derwolf111) wrote :

checkout readme.debian in /usr/share/doc/cryptsetup or http://wiki.ubuntuusers.de/Verschl%C3%BCsseltes_System_via_SSH_freischalten

daniel_L (daniel-das-grauen) wrote :

That's actually the guide I already followed without success. Anyways, I found the "solution": I had to update the initramfs image in order to get this working; that's a step the guide is missing (maybe because it's more or less obvious). Nevertheless, the guide is written as if it provides all neccessary steps so I just didn't get the idea - until now.

Thanks anyway.

164747 (jacquet-david) wrote :

From yout comment, I understand that you have uncomment lines suggested by DW in #5, and fot remote ssh unlocking working after running "update-initramfs -u". Thats nice! However can you still unlock the machine by classical mean, keyboard on site? Or do you have unlock it remote?

Ryan Lackey (ryan.lackey) wrote :

I've also applied DW's fix (thanks!) and think maybe this should be the default for now until there is a better fix in place.

daniel_L (daniel-das-grauen) wrote :

Unfortunately, with this fix it's not possible to unlock the system with a keyboard on site.

hal2100 (hal-from-2001) wrote :

If we find a way to unlock the computer on site as well, this "bug" could be closed at last....

Timmeey (zoggerfish) wrote :

I found a solution in ubuntuusers Forum


this guy wrote a little script. It worked for me (10.10)now I'm able to unlock locally AND over ssh

just copy this script into /usr/share/initramfs-tools/hooks/
make it executable
(chmod +x) and
update-initramfs -u

reboot.... now ure up and running

Richard Hansen (a7x) wrote :

@Steve Langasek: What about adding a read-from-fifo capability to 'plymouth ask-for-password' like /lib/cryptsetup/askpass has?

Stephen Warren (srwarren) wrote :

A solution to making this work remotely is:

1) SSH in
2) Manually run cryptsetup; basically run ps, find the cryptsetup command-line, remote the key-file option, run it, type the password into cryptsetup
3) kill cryptsept process, kill plymouth process

It just worked for me:-)

Launchpad Janitor (janitor) wrote :

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

Changed in plymouth (Ubuntu):
status: New → Confirmed

@a7x that would be my preferred solution as well. I looked at the source and it's unfortunately a client/server based system so it's not a 10-minute fix for someone not used to the source code of plymouth (like me.)

AllenS (thehousecat) on 2013-01-09
Changed in cryptsetup (Ubuntu):
status: Triaged → Confirmed
Steve Langasek (vorlon) on 2013-01-09
Changed in cryptsetup (Ubuntu):
status: Confirmed → Triaged
AllenS (thehousecat) wrote :

The following solution is simple and works for me. My configuration is the default encrypted LVM setup created by the Precise alternative installer.

ssh to the remote machine and run the following commands:

kill $(pidof plymouthd)
# Wait a few seconds for '/scripts/local-top/cryptroot' to timeout and retry using 'askpass' instead of plymouth
echo -ne password > /lib/cryptsetup/passfifo

Davidos (davidos-di) wrote :

Have a look at probably simpler solution provided here:

The solution is to install plymouth-dummy package and remove the standard one. Then everything works fine as earlier.
This is fully based on https://bugs.launchpad.net/cryptsetup/+bug/556372/comments/78
Oliver Joos (oliver-joos) wrote on 2012-03-25: #78

Ok then, here is the ready-to-install plymouth-dummy_1.0_all.deb! It's an empty package but allows to remove plymouth while keeping the packages that have wrong dependencies to plymouth.

To workaround this (WontFix??) bug and remove plymouth just execute 2 commands in a Terminal:
  sudo dpkg -i plymouth-dummy_1.0_all.deb
  sudo apt-get remove plymouth

Advanced users can build plymouth-dummy_1.0_all.deb themselves: see comment 16
Many thanks to Christian Kujau!

I've tested it on 12.04 LTS

cunnilinux (cunnilinux) wrote :

with installed plymouth-dummy and removed original plymouth, i could not unlock my partitions vial local keyboard.
seems like this works for remote unlocking via ssh, but still does not fixes all issues.
tested on raring as for 2013-02-17.


I've tried on quantal (12.10) server and with the plymouth-dummy package I could unlock using BOTH the passfifo method and using a keyboard on site, attached to the machine. Did you followed the correct instructions?:

1) dpkg -i plymouth-dummy_1.0_all.deb
2) apt-get remove plymouth
3) update-initramfs -u

reboot then done

Richard Hansen (a7x) wrote :

Attached is a script I wrote to make it easier to unlock systems from remote. It works on precise and quantal even with the original plymouth. I haven't tried the script on raring yet.

It appears that plymouth-dummy doesn't work on raring (13.04). I've installed it and when I try to remove the plymouth package, it tries to remove a lot of dependencies and if I remove it, the apt gets broken. If I reinstall it though, it works again, but remote unlocking using the passfifo method doesn't work, only using the script from #23 or one of the other methods (that kill the cryptroot process and wait many seconds). There is any deadline for this bug being permanently solved? Remote unlocking a luks or dm-crypt root container should be easy to use, perhaps even an option on an ubuntu server installation, since there are a lot of VPS hosting providers that offer this kind of installation.

Felix Eckhofer (eckhofer) wrote :

On Raring, something like this works:

  cat /conf/conf.d/cryptroot
  /sbin/cryptsetup luksOpen <source> <target>
  kill $(pidof plymouth)

Where <source> and <target> have to be replaced by the respective parameters from the output of the first command.

What is the proposed way to fix this issue? It should be rather easy to create a script which uses the functions from local-top/cryptroot to parse options from /proc/cmdline and /conf/conf.d/cryptroot, then calls /sbin/cryptsetup as above and on success kills the plymouth password prompt. Calling this script from a wrapper which waits for input on /lib/cryptsetup/passfifo seems similary simple. Would a patch be accepted if it did that?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers