Docker コンテナに SSH する方法（そして docker exec こそが本当の答えである理由）

手短に言うと

通常、Docker コンテナに直接 SSH することはありません ── ホストに SSH してから、docker exec でコンテナ内のシェルを開きます。コンテナはデフォルトで SSH サーバーを実行しません(そして基本的に実行すべきでもありません:イメージが肥大化し、攻撃対象領域が広がります)。ノートパソコンでもスマホでも標準的なパターンは同じです:ホストに SSH → docker exec -it <container> bash。本記事ではこの流れ、コンテナ内 SSH が正当となる例外、そしてよくあるエラーを扱います。

標準的な方法:SSH 経由の docker exec

# 1. SSH into the Docker host
ssh user@host

# 2. find the container
docker ps

# 3. open a shell inside it
docker exec -it mycontainer bash
# minimal images may not have bash:
docker exec -it mycontainer sh

これだけです ── コンテナ内に SSH サーバーがないまま、コンテナ内のシェルにいます。exit でホストに戻ります。単発のコマンドならシェルを開く必要すらありません:docker exec mycontainer cat /etc/nginx/nginx.conf。

誰もが遭遇する 2 つのエラー

• OCI runtime exec failed: "bash": executable file not found ── イメージに bash がありません(Alpine や distroless イメージ)。代わりに sh を使います。本当に最小限/distroless のイメージにはシェルがまったくないこともあります。
• container ... is not running ── exec は実行中のコンテナにしか効きません。docker ps -a を確認し、終了していたらまず docker logs mycontainer で理由を読みます。

Docker Compose の場合

docker compose exec api sh      # service name, not container name
docker compose logs -f api      # and the logs, while you're there

よりスマホ向きの Docker ワークフローはスマホから Docker を管理するを参照してください。

コンテナ内の SSH が実際に正当な場合

いくつかの実際のケースが存在します:コンテナ自体が SSH サービスである場合(git サーバー、sftp エンドポイント、ポート 2222 で公開する開発環境コンテナ)、または exec アクセスが利用できないプラットフォーム。その場合はイメージ内で sshd を実行し、ポートを公開し(-p 2222:22)、他のサーバーと同様に扱います:鍵認証のみ、root ログイン禁止。それ以外のすべてでは docker exec がよりシンプルで安全です。

スマホで、タイピングを減らして

コンテナ名や exec のフラグは、まさにスマホで入力するのが面倒な類のものです。役立つことが 2 つあります:docker ps / docker exec -it … sh をスニペットとして保存すること、そしてアシスタントに尋ねること ── 「postgres コンテナでシェルを開いて」 ── TermAI が、今いるホストに即した正確なコマンドを提案します(直近の出力が見えているので、前回の docker ps のコンテナ名を把握しています)。

よくある質問

Docker コンテナにはどうやって SSH しますか?
通常はしません ── Docker ホストに SSH してから docker exec -it container bash(または sh)を実行します。コンテナはデフォルトで SSH サーバーを実行しません。

なぜ docker exec が "bash: executable file not found" と言うのですか?
イメージに bash が含まれていません(Alpine でよくあります)。docker exec -it container sh を使います。

停止したコンテナに exec できますか?
いいえ ── exec には実行中のコンテナが必要です。docker logs で終了理由を確認するか、シェルをエントリポイントにした新しいコンテナを docker run してイメージを調べます。

コンテナに sshd をインストールすべきですか?
基本的にいいえ ── イメージを肥大化させ、攻撃対象領域を増やします。例外は、その目的が SSH サービスであるコンテナや、exec アクセスのないプラットフォームです。

クイックファクト

• 標準パターン:ホストに SSH → docker exec -it <name> bash(または sh)
• bash がない? Alpine/最小イメージ:sh を使う
• 実行されていない? exec には生きたコンテナが必要 ── まず docker logs
• コンテナ内の sshd:コンテナの役割が SSH サービスである場合に限る