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

Antoine Beaupré anarcat at debian.org
Sat Jul 1 20:10:01 UTC 2017


On 2017-07-01 21:10:37, Guilhem Moulin wrote:
> Hi Antoine,
>
> On Sat, 01 Jul 2017 at 13:35:20 -0400, Antoine Beaupre wrote:
>> I used to have a custom initramfs script that would do that for me in
>> jessie, but since the stretch upgrade, it stopped working, and I'm not
>> exactly sure why: i just don't get the prompt on the SSH commandline
>> at all anymore when I run my script.
>
> Could actually be a problem with dropbear's hook scripts.  From 2015.68-1's
> changelog:
>
>     + Bring down interfaces and flush IP routes and addresses before exiting
>       the ramdisk, to avoid dirty network configuration in the regular kernel.
>       (Closes: #715048, #720987, #720988.)  The interfaces considered are
>       those matching the $DROPBEAR_IFDOWN shell pattern (default: '*'); the
>       special value 'none' keeps all interfaces up and preserves routing
>       tables and addresses.
>
> But that script is run at local-bottom stage, so just after the local root FS
> has been mounted.  (At the time I chose it rather than init-bottom because for
> NFS mounts you clearly don't want to bring down the interface ;-)  Since
> devices needed to mount / are the first ones to be unlocked, the network
> interface is brought down before you have a chance to remotely type in your
> password for other devices :-/
>
> 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.

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.

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

A.

-- 
Tu connaîtras la vérité de ton chemin à ce qui te rend heureux.
                        - Aristote



More information about the pkg-cryptsetup-devel mailing list