Home Technical Support SSH Key Management & Authentication Agent: A Complete Guide for DevSecOps Learners

SSH Key Management & Authentication Agent: A Complete Guide for DevSecOps Learners

Last updated on Jan 26, 2026

SSH Key Management & Authentication Agent: A Complete Guide for DevSecOps Learners

Managing SSH keys securely is a core skill for anyone working in DevSecOps. This article explains why you add keys to known_hosts, what the ssh-add command does, how the SSH authentication agent works, and where its configuration lives. By the end of the guide you’ll be able to set up and use SSH keys confidently in labs, real‑world projects, and certification exams.

Table of Contents

  1. Why Add Your Public Key to known_hosts?

  2. Understanding the ssh-add Command

  3. The SSH Authentication Agent Explained

  4. Practical Walk‑through: From Key Generation to Connection

  5. Tips & Common Questions

Why Add Your Public Key to known_hosts?

When you SSH to a server for the first time, SSH stores the server’s host key in ~/.ssh/known_hosts. This file acts as a fingerprint that tells your client, “I have connected to this exact server before; if the fingerprint changes, something is wrong.”

Adding your own public key

In many DevSecOps labs you are asked to run a command such as:

ssh-keyscan -t rsa devsecops-box-p29i9pmx >> ~/.ssh/known_hosts

Even though the command uses your own machine’s hostname, the same security principle applies:

Reason What Happens
Man‑in‑the‑Middle (MITM) protection The client verifies the server’s host key against the entry in known_hosts. If an attacker tries to impersonate the server, the fingerprint won’t match and the connection is aborted.
Predictable environment Labs often spin up fresh VMs. Adding the host key manually guarantees that the client trusts the exact instance you intend to use, avoiding the “Are you sure you want to continue connecting (yes/no)?” prompt.
Automation friendliness Scripts that run non‑interactive SSH commands (e.g., scp, ansible) need a pre‑populated known_hosts to avoid hanging for user input.

Bottom line: Adding the host’s public key to known_hosts is a verification step, not a way to “give the server access to you.” It assures you are talking to the right server.

For a deeper dive, see the SSH Academy article on Known Host Keys.

Understanding the ssh-add Command

ssh-add works with the SSH authentication agent (often ssh-agent). Its purpose is to load private keys into the agent so you don’t have to type a passphrase for each new SSH connection.

What ssh-add does

  1. Reads a private key (default is ~/.ssh/id_rsa if you run ssh-add without arguments).

  2. Prompts for the key’s passphrase (if the key is encrypted).

  3. Stores the decrypted key in memory inside the running ssh-agent.

  4. Makes the key available to any SSH client that contacts the agent during the same session.

Typical usage patterns

# Start an agent (most shells do this automatically)
eval "$(ssh-agent -s)"

# Add the default key
ssh-add          # prompts for passphrase if needed

# Add a specific key
ssh-add ~/.ssh/ci_deploy_rsa

# List keys currently loaded
ssh-add -l

# Remove all keys (useful before switching projects)
ssh-add -D

Why use ssh-add?

  • Convenience: One passphrase entry per session, not per connection.

  • Security: Private keys never touch the disk after being loaded; they stay in the agent’s protected memory.

  • Automation: CI/CD pipelines can load keys once and then run many Git or remote‑exec commands without interactive prompts.

The SSH Authentication Agent Explained

ssh-agent is a background daemon that holds your decrypted private keys and supplies them to SSH clients on demand.

Core responsibilities

  • Key storage: Keeps private keys in memory, encrypted with the user’s login credentials.

  • Signing requests: When a remote server challenges you, the agent signs the challenge with the appropriate private key and returns the signature.

  • Key selection: If multiple keys are loaded, the agent can try them sequentially or based on the IdentitiesOnly option.

Where is the agent’s configuration stored?

The agent itself does not have a persistent configuration file. Instead, you control its behavior through:

File Purpose
~/.ssh/config Per‑host or global SSH client settings (e.g., AddKeysToAgent yes, IdentityFile ~/.ssh/id_rsa).
Environment variables SSH_AUTH_SOCK points to the Unix socket the agent listens on; SSH_AGENT_PID holds the process ID.
Shell startup scripts (~/.bashrc, ~/.zshrc) Often contain eval "$(ssh-agent -s)" and ssh-add commands to start the agent automatically.

Example ~/.ssh/config snippet:

Host *
    AddKeysToAgent yes
    UseKeychain yes          # macOS only – stores passphrase in the system keychain
    IdentityFile ~/.ssh/id_rsa

Practical Walk‑through: From Key Generation to Connection

Below is a step‑by‑step example that mirrors a typical DevSecOps lab.

  1. Generate a new key pair (skip if you already have one).

    ssh-keygen -t rsa -b 4096 -C "student@example.com"
# Accept default location (~/.ssh/id_rsa) and set a strong passphrase.

  2. Add the server’s host key to known_hosts.

    ssh-keyscan -t rsa devsecops-box-p29i9pmx >> ~/.ssh/known_hosts

  3. Start the authentication agent (if not already running).

    eval "$(ssh-agent -s)"

  4. Load your private key into the agent.

    ssh-add ~/.ssh/id_rsa

  5. Connect to the lab machine.

    ssh devsecops@devsecops-box-p29i9pmx

    Because the host key is already trusted and the private key is cached in the agent, the connection proceeds without any further prompts.

  6. Optional: Verify the loaded keys.

    ssh-add -l   # shows fingerprints of keys held by the agent

Tips & Common Questions

✅ Tips for Smooth SSH Workflows

  • Add keys automatically: Include AddKeysToAgent yes in ~/.ssh/config so ssh adds a key to the agent the first time you use it.

  • Use the macOS Keychain: On macOS, UseKeychain yes stores the passphrase securely and reloads it after reboots.

  • Limit known_hosts size: Periodically prune stale entries with ssh-keygen -R hostname.

  • Forward the agent when needed: Use ssh -A or set ForwardAgent yes in the config to let remote hosts use your local keys (use with caution).

❓ Frequently Asked Questions

Question Answer
Do I need to add my public key to known_hosts? No. known_hosts stores host keys, not your public key. The command ssh-keyscan fetches the server’s host key and appends it.
What if I forget to start ssh-agent? SSH will fall back to asking for the key’s passphrase each time. Run eval "$(ssh-agent -s)" and ssh-add to fix it.
Can I store the agent’s socket in a custom location? Yes—set SSH_AUTH_SOCK=/tmp/custom_agent.sock before launching ssh-agent. This is useful for containerized environments.
Is ssh-add -D safe to run? It removes all keys from the current agent session. It’s safe, but you’ll need to re‑add any keys you still need.
Why does ssh-add sometimes say “Could not open a connection to your authentication agent”? The environment variable SSH_AUTH_SOCK is missing or points to a dead socket. Start a new agent with eval "$(ssh-agent -s)".
**how is the devsecops-box machine always able to ssh into prod for example? I killed the ssh-agent on the devsecops-box and it can still auth to prod ** It's because we have designed the lab to store the production machine by default, and as long as the private key is there, you will be able to SSH into the production machine. In our DevSecOps Box, there is a private key stored at /root/.ssh/id_rsa. This key is being used to SSH into the production machine. If you remove that private key from /root/.ssh/, you will no longer be able to SSH into the production machine. **

Wrap‑Up

Effective SSH key management hinges on three pillars:

  1. Trust the server – populate known_hosts with verified host keys.

  2. Securely store private keys – load them once into ssh-agent using ssh-add.

  3. Configure the client – use ~/.ssh/config to automate agent usage and key selection.

By following the steps and best practices outlined above, you’ll reduce friction in labs, avoid common security pitfalls, and be ready for any DevSecOps certification exam that tests SSH proficiency. Happy secure connecting!