[pkg-cryptsetup-devel] Bug#866786: unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

[Antoine Beaupré]

On 2017-07-04 10:34:04, Guilhem Moulin wrote:
> On Mon, 03 Jul 2017 at 19:08:52 -0400, Antoine Beaupré wrote:
>> On 2017-07-03 23:21:25, Guilhem Moulin wrote:
>>> Actually I came up with a better solution that doesn't rely on the
>>> behavior of dropbear.  It passes my tests, but perhaps you could try it
>>> as well?  Then we won't have to go through this again after the Buster
>>> release ;-)
>> 
>> Hehe.. That's a great idea! Any chance this could hit stretch as well?
>> Or would that be... stretching it? *rimshot*
>
> Aha :-)  If there is enough interest I guess we could maintain a
> backport as well.

That may make more sense yes.

>>> When its standard input is a TTY, the script should now wait until all
>>> configured devices are unlocked, and prompt for passphrases when
>>> required.  Since it exits on its own once it has detected that there is
>>> nothing more to to, SSH sessions should be terminated cleanly (ie, no
>>> hang), at least when there no shell involved.  (Well hang might still
>>> occur as polling is racy, but it's merely convenience at stake and it
>>> seems to work fine here with boot and resume.)
>>>
>>> When its standard input is not a TTY the behavior is unchanged: the
>>> whole standard input is dumped to the askpass FIFO, regardless of NUL
>>> bytes or newlines (the TTY prompt above doesn't work with binary
>>> passphrases), then the script exits.  Hence one needs to invoke it as
>>> many times as there are devices to unlock.
>> 
>> from my perspective, I ssh into the box and call the script. it asks me
>> for the passwords one after the other without any noticable delay, than
>> the scripts exits and shortly after the ssh session is killed.
>
> Great, thanks for the feedback!  The new workflow will be documented in
> Sec. 8 “Remotely unlock encrypted rootfs” of README.Debian.
>
>     https://anonscm.debian.org/cgit/pkg-cryptsetup/cryptsetup.git/diff/debian/README.Debian?id=d80853c26f67a31c769e6fc1859803d9a602ca96

Excellent.

>> thanks, i guess this is done? or do we need to document the "initramfs"
>> tag in crypttab better?
>
> Anything in particular you have in mind?  crypttab(5) currently reads:
>
>     initramfs
>         The initramfs hook processes the root device, any resume devices
>         and any devices with the “initramfs” option set.  These devices
>         are processed within the initramfs stage of boot.  As an
>         example, that allows the use of remote unlocking using dropbear.

I did see that, but only after you mentioned it. I guess the problem is
the documentation is kind of split up all over the place. There's that
README.Debian, then there's:

 * /usr/share/doc/cryptsetup/README.initramfs.gz
 * "Some keyscripts have an own README file at
   /usr/share/doc/cryptsetup/"
 * crypttab(5), cryptdisks_start(8) and cryptdisks_stop(8)
 * /usr/share/doc/cryptsetup/FAQ.gz
 * /usr/share/doc/dropbear-initramfs/README.initramfs

Which one is relevant here? Probably the last one? Who knows! :) In this
case, I should have read README.initramfs and crypttab(5) but even the
latter is not clearly outlined in Sec. 8 of the README.Debian...

>     […]
>     keyscript
>         The executable at the indicated path is executed with the key
>         file from the third field of the crypttab as its only argument
>         and the output is used as the key.  This also works with
>         encrypted root filesystems via initramfs if the executable is
>         self-contained (i.e. an executable which does not rely on any
>         external program which is not present in the initramfs
>         environment).
>         […]
>         WARNING: With systemd as init system, this option might be
>         ignored.  At the time this is written (December 2016), the
>         systemd cryptsetup helper doesn't support the keyscript option
>         to /etc/crypttab.  For the time being, the only option to use
>         keyscripts along with systemd is to force processing of the
>         corresponding crypto devices in the initramfs.  See the
>         'initramfs' option for further information.

Not sure how or if this applies to my current use case. :)

> See you at DebConf in a month, I guess ;-)

Definitely :)

A.

-- 
Le féminisme n'a jamais tué personne
Le machisme tue tous les jours.
                        - Benoîte Groulx