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 :(
You must log in or register to comment.
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.
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.
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?
- 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.
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.
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.
I’m doing this for when I’m out of town and want it to startup and open if the UPS loses power.
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.
Though they should be able to do that with manually decrypted drives as well, if they can access the RAM, right?
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).
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.
Ah okay I searched dropbear, this seems like a helpful solution!
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
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
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/sda3would 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.
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?
