WSLでハマったDocker + AnsibleのSSH接続問題 – FURYU Tech Blog

企業テック

こんにちは、ピクトリンク開発で運用保守を担当している藤本です。
前回の記事 DockerでAWS IAMユーザー管理を自動化しようとしたらハマった話
に続き、またまたハマってしまったお話を共有します。
今回は、WindowsのWSL環境で発生した問題です。

背景

バッチ管理はRundeckで行っており、定期的なバージョンアップはAnsibleで自動化しています。
しかし、開発メンバーのPC環境が異なるため、Ansibleのバージョン違いによるエラーが発生することがありました。

対応策として、AnsibleをDocker化しました。
ただし、SSHログインに必要な個人の設定は ~/.ssh/config をマウントする形にしています。

services:
  ansible_environment:
    build:
      context: .
      dockerfile: Dockerfile
    platform: linux/x86_64
    tty: true
    volumes:
      - type: bind
        source: ~/.ssh
        target: /root/.ssh

発生した問題

コンテナからRundeckサーバへのSSH接続時にエラーが発生しました。

環境 結果
Ubuntu 問題なく動作
Mac 問題なく動作
Windows WSL (Ubuntu) { "Failed to connect to the host via ssh: Bad owner or permissions on /root/.ssh/config", " unreachable": true }

最初は権限の問題だと思い、アクセス権限の調整を試しました。

chmod 600 ~/.ssh/config

しかし、WSL環境では解決せず、完全に混乱しました…。

原因

Dockerでマウントした ~/.ssh/config のオーナーがコンテナ内で不明なユーザーになっていたことが原因でした。

  • ローカルでは自分のユーザーがオーナー
  • コンテナ内では root ユーザーが期待されるが、マウントされたファイルのUIDが合わない
    → SSHはファイルの所有者と権限に敏感なのでエラーになる

解決方法

強引ではありますが、ローカルの~/.ssh/config のオーナーを root に変更すると動作しました。

sudo chown root:root ~/.ssh/config

ただし、この運用は推奨されません。

  • ローカルユーザーでの編集が面倒
  • 権限管理が複雑
  • 他の環境では問題なくてもWSL固有の挙動に依存する

学び

Dockerでのファイルマウントは環境依存に注意
WSLとUbuntuネイティブではファイルUID/GIDの扱いが異なるため、同じ設定でも動作が変わることがあります。

Ubuntuでは権限周りを自動で吸収してくれる部分がある
WSLではそれが効かないことに注意。

もし今後、WSL + Docker + SSHで同じような問題に直面した場合、ファイルマウントではなくDocker内に設定をコピーするなどの運用も検討すると安全です。




元の記事を確認する

格安SIMは「通信品質が良くないから安い」といまだに言われることがあるが現状を説明したい (1/2) 前の記事 ポルノ禁止の余波──グーグルがすべてのスマートフォン利用者に新たな警告 | Forbes JAPAN 公式サイト（フォーブス ジャパン） 次の記事

関連記事