virb3 / pi-encrypted-boot-ssh Goto Github PK

Hi 😊

I think we can extend the target image size to make an up-to-date image.
But I'm not sure before or in chroot ?
I will if I have some time.

And thanks again for your work 🙏👍

No device appears after using the command kpartx also it gives no output and creates loop device that has no partitions in it
(I hope I could explain it 😅)
Thank you 😃

Applying the recommended patch to /usr/share/initramfs-tools/hooks/cryptroot creates a cryptroot.orig file in the same directory, which gets executed when running mkinitramfs, and returns the following:

(...)
Calling hook cryptroot-unlock
Adding script /usr/share/cryptsetup/initramfs/bin/cryptroot-unlock
Calling hook cryptroot.orig
/usr/bin/mkdir: cannot create directory '/var/tmp/mkinitramfs_xxxxxx/cryptroot': File exists
Copying module directory kernel/arch/arm/crypto
Copying module directory kernel/crypto
E: /usr/share/initramfs-tools/hooks/cryptroot.orig failed with return 1.

Removing the file or, better yet, running chmod -x /usr/share/initramfs-tools/hooks/cryptroot.orig, fixes the issue.

Hi there,
I like the guide (kudos to you) and it makes perfect sense but is is possible to tshoot this somehow because my image is not booting. (or not obtaining IP)
My setup is a 2022-04-04-raspios-bullseye-arm64-lite.img pi3 or 4 iamge and a vanilla amd64 debian install.
The process went fine. There was only one minor issue namely in the ssh_key section (possibly in debian) it is not /etc/dropbear/initramfs/ but /etc/dropbear-initramfs/.(but I don't think it would cause the image not to boot)
Booting the image gives only a blinking cursor. checked with wireshark and not even requesting for IP through DHCP.

Richard

Hi, happy to see this brilliant project is still alive 💗
I did everything from the readme, logged in, tried things out
Updated and upgraded, and also upgraded the kernel(if it's related)
And after reboot I can't unlock the partition from ssh because it says Permission denied (publickey)
My public key is still in /etc/dropbear/initramfs/authorized_keys
What can be the problem? Thank you

Hey,

thank you for this guide. Is it possible for you to add an howto wireguard connection? Its nice and easy at the end to connect to local rpi, but what if its somewhere outside in the world without knowing its real address?

Hi

Best tutorial ever ! You did a very good job ! Seriously.

After a lot of try... I understood why I was not able to connect to my PI after unlocking....
Don't lol please...

On raspberry pi OS, you need to add the ssh file in the boot partion during chroot part.
Like touch /boot/ssh

Great regards 👍

First of all, very useful guide, thank you!

The "Device configuration" section has a warning

NOTE: Since the device name will likely be different on the Raspberry Pi, make sure to use the name that will be found on the Pi. Do not use UUIDs since cryptsetup will try to play smart and resolve them to a device name at build time.

This is a problem for me; I use the USB boot feature recently added to the Raspberry Pi firmware, and since USB mass storage devices are not exactly known to be deterministic in Linux, it is widely recommended to use UUID or PARTUUID rather than device paths.

Because I found it a bit weird that this would be a problem and couldn't find other information indicating this behavior, I just tried it with a PARTUUID and it seems to work perfectly fine. I can't find any reference to the host device name in the extracted initramfs either. So I'm wondering what this warning is based on exactly, is this maybe only a problem under certain circumstances? Or perhaps confused with a different problem?

For reference, I tested with an Ubuntu 20.10 image. (I picked that over LTS because the LTS has some complications with USB boot)

During a system update sometime in October which involved a new kernel package, my initramfs was regenerated and after a reboot the rootfs could no longer be unlocked through SSH. After inspection in a chroot it turned out that /usr/share/initramfs-tools/hooks/cryptroot had been overwritten and the patch was no longer there. I managed to fix it by re-applying the patch and regenerating the initramfs.

I should note that I am using a modified version of this guide with Debian, but given that Ubuntu and Raspberry Pi OS are derived from Debian I'd say that this could probably happen with those distributions as well.

When I find some time I will probably look into how exactly this happens and how it could be prevented. However if anyone else has experienced something like this before and/or any potential solutions come to mind, I would much appreciate your insights.

Hi,

Very nice writeup!
Did you consider writing it in code using something like a Justfile and recipes?
Check out just - let me know if I can help in providing an initial structure!

root@user-desktop:/# mkinitramfs -o /boot/initrd.img "5.4.0-1015-r"spi"
cryptsetup: ERROR: Couldn't resolve device /dev/mmcblk0p2
cryptsetup: WARNING: target 'sda6_crypt' not found in /etc/crypttab

is it ok? ':)

I was wondering about the purpose of the qemu installation and cp of the qemu binary into the chroot. I don't see qemu being used anywhere in the process, and I get a working result without installing qemu at all. Is this a leftover from an old version that did require qemu, or am I overlooking something?

Hi, trying to encrypt my Kali on raspberry pi 4
Used this project before to do the same with Ubuntu and it worked great
I know Kali is not supported, but are there any additional action I need to take
Asking in case someone knows 😁
Thank you

Hi 😊

Resizing partion was mess because of this line echo -e "d\n2\nn\np\n2\n\n\nw" | fdisk /dev/mmcblk0

I did the fdisk part manually, but forget to note step.
Maybe you should explain more.
Like last issue, I will try if time.

Great regards 👍

When building initramfs for the Pi 5 kernel (6.1.0-rpi7-rpi-2712), the guide builds initramfs8 instead of initramfs_2712.

Just to illustrate, the script below would fix this. I think a simple comment might be more suitable, but I wasn't sure about the phrasing (especially because of the subtle differences between v8/8 and 2712/_2712).

# RPi5 with 16K pages = 2712, RPI5 or all others with 4K pages = v8
kversion="6.1.0-rpi7-rpi-v8"

case "$kversion" in
  *v8)
    iversion="initramfs8";;
  *)
    iversion="initramfs_2712";;
esac

echo "CONFIG_RD_ZSTD=y" > /boot/config-$kversion
mkinitramfs -o /boot/$iversion $kversion
rm /boot/config-$kversion

root@user-desktop:/# echo "/REDACTED/" > /etc/dropbear-initramfs/authorized_keys

and then after mkinitramfs -o /boot/initrd.img "5.4.0-1015-raspi"

dropbear: WARNING: Invalid authorized_keys file, remote unlocking of cryptroot via SSH won't work!

need help with the keys, how to make, where to move
thank you :D

Dear,

Can you add instructions for a kernel update please ?

Easy : it's already in your how-to. In the part to make the initdr.img
So steps will be like :

1. sudo apt udpate && sudo apt udgrade
2. Check if you have a kernel update. And accept updates.
3. DON'T REBOOT !
4. ls /lib/modules/ and check your latest kernel version.
5. mkinitramfs -o /boot/initrd.img "[see step4]"
6. Now you can reboot.

(raspiOs x64)

Cheers

What's expected: After the disk unlocks, the system starts booting immediately, regardless of whether network is available.

What actually happens: Without network, it takes about 62 seconds (from the time the disk unlocks) for the system to actually start booting. (With network, it starts booting immediately.)

Reason for issue: My 'host' device is off sometimes.

P.s. Thanks for the clear guide.