Skip to main content


LUKS decrypt at boot over SSH?


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

in reply to clif

I've used dropbear in the past and it always feels a little janky, but it works well.
in reply to clif

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!
in reply to clif

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.
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.

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.

in reply to just_another_person

+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.
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.

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.

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…

in reply to 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.
This entry was edited (19 hours ago)

Linux reshared this.

in reply to clif

+2 for dropbear. I use it on a VPS and my media server.
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?

This entry was edited (18 hours ago)
in reply to clif

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.
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…

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.

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 :

You know how it is. You’ve heard of it happening. The Man comes and takes away your servers, your friends’ servers, the servers of everybody in the same hosting facility. The servers of their neighbors, and their neighbors’ friends. The servers of people who owe them money. And like that, they’re gone. And you doubt you’ll ever see them again.
That is why your servers have encrypted root file systems
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?

This entry was edited (15 hours ago)
in reply to PoisonedPrisonPanda

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.
in reply to glitching

you mean that even if the next user formats it you make sure that leftovers/artefacts cannot be read right?
in reply to PoisonedPrisonPanda

no, I mean the drive is encrypted and I don't gotta bother with shred.
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

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?

in reply to SphericalCow

Exactly this. The chances of my server/drives getting stolen is extremely low but I like to take all the precautions I can even if it's just an exercise in "I can, so I will". That and the "peace of mind" you mentioned.
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

The crypt-ssh dracut module allows remote unlocking of systems with full disk encryption via ssh
in reply to IanTwenty

I think this is the first time I've heard of dracut. I'll take a look - thanks for the info.
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.

⇧