You can actually unlock LUKS from another machine over SSH: https://www.cyberciti.biz/security/how-to-unlock-luks-using-dropbear-ssh-keys-remotely-in-linux/
I'm pretty happy with this solution
this post was submitted on 07 Aug 2024
39 points (91.5% liked)
Selfhosted
40296 readers
301 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
I saw this and thought "How is this even possible? No way you run an SSH server from initramfs…" Turns out that's exactly how you do it, I'll be trying this out thank you!
This is the way.
LUKS can use a TPM now.
Wait, how's this gonna help? If someone swipes the machine, they also have the TPM. TPM only helps against someone reading the disks on another machine. TPM is only useful to protect data during physical access if the rest of the firmware/software stack is impenetrable. In practical terms this would mean locked UEFI, disabled alternate boot device, Secure Boot, locked GRUB, and locked logins. In effect the security of the data is transferred from the knowledge of a passphrase to the knowledge of a login password, and the attack surface is expanded across multiple systems that all have to be secure and configured correctly to not allow access prior to OS login.
I read it as external drives, as someone "swiping the drives" without having stolen the whole ass computer kinda requires that?
I agree that if someone steals the whole computer, you're pretty fucked unless you have a password entered somewhere in the chain to actually do the decryption, but I mean, they explicitly didn't want that.
I'm not sure there's a good way to encrypt a system that'll boot with no interaction (and thus has to be able to decrypt itself with no input) and prevent access if it's stolen.
This is one of those 'software security doesn't matter if you can't guarantee physical security' meta-problems, probably.
Yeah, you're right, if it's meant as disks-only, then TPM is the easy solution.
I think SSH unlocked LUKS at boot might be a decent compromise, with the SSH server at a different physical location.
I mean, TPM-locked machine with all the other parts configured correctly should be reasonably secure. It would boot without interaction and be available on the network. It would require a sophisticated and motivated actor to find a vulnerability in one of the systems in the boot chain to get in. That's probably good enough for preventing data leaks from theft. But the user has to make sure the whole boot chain is configured securely.
Yeah, and the threat actor here is probably less 'guy who knows Linux, LUKS, and how to bypass this' and more 'dude who wants to sell this for $5 on craigslist for more meth', which pretty much means if the data is encrypted at rest and generally not accessible without logging in with a password they don't have then it's... probably fine?
Do encrypted backups with Borgbackup or similar. That means the server never sees the plaintext or the decryption keys. The encryption happens on the client. Since it's public-key encryption (separate keys for encryption and decryption), the client doesn't need the decryption key either, except when restoring. So your backup can be automated without secret keys.
Only useful if the backup machine isn't also used as a hot spare.
I worte a guide last year on how I do network bound encryption - that is the disk will automatically decrypt at boot if it's connected to my home network, but not if the disk or machine is removed from my house. The advantage over the dropbear method is that you can set unattended upgrades to auto reboot your server whenever it installs security updates, and it'll come back up with no manual intervention from you.
If you want simple you'll have to manually decrypt each time it needs doing.
If you want it to be "automatic" then your best bet is something network based. A "simple" would be to just have a script ssh's somewhere, pulls the decryption key, and then decrypts the disks. There's plenty of flaws with this though as while a threat actor couldn't swipe a single encrypted disk they could just log in as root, get your script, and pull the decryption key themselves.
The optimal solution would be to also encrypt the root partition but now you need to do network based decryption at boot which adds further complexity. I've previously used Clevis and Tang to do this.
I personally don'tencrypt my server root and only encrypt my data disks. Then ssh in on a reboot or power event and manually decrypt. It is the simplest and most secure option.
I use a luks encrypted USB drive for automated backups. My backup script mounts and decrypts the drive automatically, using secret-tool to grab the encryption pass from my keyring. It then creates the snapshots, and automatically unmounts the drive after.
There might be better methods, but this one works well for me.
If someone can login as root on that machine, by for example rebooting in recovery mode, they can also run the script and access the drives. Or they can get the password from the keyring. A keyring that doesn't require a password to unlock or whose password is stored somewhere on the machine is equivalent to plain text storage. There's no obvious solution other than ensuring the system can't be rooted without a login, I'm just pointing the flaw out in case you feel it's more secure than it is.
In my case root partition is encrypted, and the keyring has to be unlocked every time you reboot.
As mentioned elsewhere, the easiest method is to encrypt only the data drives. This way you can secure shell into the server upon restart and decrypt the data. I've been using this method for years now without issue.
I am not seeing any benefit over this solution https://lemmings.world/comment/10027984 , were even the root is encrypted. With dropbear installed on initramfs you can also just ssh into the server to unlock everything.
The dropbear method is more secure overall, and I plan to incorporate it as well when I find the time to wipe/reinstall my server, but it's arguably not as easy or simple, which is what OP requested.
I think you can encrypt drives by using a key stored in the TPM, if you have one. See the Arch wiki for info.
Though I have heard the TPM is not as secure..
That isn't possible. I would look into physical security (ie a locked cage)
If someone nicks it, can't they just use boltcutters? Could hide the drive under the floorboards theoretically
If someone shows up with bolt cutters then you have other issues. They just as well could hold you at gun point
I mean the whole machine. Unless I cage it to the floor
Here’s my way of doing it. TLDR: LUKS with a encryption key hosted in my router
https://nowicki.io/self-hosting-lvm-raid1-with-key-over-ftp/
Take some time and really analyze your threat model. There are different solutions for each of them. For example, protecting against a friend swiping the drives may be as simple as LUKS on the drive and a USB key with the unlock keys. Another poster suggested leaving the backup computer wide open but encrypting the files that you back up with symmetric or asymmetric, based on your needs. If you're hiding it from the government, check your local laws. You may be guilty until proven innocent in which case you need "plausible deniability" of what's on the drive. That's a different solution. Are you dealing with a well funded nation-state adversary? Maybe keying in the password isn't such a bad idea.
I'm using LUKS with mandos on a raspberry PI. I back up to a Pi at a friend's house over TailScale where the disk is wide open, but Duplicity will encrypt the backup file. My threat model is a run of the mill thief swiping the computers and script kiddies hacking in.