Buster version of dropbear changed (cryptroot-unlock messge)

[Jethro_UK]

Upgraded from Stretch to Buster on a machine that has an encrypted disk. I had configured the boot process to allow the disk to be unlocked via SSH, using dropbear.

When it was all setup back in 2017, on connecting via SSH, there was a terminal prompt that said "use cryptroot-unlock" to unlock the disk. Sure enough you entered "cryptroot-unlock" and were prompted for a password.

Come upgrade to Buster, and that message is gone. You now just get a regular terminal prompt. You can still enter "cryptroot-unlock" and continue as before. But there's no message.

This matters, because the person I set this up for had a screenshot showing them what to do when, and with a different screen they were lost.

Not really a bug, but it's a change which has had an effect, so thought I'd note it here. Although if anyone can explain the rationale behind the change (apart from shaving a few bytes off the final image) I'd be interested.

[ruwolf]

I do not know, but by Debian Changelog it may be due CVE-2018-15599?

[Jethro_UK]

Well I don't know either. Just had to reboot again, and once again noticed it's missing - also missing from the "help" text.

So if anyone else is following a guide on setting up SSH access to allow a remote drive to be decrypted before boot, then be aware that you won't be told the command you need is "cryptroot-unlock" - you just have to know it.

One way of keeping things secure, I guess.

[Jethro_UK]

OK, so a bit of further digging reveals that the message appears to be originating in a file in the "cryptsetup" package in Debian.

The initramfs part has been refactored so that the stretch file

Code: Select all

~/initramfs/cryptroot-unlock-hook

is now

Code: Select all

~/initiramfs/hooks/cryptroot-unlock

In that file is the section:

Code: Select all

if [ -f /etc/initramfs-tools/etc/motd ]; then
    copy_file text /etc/initramfs-tools/etc/motd /etc/motd
else
    cat >>"$DESTDIR/etc/motd" <<- EOF
		To unlock root partition, and maybe others like swap, run \`cryptroot-unlock\`.
	EOF
fi

So it looks like for some reason my "motd" file isn't setup properly.

[p.H]

Does /etc/initramfs-tools/etc/motd exist on your system ?
If yes, the hook script just copies it into the initramfs. If no, it creates one with the expected message.

[cuckooflew]

Another one, http://forums.debian.net/viewtopic.php? ... 47#p725135
Maybe instead of starting a new thread, and then referring back to the original, just answer what is asked here, your responses are needed to determine what has changed, and why ,etc.

See: http://forums.debian.net/viewtopic.php?f=30&t=10653 Forum guidelines. Please read before first post!

[Jethro_UK]

Does /etc/initramfs-tools/etc/motd exist on your system ?
If yes, the hook script just copies it into the initramfs. If no, it creates one with the expected message.

No it doesn't. But I still don't see the message. That's assuming we are looking at the /etc on my machine, not the /etc that gets built into initrd ???

E2A: I've unpacked my /boot/initrd.img-4.19.0-10-amd64, and there is:

/etc/motd which contains:

Code: Select all

To unlock root partition, and maybe others like swap, run `cryptroot-unlock`.
To unlock root-partition run unlock

So maybe the question is why is that not being displayed ?

[Jethro_UK]

Possible explanation here

https://matt.ucc.asn.au/dropbear/CHANGES

- Re-enable printing MOTD by default, was lost moving from options.h. Thanks to zciendor

E2A:

Code: Select all

xxxx@DellDesktop:~/tmp$ dropbear -V
Dropbear v2018.76

So hopefully when v79 is packaged with Debian, the problem is fixed.

E2A:

And here's the horses mouth:

https://github.com/mkj/dropbear/pull/87

zciendor commented on 6 Jan

The man page (https://github.com/mkj/dropbear/blob/master/dropbear.8) says MOTD will be printed by default for any login shell, but it was disabled at compile time. Probably happened by accident when this code was moved from options.h to default_options.h.
@zciendor
MOTD enabled by default as the manpage says
7f1a885
@zciendor
Contributor Author
zciendor commented on 6 Jan •

I realized this because in Debian stretch this still worked but in buster it is broken, so I compared the sources between the stretch package and buster package.