this post was submitted on 12 Jan 2025
36 points (97.4% liked)

Linux

49007 readers
1076 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
AgreeableLandscape@lemmy.ml
nooter692@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r
36
How to auto unlock an encrypted drive on start for a fedora server? (lemmy.selfhostcat.com)
submitted 3 days ago* (last edited 2 days ago) by ocean@lemmy.selfhostcat.com to c/linux@lemmy.ml
29 comments fedilink hide all child comments
 

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.

top 29 comments
sorted by: hot top controversial new old
[–] JustEnoughDucks@feddit.nl 3 points 2 days ago* (last edited 2 days ago) (1 children)

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.

[–] furrowsofar@beehaw.org 2 points 1 day ago* (last edited 1 day ago)

Yes, that is why I see little value in a TPM for this sort of thing. That is at least for motherboard attached TPMs.

[–] Unmapped@lemmy.ml 24 points 3 days ago (4 children)

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?

[–] kevincox@lemmy.ml 15 points 2 days ago* (last edited 2 days ago) (1 children)
  1. Wiping the drive is a lot easier, just overwrite the root key a few times.
  2. 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.

[–] Unmapped@lemmy.ml 3 points 2 days ago (1 children)

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.

[–] kevincox@lemmy.ml 1 points 2 days ago

Yeah, I don't think there are many benefits when keeping the key on the same drive. Other than a bit of obfuscation. It does still help with erasing, as you can wipe the keyslots (rendering the key useless) but with modern storage media deletion is fairly hard to ensure. But still better than unencrypted.

[–] chaospatterns@lemmy.world 16 points 3 days ago (1 children)

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

[–] Unmapped@lemmy.ml 3 points 2 days ago

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.

[–] bjoern_tantau@swg-empire.de 2 points 3 days ago (1 children)

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.

[–] kevincox@lemmy.ml 1 points 2 days ago (1 children)

Depending on the attacker of course. If they can read your RAM after auto-decrypt they can just take the encryption key.

[–] bjoern_tantau@swg-empire.de 1 points 2 days ago (1 children)

Though they should be able to do that with manually decrypted drives as well, if they can access the RAM, right?

[–] kevincox@lemmy.ml 4 points 2 days ago

Only if they gain possession when the device is running with the drive decrypted and they keep it running the whole time. That is a lot higher bar then being able to turn the machine on at any time and then recover the key. For example if this is a laptop that you are flying with. Without auto-decryption you can simply turn it off and be very secure. With auto-decryption they can turn it on then extract the key from memory (not easy, but definitely possible and with auto-decryption they have as long as they need, including sending the device to whatever forensics lab is best equipped to extract the key).

[–] ocean@lemmy.selfhostcat.com 2 points 3 days ago

I’m doing this for when I’m out of town and want it to startup and open if the UPS loses power.

[–] LodeMike@lemmy.today 11 points 3 days ago (1 children)

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.

[–] ocean@lemmy.selfhostcat.com 1 points 2 days ago (1 children)

Any further advice? I tried many guides but none worked. Going insane.

[–] LodeMike@lemmy.today 1 points 2 days ago

You have systemd right?

The process is, to simplify:

  1. Generate a keyfile. You should make sure to chmod 600 it. Or better yet keep it in a folder.
  2. Add this keyfile to the LUKS container. You should make sure to test it.
  3. 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>
  4. 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.

[–] bjoern_tantau@swg-empire.de 7 points 3 days ago (2 children)

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.

[–] ocean@lemmy.selfhostcat.com 2 points 3 days ago

Ah okay I searched dropbear, this seems like a helpful solution!

[–] ocean@lemmy.selfhostcat.com 2 points 3 days ago (1 children)

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

[–] Starbuck@lemmy.world 5 points 3 days ago (1 children)

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.

[–] finsk@lemmy.ml 2 points 3 days ago

This is my approach. And it works nicely

[–] umami_wasbi@lemmy.ml 3 points 3 days ago (2 children)

What's your setup and your goal?

[–] ocean@lemmy.selfhostcat.com 0 points 3 days ago

Another comment made me think unlocking via ssh would be good too

[–] ocean@lemmy.selfhostcat.com 0 points 3 days ago (1 children)

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.

[–] undefined@lemmy.hogru.ch 2 points 3 days ago

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

[–] furrowsofar@beehaw.org 1 points 2 days ago

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.

[–] TootSweet@lemmy.world 1 points 3 days ago* (last edited 3 days ago)

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.

[–] ocean@lemmy.selfhostcat.com -1 points 3 days ago

Could it be a TPM issue?