Unlock two root drives (for ZFS mirror)?

Mike Klein mike at kleinnet.com
Mon May 18 04:29:12 CEST 2020


In case it is of interest, here is the complete initramfs crypt related terminal I/O including the password prompts and ZFS module loading messages. Note that croot1’s password was prompted for twice, and croot2’s was not prompted at all. I inserted the added text based on a photo I took during boot. Maybe this helps illuminateÎ unexpected timing issues, if any.

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

Please unlock disk croot1:mandos mk: plugin-runner completed
mandos mk: trying cryptroot-unlock #1
Please unlock disk croot1:   cryptroot-unlock #1 exited with 0
mandos mk: trying cryptroot-unlock #2
   cryptroot-unlock #2 exited with 0
[   20.708398] spl: loading out-of-tree module taints kernel.
[   20.710746] znvpair: module license ‘CDDL’ taints kernel.
[   20.710986] Disabling lock debugging due to kernel taint
mandos mk: trying cryptroot-unlock #3
   /run/mandos-keep-running is gone; break
mandos mk: finished, or plugin-runner failed

		-Mike

> On May 17, 2020, at 2:08 PM, Mike Klein <mike at kleinnet.com> wrote:
> 
> 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 <mailto:teddy at recompile.se>> wrote:
>> 
>> Mike Klein <mike at kleinnet.com <mailto: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 <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/2656b708/attachment-0001.htm>


More information about the Mandos-Dev mailing list