🔐

WSL で 1Password SSH Agent を使うときの注意点 (2025/8版)

に公開

はじめに

WSL 環境で GitHub に SSH 接続する際、1Password の SSH Agent を使うと便利ですが、設定を誤ると「エージェントが利用されず、直接鍵ファイルの入力を求められる」「Permission denied」などのトラブルになります。ここでは、迷走しがちなポイントと解決方法をまとめます。筆者があまり仕組みを理解せずにカオスな設定をしてしまった後のトラブルシューティングなので、同じ事象になっている人は少ないかもしれません…

検証環境

Windows ホスト:

  • Microsoft Windows 11 Home (Build 26100)
  • アーキテクチャ: 64 ビット

WSL 環境:

  • Ubuntu 22.04.4 LTS (jammy)
  • 1Password for Windows (SSH Agent 機能有効)

トラブルの原因

WSL の ssh と Windows の ssh を混同

  • alias ssh=ssh.exe のように Windows の ssh を強制利用すると、WSL 内の SSH_AUTH_SOCK を無視してしまう。
  • その結果、1Password のエージェントに接続できず、鍵ファイルの直接入力を求められる。

core.sshCommand を git config に設定していた

  • git config --global core.sshCommand ssh.exe のような設定があると、Git 操作時に Windows ssh が必ず使われる。
  • これも WSL の ssh-agent 経由の認証をバイパスしてしまう。

解決のポイント

1. WSL の ssh をそのまま使う

  • alias ssh=ssh.exe は不要。WSL 側の /usr/bin/ssh を使う。

2. core.sshCommand を削除する

git config --global --unset core.sshCommand

3. 1Password 側で Windows OpenSSH Agent 連携を有効化

  • 1Password の設定 → Developer → "Integrate with SSH agent" をオン。
  • これで Windows の ssh-agent に鍵が登録される。

4. WSL 側の ssh が Windows のエージェントを認識

  • 特別な socatnpiperelay 設定は不要。
  • /mnt/c/Users/<username>/.ssh/config に以下を追加すれば十分:
Host github.com
  HostName github.com
  User git
  IdentityAgent \\.\pipe\openssh-ssh-agent
  IdentitiesOnly yes

動作確認手順

ssh -T git@github.com
# Hi <username>! You've successfully authenticated, but GitHub does not provide shell access.
git fetch   # パスフレーズを聞かれず成功する

接続フロー図(推奨方法)

この図は上記の「解決のポイント」で説明した推奨方法を表しています。socatやnpiperelayは不要で、WSLのsshが直接Windows側のOpenSSH Agentに接続します。


まとめ

  • 混乱の原因は「WSL ssh」と「Windows ssh」を混ぜて使っていたこと。
  • 正しい解決策は WSL 側の ssh を素直に使い、Windows 側の OpenSSH Agent(1Password 経由)にブリッジすること。
  • 余計な socat や alias 設定は不要。シンプルにした方が安定する。

筆者の環境では、core.sshCommand の削除と alias ssh=ssh.exe を外すだけで解決しました。 複雑な socat/npiperelay 設定は一切不要で、IdentityAgent を指定する方法だけで正常に動作しています。


詳細アーキテクチャ図

1) 従来の方法: Linux ssh + npiperelay/socat

ポイント: Linux の ssh を使い、socat + npiperelay が Windows の 1Password エージェントへ橋渡しする。


2) 代替: Windows ssh.exe を使う場合の経路と落とし穴

落とし穴:

  • SSH_AUTH_SOCK をWSL側に固定していると ssh.exe は見つけられない。
  • Windows 標準 ssh-agent が動いていると、空のエージェントに接続してしまう。
  • 鍵ファイル直読みになり、パスフレーズで止まりがち。

3) トラブルシュート フロー

チェック順: 1) どの ssh を使っているか → 2) エージェントの見え方 → 3) 競合の排除(標準 ssh-agent / 直読み)。


参考情報

公式ドキュメント

関連記事・解説

GitHub 関連情報

Microsoft 公式


最終更新: 2025年8月
対象: 1Password v8.10.22+ / Windows 11 / WSL2 (Ubuntu 22.04+)

Discussion