SSH Key Management in the DevSecOps Box – How It Works, Where It’s Configured, and What You Need to Know

Managing SSH keys is a core part of any DevSecOps lab. In the DevSecOps Box you can connect to the production environment without specifying a key file each time, and you may wonder why this works, where the configuration lives, and what tools like ssh-agent and ssh-add actually do. This article breaks down the mechanics, points you to the relevant files, and provides practical tips for customizing the setup for your own labs.

Table of Contents

1. Why the DevSecOps Box Can SSH to Production Without Extra Flags
2. Where the Private Key Is Stored
3. How SSH Chooses the Correct Key for a Host
4. Configuring Your Own Key Pair
5. The Role of ssh-agent and ssh-add
6. Common Questions & Quick Tips

Why the DevSecOps Box Can SSH to Production Without Extra Flags

The lab is deliberately pre‑configured so that the root user on the DevSecOps Box already possesses a private key that matches a public key stored on the production host. When you run a plain ssh prod‑host, OpenSSH automatically looks for a private key in the default location (~/.ssh/id_rsa). Because the matching key is present, authentication succeeds without the -i /path/to/key option.

Key point: As long as the private key exists at /root/.ssh/id_rsa, the box can reach the production machine. Delete or replace that file and the password‑less login will stop working.

Where the Private Key Is Stored

If you inspect the box:

# Show the private key (redacted for security)
cat /root/.ssh/id_rsa
# Verify the public key that the prod host trusts
ssh prod-host "cat /root/.ssh/authorized_keys"

Removing /root/.ssh/id_rsa breaks the automatic login.

How SSH Chooses the Correct Key for a Host

OpenSSH follows a simple lookup order:

1. Explicit key via -i flag – overrides everything else.
2. Keys listed in ~/.ssh/config under a Host stanza (e.g., IdentityFile).
3. Default key files (~/.ssh/id_rsa, id_ecdsa, id_ed25519, …).

In the DevSecOps Box there is no custom ~/.ssh/config; the system relies on step 3. When you first connect to a new host, SSH asks you to confirm the host’s fingerprint (the “host verification” prompt). After you accept, the connection proceeds, and the remote SSH daemon checks whether the presented public key (derived from the private key you offered) appears in its authorized_keys file.

If you need a per‑host key mapping, create a config file:

cat > /root/.ssh/config <<'EOF'
Host prod
    HostName 10.0.0.5
    User root
    IdentityFile /root/.ssh/prod_id_rsa
EOF
chmod 600 /root/.ssh/config

Now ssh prod will automatically use /root/.ssh/prod_id_rsa.

Configuring Your Own Key Pair

1. Generate a new RSA (or Ed25519) key pair

   ssh-keygen -t rsa -b 4096 -f /root/.ssh/my_lab_key -N ""   # -N "" = no passphrase
   

2. Copy the public key to the remote host

   ssh-copy-id -i /root/.ssh/my_lab_key.pub root@prod-host
   

   or manually append the key to /root/.ssh/authorized_keys on the remote side.

3. Tell SSH which key to use (optional but recommended for multiple keys)

   echo -e "Host prod\n    IdentityFile /root/.ssh/my_lab_key" >> /root/.ssh/config
   chmod 600 /root/.ssh/config
   

Now you can connect with ssh prod just as before, but the lab uses your own credentials.

The Role of ssh-agent and ssh-add

• ssh-agent is a background process that holds private keys in memory, allowing you to use them without re‑entering a passphrase for each connection.

• ssh-add loads a private key into the running agent:

  eval "$(ssh-agent -s)"      # start the agent
  ssh-add /root/.ssh/my_lab_key
  

In CI pipelines (e.g., GitLab CI) you’ll often see a snippet like:

before_script:
  - mkdir -p ~/.ssh
  - echo "$DEPLOYMENT_SERVER_SSH_PRIVKEY" | tr -d '\r' > ~/.ssh/id_rsa
  - chmod 600 ~/.ssh/id_rsa
  - eval "$(ssh-agent -s)"
  - ssh-add ~/.ssh/id_rsa

This sequence creates the key file from a protected variable, starts an agent, and adds the key so subsequent ssh or scp commands run without interactive prompts.

Bottom line: In the DevSecOps Box you don’t need ssh-agent for the default key because the key is unencrypted and stored at the default location. You only need an agent when the key is passphrase‑protected or when you want to manage multiple keys securely.

Common Questions & Quick Tips

TL;DR

• The DevSecOps Box authenticates to production using the default private key at /root/.ssh/id_rsa.
• No explicit configuration file is required; OpenSSH falls back to this default location.
• To use a different key or multiple hosts, create a ~/.ssh/config file with IdentityFile directives.
• ssh-agent and ssh-add are only needed for passphrase‑protected keys or when you want to avoid typing passwords repeatedly.

With this knowledge you can safely modify the lab’s SSH setup, add your own keys, and understand exactly how authentication works under the hood. Happy securing!