LUKS decrypt at boot over SSH?
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.
frongt
in reply to clif • • •clif
in reply to frongt • • •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
MimicJar
in reply to clif • • •paequ2
in reply to clif • • •clif
in reply to paequ2 • • •whimsy
in reply to clif • • •dragonfly4933
in reply to clif • • •clif
in reply to dragonfly4933 • • •SphericalCow
in reply to clif • • •If you run a system that uses dracut to manage its initramfs, then github.com/gsauthof/dracut-ssh… 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.
GitHub - gsauthof/dracut-sshd: Provide SSH access to initramfs early user space on Fedora and other systems that use Dracut
GitHubmodeh
in reply to SphericalCow • • •+1
This is my setup as well, having a headless Fedora server, being able to unlock over SSH makes things a breeze.
just_another_person
in reply to clif • • •Clevis with TPM+Tang is the most secure you're going to get as far as automated unlocking goes.
docs.redhat.com/en/documentati…
Dropbear is still a thing, but going to be more problematic.
Chapter 10. Configuring automated unlocking of encrypted volumes by using policy-based decryption | Security hardening | Red Hat Enterprise Linux | 8 | Red Hat Documentation
docs.redhat.comdata1701d (He/Him)
in reply to just_another_person • • •clif
in reply to just_another_person • • •If I'm reading the docs correctly, Clevis can rely on a separate Tang server for retrieving the decryption key, right? So in that scenario I'd need to have another machine for Tang that can also auto-boot without entering a boot/LUKS password. Otherwise, if both machines (server+clevis and Tang server) were in the same room and restarted due to power loss, neither would be able to boot if both were encrypted... or did I misunderstand something important?
And I don't think I actually want "automatic" unlocking. I just want to be perform the unlock (enter LUKS password) remotely. I realize that comes with manual intervention (entering the password remotely) but I'm okay with that. I should probably have clarified that by "home server" I mean a machine the serves nice to have stuff, nothing mission critical. Plus I'm really the only one who uses it currently so I'll notice it's down when something doesn't work and can then initiate the remote unlock/boot : D
Clevis is interesting but I don't think it matches my specific situation. Glad I know about it now though, thanks for the info.
GitHub - latchset/clevis: Automated Encryption Framework
GitHubjust_another_person
in reply to clif • • •If you just want to remotely interact with LUKS to unlock it, I think dropbear-initramfs module is your only option.
Clevis+Tang is essentially the same thing but automatic, and yes it does require a separate machine and network access to that machine.
clif
in reply to just_another_person • • •sznowicki
in reply to clif • • •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.
nowicki.io/self-hosting-lvm-ra…
LVM RAID1, LUKS, encrypted with key over FTP
nowicki.ioMark
in reply to clif • •Linux reshared this.
paequ2
in reply to Mark • • •Mark
in reply to paequ2 • •Linux reshared this.
Jess
in reply to clif • • •paequ2
in reply to clif • • •Same boat. I'm currently testing some unlock stuff out. I just got USB unlocks to work for Debian by following this: tqdev.com/2022-luks-with-usb-u…
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?
LUKS with USB unlock
tqdev.comclif
in reply to paequ2 • • •I'd imagine that if you have physical access and don't mind plugging in a USB then that's the easier route.
My personal goal is to be able to unlock it remotely in two main scenarios :
1. I'm lazy and don't want to have to awkwardly fumble at plugging in something. So, SSH to it from the same room and unlock it from my desktop.
2. Server got rebooted while I'm away from home but I would really like it to be up and running again for something I need but I don't have physical access at the time.
Both of those situations lean towards a remote unlock with no USB. The first one is absolutely doable because I have local access and could plug a device in, it's just awkward. On the second, physical access is impossible so it must be done remotely.
I mentioned it in another comment but the remote unlock while away from home presents extra challenges for me because I access my server externally via Tailscale. Since Tailscale isn't available at boot (pre-decrypt), then I'll have to tailnet+ssh to another machine on the LAN (that doesn't require a boot passwor
... Show more...I'd imagine that if you have physical access and don't mind plugging in a USB then that's the easier route.
My personal goal is to be able to unlock it remotely in two main scenarios :
1. I'm lazy and don't want to have to awkwardly fumble at plugging in something. So, SSH to it from the same room and unlock it from my desktop.
2. Server got rebooted while I'm away from home but I would really like it to be up and running again for something I need but I don't have physical access at the time.
Both of those situations lean towards a remote unlock with no USB. The first one is absolutely doable because I have local access and could plug a device in, it's just awkward. On the second, physical access is impossible so it must be done remotely.
I mentioned it in another comment but the remote unlock while away from home presents extra challenges for me because I access my server externally via Tailscale. Since Tailscale isn't available at boot (pre-decrypt), then I'll have to tailnet+ssh to another machine on the LAN (that doesn't require a boot password/unlock) and then SSH from that machine to the server to enter the LUKS password to allow boot to continue. Sounds feasible, though perhaps a little clunky. That's my current plan and hoping to try it out this weekend if time permits.
paequ2
in reply to clif • • •clif
in reply to paequ2 • • •Just one... For now 😀
It's a Lenovo Tiny refurb and came with a 1TB NVMe which is plenty for playing around but I'll have to expand if I move my Jellyfin instance to it.
paequ2
in reply to clif • • •Ah, nice ok. Your post got me to look at dropbear a little more closely, but since I got a bunch of disks, I think USB unlock makes more sense in my setup. I'm using a keyfile on the USB to unlock a bunch of disks on boot. But if I only had one, then dropbear would be more doable for me.
Neat! Interesting post!
Lemmchen
in reply to clif • • •SirMaple__
in reply to clif • • •On my Debian systems I use mandos to unlock LUKS during boot. All done over WireGuard which is loaded inside initramfs.
recompile.se/mandos
github.com/r-pufky/wireguard-i…
GitHub - r-pufky/wireguard-initramfs: Use dropbear over wireguard.
GitHubTMP_NKcYUEoM7kXg4qYe
in reply to SirMaple__ • • •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.
clif
in reply to SirMaple__ • • •This is interesting, another one I hadn't heard of yet. And, the server is running Debian : )
I enjoy the intro too :
PoisonedPrisonPanda
in reply to clif • • •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?
glitching
in reply to PoisonedPrisonPanda • • •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.PoisonedPrisonPanda
in reply to glitching • • •glitching
in reply to PoisonedPrisonPanda • • •PoisonedPrisonPanda
in reply to glitching • • •yah thats what i meant.
in a way.
SphericalCow
in reply to PoisonedPrisonPanda • • •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
PoisonedPrisonPanda
in reply to SphericalCow • • •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?
IanTwenty
in reply to PoisonedPrisonPanda • • •PoisonedPrisonPanda
in reply to IanTwenty • • •clif
in reply to SphericalCow • • •IanTwenty
in reply to clif • • •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
GitHub - dracut-crypt-ssh/dracut-crypt-ssh: dracut initramfs module to start dropbear sshd during boot to unlock the root filesystem with the (cryptsetup) LUKS passphrase remotely
GitHubclif
in reply to IanTwenty • • •nucleative
in reply to clif • • •Interesting, I want to try some of these solutions.
I set up luks on some of my selfhosted virtualbox instances to protect against physical theft, but power issues cause all too frequent restarts that are a serious pain to physically access.
An ssh call in a script that could be remotely used to unlock and complete the boot would be so handy.
Björn
in reply to clif • • •I use dropbear in initramfs on my Debian server. Works great.
At home I have a cheap networked KVM because I also sometimes have hardware problems preventing a boot. Works really well. Cost 100 € and uses open source software. It's called GL.iNet KVM.
clif
in reply to Björn • • •Good to hear. This will be going on a Debian server too.
I just set up tailscale on the RPi that controls my printer so I've got a jump host on the LAN now... Just need to make time to setup dropbear (and keys) on the server.