4

I have at my workstation, an ubuntu 14.04 installation with full disk encryption. I now have to travel frequently for days and am planning to ssh into this machine from my chromebook to work remotely.

I don't have any guarantee that this machine will never be shut down(the cleaning staff may do so). On rebooting the system asks for encryption password everytime while booting up, which I guess will not be possible to do remotely (as I believe the networks and especially sshd will start only after reading the encrypted disk/booting). How can I tackle with this situation? Is it possible to continue with the encrypted HDD? Or if not, how can I remove HDD encryption (if possible, which I doubt)

2

You can use dropbear ssh to ssh to your machine and then unlock the LUKS volume. There's a tutorial here which can assist you with setting up.

1

The easiest solution would be to have installed your server so it can (minimally) boot without a passcode, either by not having it encrypted, or by using some kind of hardware key, like a USB stick, that has the data necessary for the system to automatically boot. That way, you can "lock" the server by powering it off and walking away with the USB key. IIRC, TrueCrypt (and presumably therefore VeraCrypt, the still-active fork of TrueCrypt) supports using arbitrary files on USB sticks as passcodes.

That's merely the base level. Once the system is up and running (and online), you can SSH in and manually unlock the server's encrypted storage.

In order to get to this kind of setup, you'd have to back up your data, repartition your disk(s) and reinitialize your filesystem(s), then restore your data atop the new filesystem(s). Then you'd need to create the encrypted (or, if you're using a hardware key, the double-encrypted) area(s) and symlink to them from the various locations you've already got configured for use.

 

If you're encrypting home directories, note that SSH pubkeys stored in each user's ~/.ssh/authorized_keys file will be unavailable to authenticate users that are not logged in. To fix this, assuming you're using ecryptfs-mount-home, tell your users to run ecryptfs-umount-private and then install their pubkeys into the unencrypted ~/.ssh/authorzied_keys file (which may require creating ~/.ssh – don't forget to chmod 700 ~/.ssh or it won't work!).

Alternatively, you could add something like this to your /etc/ssh/sshd_config file:

AuthorizedKeysFile .ssh/authorized_keys /var/ssh/%u/authorized_keys

This would require you to create (and chown and chmod) the appropriate /var/ssh/<user> directories since users won't be able to do that. Now users can have two authorized_keys files (or else the user can run ln -s /var/ssh/$USER/authorized_keys ~/.ssh/authorized_keys to link them).

 

Remember, if you're logged in, your data is vulnerable. If an attacker powers off your system and brings it back up with a boot disk, they can gain root access. Then you log in remotely and unlock things, so the attacker then has access to those things. Encrypting your home directory is a great idea, but for things like tax returns and other sensitive documents, you're better off using a special dedicated space that is mounted only as long as its content is needed. These are not mutually exclusive; I suggest doing both.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.