7mo ago

How to auto unlock an encrypted drive on start for a fedora server?

I tried added a key file and even a password txt but both lead to it still asking for me to type in the password.

Is it because the drive is encrypted? I tried placing the files at /, /boot, /root, /etc

Edit1: I’ve tried to install dropbear and give it ssh keys. I will try to reboot in the morning and see what happens

Edit2: signing in via ssh just says port 22 rejected not working :(

Edit3: neither dropbear for ssh or keyfile worked. I give up.

29 comments

This isn't helpful. But genuine question. What is the point of encryption that auto unencrypts? When would it ever actually be securing the data?
- One place it would be useful is if you are worried about somebody breaking into your home and stealing your computer. Don't store the key on the home computer, instead store it on a cloud server. The home computer connects to the cloud server, authenticates itself with some secret, then if the cloud server authorizes, it can return the decryption key.
  Then if your computer gets stolen or seized, it'll connect via a different IP and the cloud server can deny access or even wipe the encryption key.
  this doesn't protect against all risks, but it has its uses.
  Example: https://www.ogselfhosting.com/index.php/2023/12/25/tang-clevis-for-a-luks-encrypted-debian-server
  
  Thanks, I was thinking about it as if the key was stored on the same drive. Like OP is trying to do. Which I don't think would help in the case of it being stolen. Or any case I can think of. But I see how A cloud key would make a lot of sense. And would be a good compromise on security vs convenience.
- Wiping the drive is a lot easier, just overwrite the root key a few times.
  If you store the key on a different drive you can safely dispose of the drive just by separating the two. (I do on my home server, keeping the decryption key on a USB drive. If I need to ship the server or discard old hardware I can just hold onto the thumb drive and not worry about the data being read.)
  Security is always about tradeoffs. On my home server unattended reboots are necessary so it needs to auto-decrypt. But using encryption means I don't need to worry about discarding broken hardware or if I need to travel with the server were it may be inspected. For my laptop, desktop and phone where I don't need unattended reboots I require the encryption key on bootup.
  
  Thanks, both of your points are good. I was thinking about it in terms of what OP is trying to do. Having key on the same drive. Putting the key on a separate drive or even the cloud like someone else suggested makes sense. I have all of my computers on manual. Since I don't have anything critical enough that it can't wait till I'm back home to start it back up.
- At least TPM is supposed to be tamper proof. So as long as you don't login automatically your data should be secure.
  It's also useful to autodecrypt it temporarily to set up more secure decryption later. OEM installs often do this. I did it on my Steam Deck while looking for a way to enter a passphrase without a keyboard.
  
  Depending on the attacker of course. If they can read your RAM after auto-decrypt they can just take the encryption key.
- I’m doing this for when I’m out of town and want it to startup and open if the UPS loses power.
Hi. You now need to create a new key for the drive as you placed it in an unencrypted partition.
You just use /etc/crypttab and /etc/fstab to do it. Just look up "auto mount LUKS at startup" theres like 100 guides.
- Any further advice? I tried many guides but none worked. Going insane.
  
  You have systemd right?
  The process is, to simplify:
  Generate a keyfile. You should make sure to chmod 600 it. Or better yet keep it in a folder.
  Add this keyfile to the LUKS container. You should make sure to test it.
  Edit /etc/crypttab to include a line to auto-unlock the LUKS container by UUID. You will also specify a logical name, which will mount the block device at /dev/mapper/logicalname>
  Edit /etc/fstab to auto mount /dev/mapper/logicalname> at /path/to/mountpoint
  On startup, systemd will read these files and dynamically create a service for it.
Just putting the key file somewhere does nothing. It has to be in a spot that is not encrypted and the kernel has to know where it is. Putting it on /boot or /boot/efi is one way. Putting it in the initrd is another.
Of course, having the key out in the open defeats the purpose of encrypting the drive in the first place. Sealing it in TPM would be one solution. But still you have to tell the kernel where to find it.
Personally my server has a ssh server in the initrd and allows me to unlock it remotely that way. I think it uses dropbear.
There should be several tutorials for every way. No idea if there are Fedora specific ways to follow.
- I have Tailscale access to the network. Could you please tell me what I should search to be able to ssh input the password? Currently I cannot ssh prior to the password being inputted.
  This would be a great solution! Secure and mobile
  
  This looks similar to the tutorial I used on my Debian server. https://askubuntu.com/questions/1269981/unattended-headless-ubuntu-server-with-disk-encryption-how-to-set-it-up
- Ah okay I searched dropbear, this seems like a helpful solution!
Check out https://fedoramagazine.org/using-linux-system-roles-to-implement-clevis-and-tang-for-automated-luks-volume-unlocking/
You can have a small rpi or similar on your WiFi in a hidden location on a UPS, so the main computer can’t boot without the tang server accessible.
- This is my approach. And it works nicely
Interesting thoughts in this thread.
I simply switched to having an unencrypted boot partition with the automount key on a flash drive. After it boots the server, just remove the whole boot partition. Physical separation is much much more powerful for smash and grabs, petty seizures, and evil maid than TPMs.
The flash drive is stored securely when I am in the area. Flash drive can go in the machine if I am away for a while or have something critical.
I go a step further and have password-only data drive description so I have to ssh in to set up the data drives again, but the principle would be the same.
- Yes, that is why I see little value in a TPM for this sort of thing. That is at least for motherboard attached TPMs.
What's your setup and your goal?
- Another comment made me think unlocking via ssh would be good too
- Goal is to boot when I’m away if UPS loses power. Setup is a fedora server with /dev/sda3 encrypted, the whole drive. I want it to auto unlock when I cannot type it in myself.
  
  /dev/sda3 would be one partition no?
  Is this a NAS by chance? What I do is I have the boot and root partitions unencrypted but all my files, media, etc are encrypted. If the power goes out I SSH in, mount it and start up file sharing services. Sure it’s a bit tedious, but at least if someone breaks into my apartment and runs off with my drives they won’t see the actual contents.
Keep in mind that you have to decide where your going to get the primary unlock key from and how your going to secure it. Standard way is to supply the primary key for the root partition on boot via the console and then the other keys are stored in the root partition.
There are other ways to get the primary key. You can get it from a TPM, a network key server, from other media, etc. These are not standard and have to be set up. What is best depends on threat model.
Does it really do any good for the drive to be encrypted if it doesn't require a password (or Yubikey or retinal scan or other authentication factor) on boot? If you're just going to put the plaintext key/password on the same drive but in a partition that's not encrypted, there's no point encrypting the drive, right?
So maybe "it asks for a password on boot" is more of a "works as intended" thing?
How will I access the encrypted devices after installation? (System Startup) During system startup you will be presented with a passphrase prompt. ...
The quote above is from Fedora documentation here
This is your root FS that's encrypted that we're talking about, correct?
If you really want an encrypted root but no password on boot and the plaintext decryption password/key on the same drive, there are ways to do it. (It would probably require customizing the initramfs somehow. But it's Linux, and Linux certainly isn't going to prevent you from doing such things. Just try to dissuade you.)
If we're not talking about a root filesystem, that would likely change some things. If it's Luks, I'm pretty sure it wouldn't matter particularly where on your filesystem the key was so long as your /etc/crypttab refers to it. I'd say that sort of setup would probably only provide additional security if the encrypted drive is an external drive that you might worry could be stolen or physically accessed when the attacker doesn't have physical access to your root filesystem.
Also, if you shared what encryption scheme was in use (Luks, Anaconda, etc), that would probably help as well.
Edit: Ah. Ok. You gave more info while I was typing the above response. What you want is unlocking via ssh. For sure.
Could it be a TPM issue?

29 comments