# Entering Password on a System with Full Disk Encryption

## tuber

For those running a system with full disk encryption, how do you deal with entering the encryption password remotely? I'm thinking about cases like when there is a temporary power failure, and you can't get to the console immediately.

----------

## cach0rr0

I can't/don't

lacking physical access to a machine negates the security of crypto anyway (cryo makes plucking a key from a running system's memory much easier!)

but that's neither here nor there - if i were to have this requirement, I'd likely be forced to let the kernel set an address via dhcp, AND, have a peek at the remote_rescue_shell here:

http://resources.infosecinstitute.com/luks-and-initramfs/

----------

## eccerr0r

I was wondering about this, and was one of the reasons why I didn't really want full disk encryption in case there was an unintended reboot.  I'd probably end up keeping a skeleton root on an unencrypted disk and the rest on an encrypted volume...  That way the machine will always boot enough that you can login with root or something, and start up the rest of the volumes.

But anyway it'll be a mess especially if you start daemons in initrd.  Likely you'll have to kill them (actually, have the initrd kill them when you close the shell) else there will be open descriptors on the initrd when switch_root occurs.  But then if it subsequently fails, then it'll be very stuck indeed requiring a reset button push.

----------

## tuber

The remote_rescue_shell would be cool if it used an SSH server instead of a Telnet server. One option that I was thinking of, was to hook up the main server's serial console to another machine. Perhaps a VPN server on a Pogoplug or something. So if I had to remotely access a rebooted server, I would login to the VPN server, fire up minicom, and then enter the password on the server's serial console.

----------

## luckylinux

Some KVM over IP solution (like Supermicro IPMI for instance) or maybe Dropbear SSH to enter LUKS passphrase via SSH? I use the first one - although if you can manage to setup Dropbear SSH into your initrd as it should I don't see problems with it (except security, of course).

----------

## tuber

Dropbear sounds like it would work just fine. Why is it a security concern?

----------

## luckylinux

 *tuber wrote:*   

> Dropbear sounds like it would work just fine. Why is it a security concern?

 

Well, depending on how critical your server is, I don't think remote SSHing as root is a good practice. SSHing as root is never a good practice (though I think you have to do so to unlock LUKS encrypted devices/partitions).

Someone more knowledgeable than me will probably give you a more in-deep answer.

----------

## frostschutz

 *tuber wrote:*   

> For those running a system with full disk encryption, how do you deal with entering the encryption password remotely?

 

I do a magic packet exchange consisting of local and shared secrets xor'd with random data, which is not secure at all. It beats telnet (unencrypted), and it doesn't simply allow the packet to be reused, nor does it actually contain the key by itself. But it's still vulnerable (a man in the middle could probably produce the correct reply using xor himself, if he listened to a successful exchange once). I only did it because it was simple (using busybox netcat in the initramfs) and the box is in the local network so ...  :Laughing: 

The question is how secure do you need it to be, considering that all they have to do is shut down your box and modify your Initramfs to get the key?

----------

