Mastering Docker Exec: Securely Accessing Your Containers without Traditional SSH

Longstanding habit: spin up a VM, deploy OpenSSH, and connect via ssh user@host. In the Docker era, this pattern drags along unnecessary baggage—attack surface, resource usage, and configuration complexity.

With containers, the right approach is simpler: use Docker’s integrated tooling to access the running environment directly. Installing an SSH server into every image not only bloats your images, it introduces a persistent service that serves no architectural purpose in stateless workloads.

Why Not SSH?

A quick comparison:

Attack Vectors: Each SSH daemon is a listening entry point. Vulnerabilities—see CVE-2023-48795—can be targeted on misconfigured images.

Image drift: Adding SSH often drags in PAM, various config files, keys, and, inevitably, one-off debug hacks. Auditing and keeping an image minimal becomes error-prone.

Ephemeral principle: A containerized workload should be throwaway, reproducible, and atomic.

docker exec in Practice

No SSH keys to manage, no daemons to patch. Just direct command execution inside namespaces.

Typical use:

docker exec -it <container_name_or_id> /bin/bash

• Optionally fall back to /bin/sh for Alpine-based or minimized images:

docker exec -it <container_name_or_id> /bin/sh

If your image ships without a shell (common for scratch-distroless builds), you’ll need a purpose-built debug image instead—more on that below.

Identify Running Containers

docker ps

Example output:

CONTAINER ID   IMAGE          COMMAND                  CREATED         STATUS         PORTS                  NAMES
a2ffd73ac384   nginx:1.25.0   "/docker-entrypoint.…"  41 seconds ago  Up 41 seconds  0.0.0.0:8080->80/tcp   webserver

If the target isn’t obvious, filter by image or label:

docker ps --filter ancestor=nginx:1.25.0

Inspect and Debug In-Place

Container behaving erratically? Access the running shell with docker exec:

docker exec -it webserver /bin/bash

You’re dropped inside the environment with PID namespace and filesystem access:

root@a2ffd73ac384:/#

Check running processes:

ps aux

View active config:

cat /etc/nginx/nginx.conf

Network debugging often comes up—tools like ping or curl may not be bundled. Sometimes a minimal image forces you to use preinstalled binaries or mount utility volumes as a workaround.

Execute as Specific User

By default, docker exec operates as root (or container's default user). For restrictive images:

docker exec -it -u www-data webserver /bin/bash

Practical when investigating file permissions or testing application as a non-root user.

Known issue:

Running as a non-root user may yield:

the input device is not a TTY

Workaround: ensure the user has a valid shell and /bin/bash exists for that UID.

One-Off Commands

No need to launch a full shell for single checks:

docker exec webserver cat /proc/cpuinfo
docker exec webserver env | grep HOSTNAME

This minimizes session footprint, avoids unwanted process trees.

Advanced: Temporary Debug Containers

Production images regularly exclude shell and debugging tools for attack surface minimization. Inject auxiliary toolsets via an ephemeral debug container:

docker run --rm -it --network container:webserver --pid container:webserver --volumes-from webserver alpine:3.18 sh

Now you can poke into filesystems, network namespaces, and even run apk add tcpdump inside the context of the running workload, without contaminating the base image.

Note: Not all orchestrators (e.g., ECS) allow this pattern. Kubernetes has kubectl debug, which provides similar functionality with correct RBAC and admission controls.

Gotchas

• docker exec may hang or not return if the main process is deadlocked or the container is in OOM state.
• The exit code from docker exec will mirror the inner command—it’s trivial, but easily misinterpreted in automation.
• If containers restart rapidly (e.g., due to a SIGSEGV), exec sessions will disconnect mid-operation.

Security & Workflow Tips

• Never expose SSH ports (22/tcp) inside a container in production unless absolutely required; audit with docker ps --format '{{.Names}}: {{.Ports}}'.
• Rotate debug images, keeping them in separate registries. Avoid pushing production images with bundled shells or extra binaries.
• For debugging live but immutable containers, prefer tooling like nsenter (Linux) or container orchestrator-native commands.

Summary

If your workflow still includes installing and maintaining SSH inside container images, it’s overdue for a rework. Use docker exec—it better matches the philosophy of stateless, disposable workloads, and sharply reduces attack surface. In environments where exec is insufficient, leverage debug containers, not SSH daemons. For those running distroless or minimal images: maintain a toolbox image for emergencies, mounted with just-in-time access.

For reference:

• Best practices for writing Dockerfiles (official)
• Distroless debugging guide

Written by an engineer deploying stateless workloads since Docker 1.9. Sometimes, the best SSH connection is none at all.