Fellow selfhoster, do you encrypt your drives where you put data to avoid privacy problems in case of theft? If yes, how? How much does that impact performances? I selfhost (amongst other services) NextCloud where I keep my pictures, medical staff, …in short, private stuff and I know that it’s pretty difficult that a thief would steal my server, buuut, you never know! 🤷🏻♂️
How do you even encrypt a server so that it doesn’t require human intervention every time it goes down/restarts?
Isn’t that what a TPM could be used for?
i dunno is it? how to set that up?
I’m too lazy to look up the details. But you can have a small ssh server running as part of initrd. I think it’s dropbear. I log into that and unlock the root drive from there.
Of course that necessitates an unencrypted /boot/.
Did it on Debian and it was relatively easy to set up.
I‘m in the process of setting up a new NAS with Debian and disk encryption, and this is exactly what I’m struggling with. I’ve tried multiple guides for Dropbear but every time I try to SSH into the server to unlock it, I get “Permission denied”.
This answer here covers it quite nice imo.
https://unix.stackexchange.com/questions/5017/ssh-to-decrypt-encrypted-lvm-during-headless-server-boot
Important is that you update your initramfs with the command after you edited the dropbear initramfs config and or you copied the key over.
For the client it is important to define 2 different known hosts files since the same host will have 2 different host keys, 1 when encrypted with dropbear, and 1 when operational with (usually) sshd.
Also you need to use root when you connect to your server to unlock it. No other user will work with the default setup.
I was actually using my own user account instead of root, but now that you mention it… I’m not sure how that would even work so yeah that makes sense.
I did rebuild the initramfs after every change but did not manually copy the key file anywhere other than etc.
Will check out the link tomorrow. Thanks a lot for sharing!
Edit: tried again with root and it worked flawlessly :D
I don’t reboot my server that often. But I think I use a dedicated port and key for it. I don’t use them anywhere else. Maybe the key has to be a specific format for Dropbear.
Files could be decrypted by the end user. The OS itself could remain unencrypted.
The only time my Server goes down, is when i manually reboot it. So waiting a minute or two, to ssh into it and entering the passphrase is no inconvenience.
TPM, but it’s a pain in the ass and breaks a lot. The new version of Ubuntu should handle it better, but if you’re not on Ubuntu, that won’t help you.
TPM solves a sigthly different threat model: if you dispose the hd or if someone takes it out from your computer it is fully encrypted and safe. But if someone steals your whole server it can start and decrypt the drive. So you have to trust you have good passwords and protection for each service you run. depending on what you want to protect for this is either great solution or sub optimal
I remember this blog post (I cannot find right now) where the person split the decryption password in two: half stored on the server itself and half on a different http server. And there was an init script which downloaded the second half to decrypt the drive. There is a small window of time between when you realize that the server is stolen and when you take off the other half of the password where an attacker could decrypt your data. But if you want to protect from random thieves this should be safe enough as long as the two servers are in different locations and not likely to be stolen toghether.
Use Clevis either with TPM or Tang (remote server) https://github.com/latchset/clevis
TPM is a good way, Mine is setup to have encryption of / via TPM with luks so it can boot no issues, then actual sensitive data like the /home/my user is encrypted using my password and the backup system + fileserver is standard luks with password.
This setup allows for unassisted boot up of main systems (such as SSH) which let’s you sign in to manually unlock more sensative drives.