Manual password entry. I feel that any other method offers insufficient security.
For my desktops, this means interactive decryption before the OS loads. For my servers, only the data drives are encrypted, and I decrypt them manually over SSH whenever a reboot is needed (kernel updates, etc.).
In the past I wanted to use auto unlock via TPM, however it seems quite complicated to set up and the Arch wiki advises against it anyway, so I just enter the password during boot.
The one improvement I would like to make here is to have a nicer input (visually) like Fedora but I’m not sure how this is done and how I could replicate that on Arch.
If I understand your query correctly, Fedora uses a Plymouth theme called bgrt which displays the OEM logo and asks for the key in a nicer input. Try setting your Plymouth theme to bgrt
Thank you! I had no clue what to even search for but your comment pointed me in the right direction.
I spent the past hour setting this up and it almost works, but for some reason when I boot I only see something like “Loading initramfs” and then just a black screen and nothing happens. If I mash the escape key before I reach the black screen then plymouth works and I see the logo and LUKS password prompt.
The boring method, unlock boot drive with password, then the other drives with a keyfile referenced in crypttab. Although now that I think about it, if I were to reboot the machine remotely I wouldn’t be able to do anything on the machine until I have physical access.
I’ve always used Veracrypt since I discovered its existence.
Nice inconspicuous encrypted loop-files you can mount manually when needed (or automount at boot, but that already makes them a lot less safe) and backup to any cloud safely, as without the password they are useless.
I’m not sure if this is helpful to you or not, because it’s not what you asked. I just don’t mount them on boot though.
I have a script that requires a unique password that decrypts everything that I actually care about. If that hasn’t been run, then the server starts emailing me every 15 minutes until I do.
The server is not setup to reboot unless I manually tell it to or there is a power outage, so logging in to run the script has never really been an issue. At most, I’ve had to SSH in from my phone maybe a handful of times.
Initramfs listening with dropbear to prompt me for my passphrase. I can ssh in if I needed to reboot, or if it’s lost power for longer than my ups can keep it running.
Wireguard connects to a cloud VPS that acts as the mandos server and then grabs the key from mandos.
All my systems are protected by LUKS aside from /boot which in my case simply holds the wireguard config and what’s required to get the key from mandos. Yes this leaves the wireguard keys exposed but I’m not concerned since in my case they’re only good for this purpose and it’s easy to disable a peer. Plus the VPS has nftables rules that only allow traffic on the wireguard interface to a single port that the mandos server listens on.
I only encrypt the data using LUKS and I have a password stored in Google Secrets Manager. I have a script that runs as a systemd service, goes fetch the password and unlocks the volume. If the drive is somehow stolen, I just revoke the key and the data is unreadable.
TPM stores the encryption key against secure boot. That way, if attacker disables/alters secure boot then TPM won’t unseal the key. I use clevis to decrypt the drive.
Flash drive hidden under the carpet and connected via a USB extension, holding the decryption keys - threat model is a robber making off with the hard drives and gear, where the data just needs to be useless or inaccessible to others.
There’s a script in the initramfs which looks for the flash drive, and passes the decryption key on it to cryptsetup, which then kicks off the rest of the boot mounting the filesystems underneath the luks
I could technically remove the flash drive after boot as the system is on a UPS, but I like the ability to reboot remotely without too much hassle.
What I’d like to do in future would be to implement something more robust with a hardware device requiring 2FA. I’m not familiar with low level hardware security at all though, so the current setup will do fine for the time being!
I used to run a TFTP server on my router that held the decryption keys.
As soon as a machine got far enough in the boot sequence to get network access, it would pull the decryption keys from the router.
That way a thief would have to steal the router along with the computer, and have the router running when booting up the computer.
It works wirelessly, too!
Flash drive hidden under the carpet and connected via a USB extension, holding the decryption keys - threat model is a robber making off with the hard drives and gear, where the data just needs to be useless or inaccessible to others.
This is a pretty clever solution. Most thieves won’t follow a cable that for all intents looks like a network cable, especially if it disappears into a wall plate or something.
I don’t think most thieves care much about the data on the computer in the first place. Steal hardware, fresh install of Windows on it and straight to the pawn shop.
Agreed. Even just putting a non-Windows/Mac compatible file system on it may have the same effect. They cannot see files when they plug the drive into their PC or Mac, so they probably also just format it.
For my thief threat model, I just have the computer in an unassuming black Node304 in a utility room on a shelf lol. Security through obscurity is often as good for a smash and grab threat. They go for visually high value items.
Entire boot partition with main drive keys on a removable hard drive with security keys for the data drives in an encrypted password manager. No way a theif is getting that data, even if I accidentally leave the boot drive in there out of laziness. That means that I am comfortable storing personal documents there also.
It is indeed more of a hassle to reboot. USB plugged in -> decrypt and setup zpools script -> docker service restart. Specifically upgrading the kernel also because with the boot partition removed, all of the hooks don’t get processed. However, this also protests against the copyright gangster smash and grabs as a bonus. Probably an extreme edge case as that doesn’t happen anymore here in Belgium, but it was interesting to set up.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
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
Manual password entry. I feel that any other method offers insufficient security.
For my desktops, this means interactive decryption before the OS loads. For my servers, only the data drives are encrypted, and I decrypt them manually over SSH whenever a reboot is needed (kernel updates, etc.).
In the past I wanted to use auto unlock via TPM, however it seems quite complicated to set up and the Arch wiki advises against it anyway, so I just enter the password during boot.
The one improvement I would like to make here is to have a nicer input (visually) like Fedora but I’m not sure how this is done and how I could replicate that on Arch.
If I understand your query correctly, Fedora uses a Plymouth theme called
bgrtwhich displays the OEM logo and asks for the key in a nicer input. Try setting your Plymouth theme to bgrtThank you! I had no clue what to even search for but your comment pointed me in the right direction.
I spent the past hour setting this up and it almost works, but for some reason when I boot I only see something like “Loading initramfs” and then just a black screen and nothing happens. If I mash the escape key before I reach the black screen then plymouth works and I see the logo and LUKS password prompt.
Check out Archwiki plymouth , in the installation section, make sure that you have silent boot as that’s what usually blocks plymouth from displaying.
The boring method, unlock boot drive with password, then the other drives with a keyfile referenced in crypttab. Although now that I think about it, if I were to reboot the machine remotely I wouldn’t be able to do anything on the machine until I have physical access.
I’ve always used Veracrypt since I discovered its existence.
Nice inconspicuous encrypted loop-files you can mount manually when needed (or automount at boot, but that already makes them a lot less safe) and backup to any cloud safely, as without the password they are useless.
I’m not sure if this is helpful to you or not, because it’s not what you asked. I just don’t mount them on boot though.
I have a script that requires a unique password that decrypts everything that I actually care about. If that hasn’t been run, then the server starts emailing me every 15 minutes until I do.
The server is not setup to reboot unless I manually tell it to or there is a power outage, so logging in to run the script has never really been an issue. At most, I’ve had to SSH in from my phone maybe a handful of times.
Initramfs listening with dropbear to prompt me for my passphrase. I can ssh in if I needed to reboot, or if it’s lost power for longer than my ups can keep it running.
Mandos and wireguard inside initramfs.
Wireguard connects to a cloud VPS that acts as the mandos server and then grabs the key from mandos.
All my systems are protected by LUKS aside from /boot which in my case simply holds the wireguard config and what’s required to get the key from mandos. Yes this leaves the wireguard keys exposed but I’m not concerned since in my case they’re only good for this purpose and it’s easy to disable a peer. Plus the VPS has nftables rules that only allow traffic on the wireguard interface to a single port that the mandos server listens on.
I’m using mandos with the server on a raspberry pi. Unfortunately, mandos doesn’t work with my Fedora boxes as far as I know.
deleted by creator
I only encrypt the data using LUKS and I have a password stored in Google Secrets Manager. I have a script that runs as a systemd service, goes fetch the password and unlocks the volume. If the drive is somehow stolen, I just revoke the key and the data is unreadable.
TPM stores the encryption key against secure boot. That way, if attacker disables/alters secure boot then TPM won’t unseal the key. I use clevis to decrypt the drive.
Does a PiKVM to enter the password manually count?
Flash drive hidden under the carpet and connected via a USB extension, holding the decryption keys - threat model is a robber making off with the hard drives and gear, where the data just needs to be useless or inaccessible to others.
There’s a script in the initramfs which looks for the flash drive, and passes the decryption key on it to cryptsetup, which then kicks off the rest of the boot mounting the filesystems underneath the luks
I could technically remove the flash drive after boot as the system is on a UPS, but I like the ability to reboot remotely without too much hassle.
What I’d like to do in future would be to implement something more robust with a hardware device requiring 2FA. I’m not familiar with low level hardware security at all though, so the current setup will do fine for the time being!
I used to run a TFTP server on my router that held the decryption keys. As soon as a machine got far enough in the boot sequence to get network access, it would pull the decryption keys from the router. That way a thief would have to steal the router along with the computer, and have the router running when booting up the computer. It works wirelessly, too!
This is a pretty clever solution. Most thieves won’t follow a cable that for all intents looks like a network cable, especially if it disappears into a wall plate or something.
I don’t think most thieves care much about the data on the computer in the first place. Steal hardware, fresh install of Windows on it and straight to the pawn shop.
Agreed. Even just putting a non-Windows/Mac compatible file system on it may have the same effect. They cannot see files when they plug the drive into their PC or Mac, so they probably also just format it.
For my thief threat model, I just have the computer in an unassuming black Node304 in a utility room on a shelf lol. Security through obscurity is often as good for a smash and grab threat. They go for visually high value items.
Entire boot partition with main drive keys on a removable hard drive with security keys for the data drives in an encrypted password manager. No way a theif is getting that data, even if I accidentally leave the boot drive in there out of laziness. That means that I am comfortable storing personal documents there also.
It is indeed more of a hassle to reboot. USB plugged in -> decrypt and setup zpools script -> docker service restart. Specifically upgrading the kernel also because with the boot partition removed, all of the hooks don’t get processed. However, this also protests against the copyright gangster smash and grabs as a bonus. Probably an extreme edge case as that doesn’t happen anymore here in Belgium, but it was interesting to set up.
I’m curious; how would you do it for VMs with an encrypted virtual disk?
Same way.