Remote unlock LUKS system disk

[kaefert]

Hey there!

I want to be able to unlock my systems luks encrypted root disk remotely.
Therefore, during setup I created a seperate unencrypted ext4 partition I've configured to be used as /boot/
Since the system uses UEFI, I've also created a separate fat32 partition for /boot/efi.

Initially the only way to unlock the system was to enter it locally on the graphical prompt shown locally.

So I continued with this (based on https://hamy.io/post/0009/how-to-instal ... unlocking/):

1. apt-get install dropbear-initramfs
2. adding the following line to the file /etc/initramfs-tools/initramfs.conf:
   DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s"
3. adding r8152 to /etc/initramfs-tools/modules
   (=module I need for my ethernet adapter, couldn't yet find a way to get this working with wifi)
4. add my ssh client's public key to /etc/dropbear-initramfs/authorized_keys
5. update-initramfs -ck all
6. reboot

And while writing this up I think I've found how I broke that already working system last night:

Because my USB-C Ethernet adapter also has an integrated card reader, the external hard-disk I'm using switched between sda & sdb, so I renamed the cryptsetup name from sda_crypt to hdd_crypt to remove the discrepancy. While at it, I also renamed nvme0n1p3_crypt to ssd_crypt to make both luks mapping names independent of the systems disk names. But it seems the script update-initramfs uses = /usr/share/initramfs-tools/hooks/cryptroot to find out what partitions it needs to unlock uses those device file names, or at least I can't see where else it would take this names from. So I'll now rename ssd_crypt back to nvme0n1p3_crypt and I think that will fix my current problem.

UPDATE: yep, that was it

[kaefert]

another update: The method above does work fine on my machine with kernel 5.4.x but not with 5.11.x

With kernel 5.11.x it seems the machine only manages to load the LAN adapters kernel module after the DHCP-client already gave up on configuring any network devices: