Unlock two root drives (for ZFS mirror)?

Sun May 17 03:59:19 CEST 2020

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

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.

I am using initramfs-tools.

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.

Many thanks,

		-Mike

> On May 10, 2020, at 3:16 PM, Teddy Hogeborn <teddy at recompile.se> wrote:
> 
> Mike Klein <mike at kleinnet.com <mailto:mike at kleinnet.com>> writes:
> 
>> I searched back a number of years in the archives and found only a
>> vaguely a similar question asked and at least partly answered:
>> https://mail.recompile.se/pipermail/mandos-dev/2016-July/000350.html.
>> 
>> I have just transitioned to running root on a ZFS 2-way mirror,
>> LUKS-encrypting each underlying drive with the same passphrase.
>> Previously I was running Linux RAID1 and encrypting the assembled RAID
>> array, so only one decryption key was required.
>> 
>> What will the mandos client in initramfs do in this situation? Will it
>> unlock both drives, in quick succession, one after the other (bringing
>> up and down the network interfaces), or will it unlock just one? I
>> want to have some idea of what to expect before rebooting in this
>> configuration so I know what steps to take next.
>> 
>> Debian 10, Mandos 1.8.11.
> 
> Short answer: It should, in theory, unlock all devices.  But we have not
> tested this, since we do not use ZFS.
> 
> (Anyone who does not use ZFS should probably do encryption on top of
> RAID - like you did previously, and which we do - in which case there is
> no problem.  If there should be additional non-root filesystems on
> devices needing decryption, the passwords for those devices should be
> saved in secured files on the encrypted root file system, and the
> filenames should be entered in the third field of the line for each
> device of /etc/crypttab.)
> 
> Long answer: To understand the process, it is important to realize that
> the Mandos client does not itself unlock any devices; the Mandos client
> simply provides a password to other systems which does the unlocking.
> The Mandos client does not even necessarily start itself; it might be
> started on request by other systems.
> 
> There are three different cases, currently:
> 
> 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.
> 
> In the case of an initramfs image created with dracut(8) without
> systemd(1) installed, we override the "ask_for_password" shell function
> as defined by the file "/usr/lib/dracut/modules.d/90crypt/crypt-lib.sh"
> as provided by the "dracut-core package".  I can't give an immediate
> answer on if dracut will call that function multiple times for multiple
> devices, but from what I can tell, I would guess that it does.  Debug
> any problems with this by doing the same thing as with
> "initramfs-tools", above, except that you rebuild the initramfs with
> "dpkg-reconfigure dracut".
> 
> In the case of an initramfs image created with dracut(8) when systemd(1)
> is installed, the Mandos client instead provides a systemd "Password
> Agent", and will provide any recieved passwords to any password requests
> asked using the systemd password agent system.  This, too, should, in
> theory, work for any number of devices needing passwords at boot.
> 
> To debug this, run "journalctl --unit=ask-password-mandos.service
> --boot" as root after a successful boot.  To get more debug info, run
> "systemctl edit ask-password-mandos.service" and enter these two lines:
> 
> [Service]
> Environment=MANDOS_CLIENT_OPTIONS=--debug
> 
> Rebuild the initramfs with "dpkg-reconfigure dracut", and reboot.
> 
> /Teddy Hogeborn
> 
> -- 
> The Mandos Project
> https://www.recompile.se/mandos <https://www.recompile.se/mandos>
> _______________________________________________
> Mandos-Dev mailing list
> Mandos-Dev at recompile.se <mailto:Mandos-Dev at recompile.se>
> https://mail.recompile.se/cgi-bin/mailman/listinfo/mandos-dev <https://mail.recompile.se/cgi-bin/mailman/listinfo/mandos-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.recompile.se/pipermail/mandos-dev/attachments/20200516/15dc71d0/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mandos.log
Type: application/octet-stream
Size: 29633 bytes
Desc: not available
URL: <http://mail.recompile.se/pipermail/mandos-dev/attachments/20200516/15dc71d0/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.recompile.se/pipermail/mandos-dev/attachments/20200516/15dc71d0/attachment-0003.htm>