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

[Antoine Beaupré]

On 2017-07-02 11:44:35, Guilhem Moulin wrote:
> Control: tag -1 moreinfo
>
> On Sat, 01 Jul 2017 at 23:16:32 +0200, Guilhem Moulin wrote:
>> On Sat, 01 Jul 2017 at 16:10:01 -0400, Antoine Beaupré wrote:
>>> On 2017-07-01 21:10:37, Guilhem Moulin wrote:
>>>> Does setting “IFDOWN=none” (the option was latter renamed) in /etc/dropbear-initramfs/config 
>>>> solves your problem?  Please file a bug against dropbear-initramfs if it does.
>>> 
>>> It doesn't: the script still kills my shell and dropbear unwraps
>>> everything and kills itself as well. I then have a password prompt on
>>> the console and no ssh access from the outside.
>> 
>> Hmm odd, OTHO dropbear's shutdown script is very late.  From
>> initramfs-tools(8):
>> 
>>    init-bottom  are the last scripts to be executed before procfs and
>>    sysfs are moved to the real rootfs and execution is turned over to
>>    the init binary which should now be found in the mounted rootfs.
>>    udev is stopped.
>> 
>> I'm surprised that initramfs went so far in the init process while the
>> cryptroot script is still pending on a passphrase prompt.
>
> Actually I can't reproduce this (regardless of the value of
> dropbear-initramfs' $IFDOWN variable).
>
>     $ grep ^crypt_test /etc/crypttab
>     crypt_test  UUID=113eb3e1-8342-4f9e-86d6-17af3d976cd4 none luks,initramfs
>
> At boot time, when dropbear starts I'm able to unlock both my root FS
> and crypt_test using `cryptroot-unlock` twice.
>
>     ~ # cryptroot-unlock 
>     Please unlock disk luksRoot: 
>     cryptsetup: luksRoot set up successfully
>     ~ # cryptroot-unlock 
>     Please unlock disk crypt_test: 
>     cryptsetup: crypt_test set up successfully
>     ~ # packet_write_wait: Connection to UNKNOWN port 65535: Broken pipe

Oh. Interesting. For some reason I didn't think I could call the unlock
script multiple times!!!

By adding "initramfs" to my crypttab, I can succesfully unlock both
devices by calling the script multiple times.

Maybe what is needed then is simply a patch to the motd to warn the user
the command may need to be called multiple times? Or just loop over the
devices as you suggested before?

Thanks for the tip, it certainly works around the issue for me right
now. I think we would at least need to fix the documentation before this
is completely resolved however.

A.

-- 
Premature optimization is the root of all evil
                        - Donald Knuth