Hi there ! I have a little box at home, hosting some little services for personal use under freebsd with a full disk encryption (geli). I’m never at home and long power outage often occurs so I always need to come back home to type my passphrase to decrypt the disk.
I was searching this week a solution to do it remotely and found the “poor-guy-kvm” solutions turning a Raspberry like board (beaglebone black in my case) in a hid keyboard. It works fine once the computer has booted but once reboot when the passphrase is asked before it loads the loader menu, nothing. When I plug an ordinary USB keyboard I can type my passphrase so USB module is loaded.
Am I missing something ? Am I trying something impossible ?
(I could’ve asked on freebsd forum but… Have to suscribe, presentation, etc… Long journey)
You must log in or register to comment.
I’m in the market for a similar solution. Is the BeagleBone being powered via USB? If so, it might be trying to pull more current than the USB stack will allow at that point. Can you debug the board while it’s in the non-working state? Also, does it present as a single HID device?
Yes the beaglebone black is currently powered by USB. Unfortunately I am not able to debug the board while it’s not working due to my lack of skill… I don’t know how to do… Maybe I can read dmesg on the bbb for a message stating this nonworking state while it asks for passphrase on the PC for a first step… Yes once it’s booted, freebsd see it as a single hid device, just a hid device
Not sure about FreeBSD but under Linux I have used SSH based solutions in the past, specifically dracut-sshd to call systemd-tty-ask-password-agent and of course some early network configuration.
Have you looked into policy-based decryption? Here’s an knowledge base page on the RHEL customer portal that goes over it well. I’m not sure if this will work on freebsd but it does offer a solution that allows for zero-touch reboots.
Oh interesting, I will read that back to my computer , thanks !
Oh interesting, I will read that back to my computer , thanks !
I’m not sure how it’d work for freebsd, but on Linux, you can get sshd running in your initrd. You can even go as far as getting an onion service running in your initrd, and using that for remote access.
I’m using encrypted ZFS as the root partition on my server and I’ve (mostly) followed the instructions in point #15 from here: https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Bookworm%20Root%20on%20ZFS.html
This starts dropbear as an SSH server that only has a single task: when someone logs in to it they get asked for the decryption key of the root partition.
I suspect that this could be adopted to whatever encryption mechanism you use.
I didn’t follow it exactly, because I didn’t want the “real” SSH host keys of the host to be accessible unencrypted in the initrd, so the “locked host” has a different SSH host key than when it is fully booted, which is preferred for me.
I’ve read that freebsd 14 proposed zfs native encryption, so it could worked. Maybe it’s time to upgrade, I will see. Thanks !
Like someone already mentioned, you can use dracut-ssh for rpm-based distros or dropbear-initramfs for deb-based distros. My idea would be to use debian as host and virtualize or dockerize the freebsd system/software part.
If you have a TPM 2 you can use secure boot (custom keys) to allow Linux to decrypt itself if nothing has changed.
What do you mean by if nothing has changed? Wouldnt this mean someone could physically steal the machine and then boot it up somewhere else and it’d auto decrypt itself?
Yes. That is possible. However if the hardware configuration/software configuration changes the TPM should trip and prevent decryption.
The attackers would have to break you ssh/terminal/lock screen/other insecure software. However code injection should be impossible because you used custom secure boot keys and ideally a signed unified kernel image. (Can’t even change kernel params without tripping TPM.)
You would not be safe if they did a bus listening attack or if your shell pwd is not safe. If that is your threat vector this may not be a good option for you.
I have a box at home … I’m never at home.
How is this your home? Please resolve this mystery so I can find sleep again.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters IP Internet Protocol PCIe Peripheral Component Interconnect Express SSH Secure Shell for remote terminal access ZFS Solaris/Linux filesystem focusing on data integrity
4 acronyms in this thread; the most compressed thread commented on today has 12 acronyms.
[Thread #340 for this sub, first seen 8th Dec 2023, 22:45] [FAQ] [Full list] [Contact] [Source code]
