this post was submitted on 12 Jan 2025
24 points (96.2% liked)

Linux

48954 readers
720 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
 

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 :(

top 21 comments
sorted by: hot top controversial new old
[–] LodeMike@lemmy.today 8 points 10 hours ago

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.

[–] Unmapped@lemmy.ml 15 points 13 hours 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 5 points 3 hours ago* (last edited 3 hours ago)
  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.

[–] chaospatterns@lemmy.world 8 points 11 hours ago

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

[–] bjoern_tantau@swg-empire.de 2 points 13 hours 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 3 hours 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 3 hours 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 1 points 3 hours 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 13 hours ago

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

[–] bjoern_tantau@swg-empire.de 7 points 13 hours 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 13 hours ago

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

[–] ocean@lemmy.selfhostcat.com 2 points 13 hours 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 4 points 13 hours 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 10 hours ago

This is my approach. And it works nicely

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

What's your setup and your goal?

[–] ocean@lemmy.selfhostcat.com 0 points 13 hours ago

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

[–] ocean@lemmy.selfhostcat.com 0 points 13 hours 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 11 hours 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.

[–] TootSweet@lemmy.world 1 points 12 hours ago* (last edited 12 hours 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 13 hours ago

Could it be a TPM issue?