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

[Guilhem Moulin]

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.
 
>> 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
 
> 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.

    […]
    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.

See you at DebConf in a month, I guess ;-)
-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20170704/f732a986/attachment.sig>