Unlock two root drives (for ZFS mirror)?

[Mike Klein]

Teddy, thank you — the change you suggested works. No problem now; both partitions are unlocked in quick succession with password from server.

I added a number of echo commands into the loop in mandos-to-cryptroot-unlock to watch what was happening, as follows:

echo "mandos mk: starting cryptroot-unlock attempts" >&2
while command -v cryptroot-unlock >/dev/null 2>&1; do
    echo "mandos mk: start a new plugin-runner to get a password" >&2
    /lib/mandos/plugin-runner > "$passfile" &
    echo $! > /run/mandos-plugin-runner.pid
    echo "mandos mk: waiting for plugin-runner..." >&2
    wait %% || break
    echo "mandos mk: plugin-runner completed" >&2

    # Try this password ten times (or ten seconds)
    for loop in 1 2 3 4 5 6 7 8 9 10; do
	echo "mandos mk: trying cryptroot-unlock #$loop" >&2
	if [ -e /run/mandos-keep-running ]; then
	    # Mike K 2020-05-17: On advice from Teddy Hogeborn, remove
	    # the break since it stops providing password after a single successful attempt
	    #cryptroot-unlock < "$passfile" >/dev/null 2>&1 && break 2
	    cryptroot-unlock < "$passfile" >/dev/null 2>&1
	    echo "   cryptroot-unlock #$loop exited with $?" >&2
	    sleep 1
	else
	    echo "   /run/mandos-keep-running is gone; break" >&2
	    break 2
	fi
    done
    echo "mandos mk: finished" >&2
done
echo "mandos mk: finished, or plugin-runner failed" >&2

/var/log/boot.log shows:

mandos mk: starting cryptroot-unlock attempts
mandos mk: start a new plugin-runner to get a password
mandos mk: waiting for plugin-runner...
  Reading all physical volumes.  This may take a while...
IP-Config: eno1 hardware address xx:xx:xx:xx:xx:xx mtu 1500
  /dev/sdi: open failed: No medium found
IP-Config: eno1 guessed broadcast address xxx.xxx.xxx.xxx
IP-Config: eno1 complete:
 address: xxx.xxx.xxx.xxx  broadcast: xxx.xxx.xxx.255  netmask: 255.255.255.0   
 gateway: 0.0.0.0          dns0     : 0.0.0.0          dns1   : 0.0.0.0         
 host   : xxxxxxxxxx                                                         
 rootserver: 0.0.0.0 rootpath: 
 filename  : 
  Found volume group "tm" using metadata type lvm2
  /dev/sdi: open failed: No medium found
  5 logical volume(s) in volume group "tm" now active
mandos mk: plugin-runner completed
mandos mk: trying cryptroot-unlock #1
   cryptroot-unlock #1 exited with 0
mandos mk: trying cryptroot-unlock #2
   cryptroot-unlock #2 exited with 0
mandos mk: trying cryptroot-unlock #3
   /run/mandos-keep-running is gone; break
mandos mk: finished, or plugin-runner failed

Many thanks!

		-Mike

> On May 17, 2020, at 6:33 AM, Teddy Hogeborn <teddy at recompile.se> wrote:
> 
> 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
> _______________________________________________
> Mandos-Dev mailing list
> Mandos-Dev at recompile.se
> 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/20200517/f3f4ed44/attachment-0001.htm>