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.
Editorial analysis by NHI Mgmt Group, based on content published by StrongDM: “How to SSH into Docker Containers [Tutorial]”.
Key questions
Q: What breaks when teams rely on SSH as the normal way to access Docker containers?
A: The container becomes harder to operate as a container and easier to mismanage like a server.
Q: Why does running SSH inside a container usually create more risk than it removes?
A: SSH inside a container adds another service, another attack surface, and another credential path to manage.
Q: How should platform teams decide whether a container needs SSH at all?
A: Start from the operational goal and ask whether the same outcome can be achieved with docker run or docker exec.
Practitioner guidance
- Prefer native Docker command execution Standardise docker run and docker exec for routine interactive operations so operators use the container's built-in execution path instead of a separate login service.
- Avoid installing SSH by default Treat OpenSSH as an exception that requires an explicit operational justification, because it adds packages, services, and a persistent access surface to the image.
- Review container access scope Check whether each container has become reachable through a standing administrative path that is broader than the task it is meant to perform.
Bottom line: Docker containers are intended to stay minimal, so adding SSH often changes the access model more than it changes the operator experience.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
08/06/2026 6:58 pm
SSH inside a container is an access-scope decision, not just an administration preference. The article makes the core tradeoff plain: docker exec already supports shell-like operations without adding a daemon and network service. Once SSH is installed, the container is no longer only a workload with command access, it becomes a remotely accessible login target. For identity teams, that changes the control boundary from task execution to standing access surface.
A few things that frame the scale:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
A question worth separating out:
Q: What should teams do when a container already has a standing login path?
A: Reassess the container's purpose, exposed services, and access boundaries, then determine whether the login path is actually required for support or whether it reflects inherited server habits. If it is not required, remove it and return the workload to a minimal, task-bound execution model.
👉 Read our full editorial: Docker container access patterns expose the scope tradeoff of SSH