Notifications
Clear all
Topic starter
08/06/2026 5:01 pm
TL;DR: Installing SSH inside a container usually adds unnecessary overhead and expands the attack surface, according to StrongDM’s tutorial on how to execute commands in Docker containers with docker run and docker exec. For IAM and platform teams, the takeaway is that container access should stay scoped to the task, not to a persistent login pattern.
NHIMG editorial — based on content published by StrongDM: How to SSH into Docker Containers [Tutorial]
Questions worth separating out
Q: How should teams access Docker containers without creating unnecessary SSH exposure?
A: Use Docker-native commands such as docker run and docker exec for routine administration.
Q: When does SSH inside a container become a governance problem?
A: SSH becomes a governance problem when it turns a disposable workload into a persistent remote administration target.
Q: What do teams get wrong about container debug access?
A: They often treat convenience as if it were neutral.
Practitioner guidance
- Prefer Docker-native command execution first Use docker run and docker exec for routine troubleshooting so operators do not create a separate SSH-based administration path for every container.
- Treat container SSH as an exception If an OpenSSH server is installed in a container, document the business reason, the approval path, and the conditions for removal.
- Restrict IP-based container access paths If teams use docker inspect to connect directly by container IP, constrain that access to tightly controlled troubleshooting windows and dedicated network segments.
What's in the full article
StrongDM's full tutorial covers the operational detail this post intentionally leaves for the source:
- Command-by-command examples for running an interactive shell with docker run and reconnecting with docker exec
- The exact Dockerfile changes used to install and enable OpenSSH inside a container
- A concrete example of using docker inspect to retrieve the container IP for direct SSH access
- The article's own stepwise explanation of when SSH adds overhead versus when it may be justified
👉 Read StrongDM's tutorial on SSH access patterns for Docker containers →
Docker containers and SSH access: are your controls adding scope?
Explore further
08/06/2026 6:58 pm
Container SSH is usually a scope-expansion decision, not an access improvement. The article frames SSH as an option, but from an identity governance perspective it moves the container away from its intended minimal trust model. The practical question is not whether SSH works, but whether the workload should ever be granted a persistent login surface at all. That distinction matters because scope grows faster than most teams review it.
A few things that frame the scale:
- 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
- Public secret exposure is not rare in adjacent DevOps workflows, with 15% of commit authors having leaked at least one secret in their contribution history.
A question worth separating out:
Q: What is the difference between Docker exec and SSH for container administration?
A: Docker exec attaches a command session through Docker’s control plane, while SSH creates a separate remote shell service inside the container. The first preserves the workload’s minimal design, while the second adds a durable access path that should be justified and governed separately.
👉 Read our full editorial: Docker container access patterns expose the scope tradeoff of SSH
