Unlock two root drives (for ZFS mirror)?

[Teddy Hogeborn]

Mike Klein <mike at kleinnet.com> writes:

> > In the case of an initramfs image created by initramfs-tools(7), the
> > Mandos client (actually the plugin-runner(8mandos) which in turn
> > runs the Mandos client) is started at boot and kept running
> > (re-started if it exits) until the root disk has been mounted.
> > Every time a password is recieved by the Mandos client, it is sent
> > as input to the "cryptroot-unlock" program (a part of the
> > "cryptsetup-initramfs" package, documented by
> > /usr/share/doc/cryptsetup-run/README.Debian.gz).  That program, as
> > documented, keeps accepting passwords until all devices are
> > unlocked.  Therefore, using the same password for multiple devices
> > should work, in theory.
> >
> > If you are having problems with this, debug by adding --debug and/or
> > --options-for=mandos-client:--debug to the
> > "/etc/mandos/plugin-runner.conf" file, rebuild the initramfs with
> > "update-initramfs -k all -u", and reboot.
> 
> Thank you, Teddy. I finally got time to work on this again. I am
> replying to your email as I haven’t found a way to reply on the
> archive site. I’m going to attach a log file from setting --debug for
> mandos-client.
>
> The dual-drive automatic unlock is not working. From what I can gather:
>
> 1) plugin-runner runs early in the cryptsetup process and it actually
> contacts the server and gets the correct passphrase
> 2) However, it appears that cryptsetup ignores the output and asks for
> interactive entry of the passphrase for both file systems to be
> unlocked

The initramfs-tools boot system always asks for passphrase on the
console; a password could still be provided by mandos-client in the
background even though a password prompt is visible and active.

> 3) The debug log shows that mandos-client has exited and this is still
> on the screen when I see the prompt for the passphrase for the first
> file system

This is probably normal.  As seen in the script
/usr/lib/$ARCH/mandos/mandos-to-cryptroot-unlock, the Mandos
plugin-runner is run once, and the password obtained thereby is passed
to the cryptroot-unlock executable ten times in a row, after which the
password is discarded and new password is obtained.  This continues
until the initramfs boot process has progressed far enough that the root
file system has been mounted.

However, I now see that my initial description of this procedure was
incorrect; if the password is passed *successfully* to cryptroot-unlock,
the whole procedure stops, and will therefore not unlock more than one
device.  If you want to keep using initramfs-tools, you could try
editing the mandos-to-cryptroot-unlock script to remove the "&& break 2"
at the end of line 72, and rebuild the initramfs image.

> I’m attaching the debug output, with decrypted passphrase removed. The
> debug output scrolls by on the screen before I see the passphrase
> prompt, but it could be that the prompt occurs early and scrolls off
> the screen quickly and then is printed again.

This debug output only tells us two useful things:

1. A password was successfully obtained.
2. A password was only requested once.

> I am using initramfs-tools.

You could try using dracut; this, as I explained previously, uses
competely different password delivery mechanisms, both of which should,
theoretically, work with multiple encrypted devices.

> I also agree that ZFS should be underneath and encryption on top, and
> this is the long term intent, but this is not available until ZFS
> implements native encryption, which also provides other features
> e.g. snapshots are encrypted so sending and saving snapshots offsite
> is encrypted throughout. If the dual-unlock does not work, I will
> probably go back to LUKS over software RAID1.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mail.recompile.se/pipermail/mandos-dev/attachments/20200517/25802e06/attachment.sig>