I’ve done a little research but curious about first hand experience.
I’ve got a little home server that is full disk encrypted with LUKS (+LVM, of course). It’s headless (no display, no keyboard, etc) and just lives attached to the back of my desk, out of the way.
If it gets rebooted due to a power outage, I can plug in a keyboard, wait long enough for it to get to the LUKS password prompt, enter password, hit enter, and assume it worked if I see the disk activity light blinking. Worst case scenario, I can move it to a monitor and plug it in to get display too.
Because lazy, I’d prefer to be able to enter the decrypt password remotely. “Dropbear” seems to be a common suggestion but I haven’t tried it yet.
So, asking for your experience or recommendations.
I’ll start. Recommendation #1 - get a UPS : D … But besides that.
Addendum: either way, I currently need to be home to do this because I access it remotely via tailscale along with my desktop. Since both are full disk encrypted, neither will boot to the point of starting tailscale without intervention. But, I might repurpose a nonencrypted RPi with SSHd to act as a “auto restarts with tailscale so I can SSH to it, then SSH to server to enter the LUKS password” jump point.
Yes it’s not too much bother to set this up, it can be put into ansible and once working I’ve not had to touch it again. Here’s another dracut tool using dropbear that works well and has decent instructions on setup: dracut-crypt-ssh
The crypt-ssh dracut module allows remote unlocking of systems with full disk encryption via ssh
On my Debian systems I use mandos to unlock LUKS during boot. All done over WireGuard which is loaded inside initramfs.
Cool! I might install something like this someday.
Do you use secure boot? What device is your server? I would use my laptop for that, but not sure if that’s how it should work.
asking out of curiousity: what benefits does encryption have here?
as long the server runs everything is decrypted right? so you are encrypting for the case when someone actively steals your hardware?
edit: stealing as in taking away. but this would mean accessing during runtime is nonetheless possible in a decrypted way?
In addition to drives being safer to replace and sell, encryption at rest should also protect against theft. So the scenario being someone taking the server or its drives. At least for me encrypting the drives gives a bit more peace of mind seeing as credentials for various accounts aren’t easily retrieved from the disks.
But yeah, this does not protect from data being read at runtime
luks will also prevent or uphold the encryption if e.g. the power is pulled?
+this means that if someone breaks in, cuts the cables during running decrypted the data is still safe?
Yes, exactly
I’ve recently upgraded my hard drives used for storage. and because I ain’t made of money, I wanted to sell the old drives.
shredding those things took ages (4 TB drives). lesson learned, new drives are btrfs + LUKS that gets unlocked via key file. so when the time comes to sell those, I won’t bother with shredding, just sell them as is.you mean that even if the next user formats it you make sure that leftovers/artefacts cannot be read right?
I do LUKS over https right now. The secret is to pass keyfile for decrypt as sh script that calls curl and echos the passkey back.
https://nowicki.io/self-hosting-lvm-raid1-with-key-over-ftp/
+2 for dropbear. I use it on a VPS and my media server.
I’m currently using a VPS that is secured by a LUKS encrypted root that gets unlocked via dropbear on boot. Can confirm, it works.
If you run a system that uses dracut to manage its initramfs, then https://github.com/gsauthof/dracut-sshd might be of use to you.
I have it setup on a server running Fedora and can’t complain. When the system reboots and plymouth shows the LUKS password prompt a ssh server is started in the background as well - so I can unlock the server either using keyboard or connect via SSH. When rebuilding the initramfs (eg. for a new kernel version) the ssh server is installed and setup automatically so I don’t really have to worry about anything after the initial setup.
Same boat. I’m currently testing some unlock stuff out. I just got USB unlocks to work for Debian by following this: https://tqdev.com/2022-luks-with-usb-unlock
I load a USB with a keyfile, then read the keyfile during boot. If I don’t have the USB plugged in, I fallback to entering a passphrase. I have multiple LUKS encrypted disks and I don’t want to type out a long passphrase a bunch of times.
I briefly encountered dropbear during my research… but ended up following the USB path because it kinda seemed a little easier to setup. 🤷
Anyone have any thoughts on USB vs dropbear unlocks?
Why not just try the common dropbear solution?
O, I fully intend to. Just wanted to ask for opinions who have done it or have tried other things while I’m sitting here waiting for an appointment.
Plus content… Lemmy… Engagement. If nobody posts then there’s nothing here
Thanks for this post. I’ve been vaguely thinking about something like this for some time, this is finally the kick I needed to actually look into it!
🫡 Thank you for your service.
I’ve used dropbear in the past and it always feels a little janky, but it works well.
I wouldn’t recommend it due to complexity, but clevis is a thing. It permits a machine to automatically unlock on boot when various environment conditions are met.
Sounds like something fun to research either way - thanks
@clif Not a remote option but you can use a FIDO2 device (e.g. yubikey) as an LUKS key, then you would just need to plug it in and hit the button.
Any guides you’d recommend to try this out?
Clevis with TPM+Tang is the most secure you’re going to get as far as automated unlocking goes.
Dropbear is still a thing, but going to be more problematic.
+1 for Clevis. I’ve been using it on my laptop for a year and it works like a charm. Sometimes, you need to update bindings after kernel updates, but it’s overall quite smooth.
