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

[Guilhem Moulin]

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.

Could you pass ‘debug’ to the kernel command line, then sanitize and
attach /run/initramfs/initramfs.debug?  Probably your /etc/crypttab and
/etc/fstab (at least the relevant lines) would be helpful, too.
 
> I am *guessing* that systemd may do the right thing next: in theory, the
> system *can* start without that partition (it's /srv), or at least the
> real sshd and then I could login and unlock the other partition. But on
> my first try, this is not what happened, at least I wasn't patient
> enough to let the machine go down any longer...
> 
> But that's my current use case: it would be a perfectly legitimate use
> case to have /, /usr and /var in three different LUKS filesystems, in
> which case the current configuration would just fail completely.

Unlike / and /usr, /var isn't needed at initramfs stage, so the
cryptsetup boot scripts won't try to unlock it early.  If for some
reason it needs to be mounted before systemd kicks in (for instance
because its lacking a crypttab(5) feature you need, such as keyscripts),
adding ‘initramfs’ to crypttab(5)'s 4th column should do the trick.
 
>>> The normal "cryptroot-unlock" program doesn't work either for multiple
>>> partitions.
>>
>> That's something which would be nice to have, indeed.  In principle it should
>> work (at least if the network interface was up) if you were to reconnect for
>> each disk, but I see some benefits in using the same script for all passphrase
>> prompts ;-)  I'll need to test this, but AFAICT a while loop would be enough as
>> dropbear's cleanup script kills the sshd and all its children (hence the script
>> itself) at init-bottom stage.
> 
> I tried to figure out how to do this myself, but ended up writing my own
> shell script with hardcoded defaults.

Same here.  Then I joined the cryptsetup and dropbear maintaining team,
and tried to make my solution generic enough to ship it along with the
packages ;-)

-- 
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/20170701/8e9a3e18/attachment.sig>