Mounting SSH Keys in Docker Containers: Why and How to Use Volume Bind‑Mounts with the -i Flag

When you run security or compliance scans inside a Docker container, you often need to connect to remote hosts over SSH. A common pattern is to combine the -i option (to point to a private key) with one or more -v volume mounts that expose your local ~/.ssh directory and the current working directory to the container. This article explains why both are required, breaks down each part of the command, and provides practical guidance for using SSH keys safely and efficiently in Docker‑based DevSecOps workflows.

Table of Contents

1. Understanding the docker run command
2. Why mount ~/.ssh as a volume?
3. The role of the -i flag
4. Why two -v flags?
5. Step‑by‑step example
6. Best practices & security tips
7. Common questions

Understanding the docker run command

A typical invocation for running the InSpec Docker image against a remote server looks like this:

docker run --rm \
  -v ~/.ssh:/root/.ssh \
  -v $(pwd):/share \
  hysnsec/inspec exec https://github.com/dev-sec/linux-baseline.git \
  -t ssh://root@$DEPLOYMENT_SERVER \
  -i ~/.ssh/id_rsa \
  --chef-license accept

Why mount ~/.ssh as a volume?

1. Provides the full SSH configuration

The -i flag only points to a single private key file. Real‑world SSH setups often rely on additional files:

• ~/.ssh/config (host aliases, proxy commands, preferred algorithms)
• Known hosts file ~/.ssh/known_hosts (pre‑trusted fingerprints)
• Additional keys (id_ecdsa, id_ed25519, etc.)

Mounting the entire ~/.ssh directory makes all of these files available to the container, ensuring the SSH client inside Docker behaves exactly like the one on your host.

2. Keeps the path consistent

Inside the container the default user is root, whose home directory is /root. By mapping ~/.ssh to /root/.ssh, the container’s SSH client automatically finds the keys without needing to adjust environment variables or copy files manually.

3. Avoids copy‑and‑paste errors

If you only passed -i ~/.ssh/id_rsa, you would still need to copy the key into the container’s filesystem or set SSH_AUTH_SOCK. A bind‑mount is a single, declarative step that guarantees the key is present where the SSH client expects it.

The role of the -i flag

• Scope: Tells InSpec (or any underlying SSH client) which private key to use for authentication inside the container.
• Syntax: -i /path/to/key – the path is evaluated relative to the container’s filesystem.
• Why it still matters: Even though the whole .ssh directory is mounted, InSpec does not automatically select a key. Explicitly specifying -i removes ambiguity, especially when multiple keys exist.

Bottom line: -v ~/.ssh:/root/.ssh makes the key available; -i ~/.ssh/id_rsa tells the tool which key to use.

Why two -v flags?

Docker allows multiple volume bind‑mounts in a single docker run. Each -v maps a distinct host path to a distinct container path:

Using both mounts lets you interact with remote hosts (via SSH) and work with local test assets without copying them into the image.

Step‑by‑step example

1. Prepare your environment

   export DEPLOYMENT_SERVER=10.0.1.23
   cd ~/my-inspec-profiles   # Directory containing custom controls
   

2. Run the scan

   docker run --rm \
     -v ~/.ssh:/root/.ssh \
     -v $(pwd):/share \
     hysnsec/inspec exec https://github.com/dev-sec/linux-baseline.git \
     -t ssh://root@$DEPLOYMENT_SERVER \
     -i ~/.ssh/id_rsa \
     --chef-license accept
   

3. Inspect results
   The scan writes its report to standard output. If you want a file on the host, add a volume for a reports folder:

   -v $(pwd)/reports:/reports \
   ... \
   --reporter json:/reports/report.json
   

Best practices & security tips

• Least‑privilege keys: Use a dedicated SSH key with limited permissions (e.g., read‑only sudo) for scanning.
• Read‑only mount: Prevent accidental modification of host keys by mounting read‑only:

  -v ~/.ssh:/root/.ssh:ro
  

• Avoid embedding secrets in images: Never COPY ~/.ssh into a Dockerfile; always use bind‑mounts at runtime.
• Clean up: The --rm flag ensures the container disappears after the run, but the host’s key files remain untouched.
• Use SSH agent forwarding (advanced): If you prefer not to expose private keys, start the container with -v $SSH_AUTH_SOCK:/ssh-agent -e SSH_AUTH_SOCK=/ssh-agent and omit the -i flag.

Common Questions

Takeaway

Mounting ~/.ssh as a Docker volume supplies the container with all the SSH artefacts it needs, while the -i flag explicitly selects the private key for authentication. The second -v flag shares your local work directory, enabling seamless interaction between host and container. By following the best‑practice checklist above, you can run DevSecOps scans securely, reproducibly, and without exposing secret material inside Docker images.