Tag Archives: dropbear

Stretch and dropbear: important upgrade notes

I used cryptsetup + dropbear in initramfs often. The integration in Debian was sometimes “strange”, but reading the doc was enough. With stretch I found some problems; I found the solutions, too, so hope this would be useful

authorized_keys path

dropbear in initramfs will only allow login from root. The keys used to be read from /etc/initramfs-tools/root/.ssh/authorized_keys

The path was weird, and it changed to /etc/dropbear-initramfs/authorized_keys. This is great and more logical, but AFAIK undocumented and without retrocompatibility.

UUID for root partition in fstab is not supported

Yep. You’d better use /dev/mapper/cryptoroot as device path. It’s just as reliable as the UUID.

use the same mapper name on the install system and the installed system

That’s hard to explain. I was installing debian from a rescue system using debootstrap, then manually editing relevant files, then running

chroot /mnt/ update-initramfs -u -k all

Unforunately, I mounted /mnt/ using cryptsetup open /dev/sda1 root, but /mnt/etc/crypttab mentioned the same device as cryptoroot. update-initramfs doesn’t like this discrepancy.

ethernet persistent naming

I know, that’s not a bug, and that’s widely known. However, I find some edges confusing. For example, the initramfs called my interface “eth0” but on the main system it was “enp3s0”. I would have also liked to have an easy way to know what name my ethernet interface would have had with persistent naming enabled

logging

I’m not totally sure about it because I was testing, and maybe my conclusions are wrong. However, at first boot it did not log anything. When I created /var/log/journal, log finally appeared. I think this doesn’t match the documentation, which states that creating /var/log/journal is only needed to log in journald format, not to log to /var/log/syslog or /var/log/messages