No keys by default

Posted: 2017-02-25 | Updated: 2017-12-08

I've recently decided to stick an SSD into an old Thinkpad T61 I have in an effort to make using it less painful. With a spinning disk, the age of the CPU really showed, but with an SSD it's back to being a total joy to use. This machine was my main driver for several years and it's great to refresh it again, and I've decided to try something new with my various secure keys this time. On this machine, there are no GPG, SSH, or VPN keys at all; those exist on a LUKS-encrypted flash drive which I mount and unlock as needed. This is technically more secure than just keeping said files on disk unencrypted at all times, and sounds pretty good I suppose, but is it actually a huge pain in the ass? Read on!

An encrypted USB drive

→ An encrypted USB drive

I've got a bunch of USB flash drives lying around from over the years, ranging from 1 to 32 GBs. For this I went with one of my spare 4GB drives, even though thus far I've not utilized anywhere near that much space. Whatever you choose, format it and then set it up as a LUKS-encrypted device via the cryptsetup utility, or there are various GUIs out there that work as well. Once the LUKS aspect is done, you then set up a filesystem like you'd do with any non-encrypted drive. When the drive is usable, unlock and mount it as both a trial and an opportunity to put some keys on it.

My goal is to not have any secure files kept on my laptop's hard drive unencrypted. Specifically, this means SSH and VPN keys. Once these are created and stored on the USB drive, I just make a symlink to them like so:

$ ln -s /run/media/$username/$drivename/ssh $HOME/.ssh

And so on, for each item I'm keeping on the USB drive. This works out so that when I've locked and removed the USB drive, I'm left with dead symlinks. Reattach the USB drive, unlock it, and the links spring to life and point to the secured keys on the drive. There's a couple of boilerplate commands that I've worked out into a shell script just because they must be run each time the drive is locked or unlocked:

# Unlock and mount the drive:
$ udisksctl unlock -b /dev/sdb
$ udisksctl mount -b /dev/dm-0  # adjust the device name as needed.

# Add SSH keys to ssh-agent:
$ ssh-add ${HOME}/.ssh/id_ed25519
$ ssh-add ${HOME}/.ssh/id_rsa

# Enable my VPN connection:
$ sudo sv-enable openvpn-client

With that, I'm ready to do business. Everything works like I've got the keys on disk (because, I technically do now.) I have occasional issues with Emacs wanting my SSH key passwords, even though the agent is loaded and working otherwise, but that's no big deal ultimately. When I'm done with all the serious business that requires keys and VPNs and whatnot, I've got the below "clean up" routine:

# Delete ssh-agent identities:
$ ssh-add -D

# Disable my VPN connection:
$ sudo sv-disable openvpn-client

# Make sure all files on the USB drive are closed, and unmount it:
$ udisksctl unmount -b /dev/dm-0  # adjust the device name as needed.

# Lock the drive:
$ udisksctl lock -b /dev/sdb

And that's it - with the drive unmounted and locked its contents will not be viewable until it is once again unlocked and mounted. From here I can continue to do anything else with the laptop that doesn't require the now-gone keys. I've been using this setup for a few weeks on the machine (that is again a secondary machine) and it's worked out really well, but the real question remains on how it would be for my primary setup. I see myself potentially making the jump in the next few months, but we shall see!