Live data from Hacker News

Remotely unlocking an encrypted hard disk

jyn.dev

71–80 of 100 posts

Re: Remotely unlocking an encrypted hard disk

#71

I'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…

Sounds like you want ZFSBootMenu.org which offers remote SSH access with FDE in addition to snapshots in case of update falures or other issues. As long as you don't format the disk itself or wipe the ZFSBootMenu efi file you can recover and revert from anything remotely.

Re: Remotely unlocking an encrypted hard disk

#72
post #38
post #28

Earlier quoted context omitted.

Police show up and arrest you. Could be with reason, could be by accident. Maybe you did something wrong, maybe you didn’t. They also physically size your servers, and in doing so they unplug the system. If you have disk encryption, your data now requires the police to force you to produce a password, which may or may not be within their powers, depending on the jurisdiction. It’s strictly better to have full disk en…

>and in doing so they unplug the system. They have kits that allow them to unplug the server from the wall without interrupting power supply, specifically so they don't lose the decryption keys.

More reason to use encrypted memory like with AMD TSME and a deadman switch.

Re: Remotely unlocking an encrypted hard disk

#73
post #35
post #20

Earlier quoted context omitted.

How does this compare to: https://docs.redhat.com/en/documentation/red_hat_enterprise_...

(I am the other Mandos developer) I think FOSDEM had a talk a few years ago about that solution and their tang server. It is very similar in concept. They use McCallum-Relyea exchange, and we use PGP encryption, but the basics are the same in that you need information stored at the server and information stored in the unencrypted initramfs in order to be combined and turned into the encryption key. If my understandin…

clevis and tang do currently work seamlessly on Debian and Ubuntu using initramfs-tools. So while the initramfs-tools/dracut discussion is valid, it seems mostly orthogonal to this topic.

Re: Remotely unlocking an encrypted hard disk

#74
post #12

If you want to be able to reboot remotely, and non-interactively (i.e. while you sleep), I (and one other person) created Mandos for this purpose: https://www.recompile.se/mandos >. It gets the password over the network. If this seems insecure to you, read the FAQ: https://www.recompile.se/mandos/man/intro.8mandos > Mandos works with initramfs images created by both initramfs-tools and Dracut, and is present in Debia…

The kind of tool that I'm waiting for would allow me to log into a machine remotely, then reboot it once into a provided image (which could then run Linux in a ramdisk). I.e., take over the entire machine until it is restarted again. Does something like this exist?

I want something like "kexec" but taking over the entire hardware at the lowest possible level.

Edit, found this:

https://github.com/marcan/takeover.sh

But it's not as low level as I hoped, though it keeps the network running which is nice :)

Re: Remotely unlocking an encrypted hard disk

#75
post #29

I have a very similar setup to the author, but instead of running Tailscale in my initramfs, I have a Raspberry Pi sitting next to the home server (which is on my Tailscale network) and I use it like a bastion host. Process is something like: 1. SSH into the Pi 2. Issue the Wake-on-LAN packet to boot the server 3. Tunnel that server's SSH port to my laptop 4. SSH into the initramfs SSH server (I use TinySSH), enter t…

[dead]

Re: Remotely unlocking an encrypted hard disk

#76
post #38
post #28

Earlier quoted context omitted.

Police show up and arrest you. Could be with reason, could be by accident. Maybe you did something wrong, maybe you didn’t. They also physically size your servers, and in doing so they unplug the system. If you have disk encryption, your data now requires the police to force you to produce a password, which may or may not be within their powers, depending on the jurisdiction. It’s strictly better to have full disk en…

>and in doing so they unplug the system. They have kits that allow them to unplug the server from the wall without interrupting power supply, specifically so they don't lose the decryption keys.

Sure, but in reality I'm more interested in not letting any low paid tech dude in the DC access to my data just because it can pull a drive. Or someone who buys the server from the provider.

Re: Remotely unlocking an encrypted hard disk

#77

Earlier 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?

TPM will not unseal the key if you change kernel parameters. It's one of the PCRs.

You'll be dropped into "enter disk crypt password please" prompt.

Re: Remotely unlocking an encrypted hard disk

#78
post #69

Earlier quoted context omitted.

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.

https://news.ycombinator.com/item?id=45294440

The good news: macOS can unlock FDE over SSH.

The bad news: `The capability to unlock the data volume over SSH appeared in macOS 26 Tahoe.`

Re: Remotely unlocking an encrypted hard disk

#79
post #29

I have a very similar setup to the author, but instead of running Tailscale in my initramfs, I have a Raspberry Pi sitting next to the home server (which is on my Tailscale network) and I use it like a bastion host. Process is something like: 1. SSH into the Pi 2. Issue the Wake-on-LAN packet to boot the server 3. Tunnel that server's SSH port to my laptop 4. SSH into the initramfs SSH server (I use TinySSH), enter t…

It's not only more complicated, it also does not sound to me like it would scale. What do you do when you have N servers? Do you buy N raspis, or do you keep using one bastion host? How do you automate it when you sooner or later must (re-)deploy?

If you set this up once ("this" meaning adding networking, SSH and tailscale inside initramfs), you can just do the same thing for the next server you set up, and you don't have to worry about the failure of one node affecting the other(s).

Post reply on HN