The risk of unprotected private keys


Categories: Architecture Tags: docker private-key

There have been numerous occations where I’ve heard the following expression: “…yeah my stuff is safe on my computer, no need to have additional encryption, or special administrative accounts…”.

Well yeah, sure, if you say so.

Let that sink in as a intro. An old laptop I was using for testing stopped working and wouldn’t start anymore. So I decided to take out the disk and retrieve the data I had laying in there. For everyone else, getting data out would be impossible. For me, the good thing was that I had Linux running on it and the disk was encrypted with LUKS (Linux Unified Key Setup), meaning that only I, with the decryption password, could access the enclosing data (by no means I consider myself as a cryptography expert, I just use common sense and best practices).

While copying some files, I remembered that I had an ssh key setup for accessing a VPS I used for testing. In that moment, an interesting idea popped into my head!

What if I build a specific Docker image with some tools and load up the private key into it. I would be able to access the VPS and run some commands. Stopping the Docker image, the private key is unloaded thus the image is kept in it’s original state.

Of course I had to try this :)

Since Docker images are not like virtual machines (well they are and aren’t) an idle image will just exit as soon as you try to start it. But if you run it while logging into it, the process will be running untill you exit.

In order to demonstrate my experiment, I’ve created a Dockerfile, built the image and ran it while logging into it.

Here is a demonstration Dockerfile (I’ve stripped down the file for this demonstration, after all, this is not a hacking tutorial. Feel free to enrich the image with various tools if needed)

FROM ubuntu:latest 
RUN apt update && apt install -y 

And then build the image in the terminal.

$ docker build -t myImage:v1 .

To make it convenient, the following bash script runs the image and loads the key from ~/ into the root directory as read-only.
docker run -it -v ~/old_id_rsa:/root/.accessKey:ro myImage:v1

Now what’s missing is the information on the server the key was used on. Again scanning the disk, and some luck, it wasn’t that hard to find.
What’s left is to ssh into the remote VPS and be “nice”.

$ ssh -i <private key filename> <user@hostname>

As closing thoughts, the more you make it difficult for someone with your private stuff, the more piece of mind you’ll have in the long run. Since almost everything is scanned/scraped/copied etc. by different sevices, take a look at some convenient encryption solutions. They’re not that complicated these days. Some renowned ones: LUKS *nix only, Cryptomator and borg.

“Security is a process, not a product.” - Bruce Schneier