It doesn't work if you use RAID 5 OR RAID 6
My friend have tried it
Remotely unlocking an encrypted hard disk
61–70 of 100 posts
Re: Remotely unlocking an encrypted hard disk
#62Earlier quoted context omitted.
> Realistically for a home server what you are worried about is someone breaking in and selling your drives on Facebook marketplace If someone steals the entire machine, the drives will unlock themselves automatically. I don't think it's worth the risk to assume a hypothetical thief is too lazy to check if there's any valuable data on the disks. At the very least, they'll probably check for crypto wallets. With somet…
They will unlock in to a password protected system. Unless the junkie who stole your server has an unpatched debian login bug, this won't be much use to them. If they remove the drive or attempt to boot off a USB, the drive is unreadable.
Don’t you just hit ESC during boot and change the Linux command line to init=/bin/sh?
Re: Remotely unlocking an encrypted hard disk
#63I'd love to see this in the bootloader, along with a selection of binaries useful for recovery. Might sound silly but over the years I have had many a remote system get to the bootloader and then no further after an upgrade. Nowadays we've usually got a nicely sized EFI partition, why not stuff it all in there? Gimme a full Linux userspace from the bootloader, it would feel luxurious when I'm up at 3 am trying to rec…
In new installs you do stuff everything in EFI partition and skip the old /boot partition as such.
The better solution is to use tpm, unified kernel image and secure boot skipping the network unlock.
The whole process is like this -
1. enable secure boot;
2. generate and install your own secure boot keys (using sbctl);
3. use clevis to enable automatic unlocking of the root fs only when secure boot check passes;
4. generate the unified kernel image (in EFI partition) that is signed by your secure boot key;
4. use efibootmgr to enable booting of said kernel image.
(5.) If your CPU supports it, enable memory encryption in BIOS (to mitigate cold boot attacks).
The unified kernel image doesn't accept additional kernel parameters, so only parameters that are set during generation of the initram are used. The secure boot makes sure no one else has tampered with the boot chain. And TPM stores the disk key securely.
You can still add some additional network level check to make sure that your computer is in your expected location before unlocking.
And you can also include some recovery tools + dropbear in your initram (within the unified kernel image), if you expect that you will have to do some recovery from the other side of the world.
Re: Remotely unlocking an encrypted hard disk
#64Earlier quoted context omitted.
They will unlock in to a password protected system. Unless the junkie who stole your server has an unpatched debian login bug, this won't be much use to them. If they remove the drive or attempt to boot off a USB, the drive is unreadable.
Don’t you just hit ESC during boot and change the Linux command line to init=/bin/sh?
Looks like you can either password protect grub or have the kernel start command part of the list of things the TPM checks before unlocking the key.
Re: Remotely unlocking an encrypted hard disk
#65FYI your decryption key can be MITMed during this process by anyone with physical access to the system, which defeats the purpose of encrypting the disk in the first place. Just use dm-verity for remote servers.
[flagged]
Re: Remotely unlocking an encrypted hard disk
#66MacOS recently solved this "issue".
When rebooting a FileVault encrypted machine, where it normally "hangs" asking for a user to unlock it, you can now SSH into the machine, but instead of getting a prompt it interprets your SSH login as a user logging in, hangs up, and proceeds to booting up.
Re: Remotely unlocking an encrypted hard disk
#67[dead]
Re: Remotely unlocking an encrypted hard disk
#68MacOS recently solved this "issue". When rebooting a FileVault encrypted machine, where it normally "hangs" asking for a user to unlock it, you can now SSH into the machine, but instead of getting a prompt it interprets your SSH login as a user logging in, hangs up, and proceeds to booting up.
Huuuh, is this true? Where is the Apple docs for this? Recently tried to setup a headless macos machine and all my searching led me to either having to do autologin or disabling FileVaukt fully.
Re: Remotely unlocking an encrypted hard disk
#69MacOS recently solved this "issue". When rebooting a FileVault encrypted machine, where it normally "hangs" asking for a user to unlock it, you can now SSH into the machine, but instead of getting a prompt it interprets your SSH login as a user logging in, hangs up, and proceeds to booting up.
Huuuh, is this true? Where is the Apple docs for this? Recently tried to setup a headless macos machine and all my searching led me to either having to do autologin or disabling FileVaukt fully.
Re: Remotely unlocking an encrypted hard disk
#70Can you also decrypt a PGP-encrypted hard disk now? I mean, nowadays...?