Windows × WSL × 1Password でSSHとGit Signedを加速する

1. 概要

1PasswordのSSHエージェント機能を活用し、Windows Native（PowerShell/Git for Windows）とWSL2の両環境で同一の秘密鍵を共有・運用するための最適化設定を記述する。WSL2からWindowsパイプへ接続するためのブリッジ構築手順、Windows側での複雑なパス解決問題の修正、および両環境における1Passwordを用いたGitコミット署名の統合を網羅する。

2. アーキテクチャ構成図

1Passwordで両環境からSSH利用とGitコミット署名を行う仕組みを以下に示す。

3. 【事前準備】Windows標準SSHエージェントの無効化

1PasswordやBitwarden等のパスワードマネージャーでSSHエージェント連携を有効化する際、Windows OS標準の「OpenSSH Authentication Agent」サービスが稼働していると名前付きパイプが競合し、正常に動作しない。
以下の設定を行う前に、管理者権限でPowerShellを開き、必ず事前にサービスを停止・無効化すること。

# 管理者権限のPowerShellで実行
Stop-Service ssh-agent
Set-Service ssh-agent -StartupType Disabled

4. WSL2環境の最適化：npiperelayブリッジとSSH署名

WSL2（Linux）からWindows側の名前付きパイプへ直接アクセスすることはできないため、npiperelay.exe を介してUnixドメインソケットとブリッジさせる必要がある。

手順1：npiperelay.exe の配置

Windows側の任意のフォルダ（例：C:\tools\npiperelay\）に npiperelay.exe を配置する。

手順2：WSL2側でのソケットブリッジ設定

WSL2側で socat をインストールし、シェルの設定ファイル（.bashrc または .zshrc）に以下のスクリプトを追記する。

# socatのインストール (初回のみ)
# sudo apt install socat

# 1Password SSH Agent Bridge 設定
export SSH_AUTH_SOCK=$HOME/.1password/agent.sock

# すでにソケットが存在する場合は無視し、バックグラウンドでリレーを開始
if [ ! -S "$SSH_AUTH_SOCK" ]; then
    mkdir -p ~/.1password
    NPIPERELAY="/mnt/c/tools/npiperelay/npiperelay.exe"

    (setsid socat UNIX-LISTEN:"$SSH_AUTH_SOCK",fork EXEC:"$NPIPERELAY -ei -s //./pipe/openssh-ssh-agent",nofork &) >/dev/null 2>&1
fi

export PATH="$HOME/.local/bin:$PATH"

手順3：WSL側 SSH Configの最適化

WSL2環境では手順2で設定した環境変数 SSH_AUTH_SOCK によってエージェントが自動的に認識されるため、IdentityAgent の明示は不要である。

~/.ssh/config の記述例:

Host github.com
    HostName github.com
    User git

手順4：WSL側でのGitコミット署名（SSH）の設定

WSLのGit（v2.34以降）は、環境変数 SSH_AUTH_SOCK でブリッジされた1Passwordの鍵をネイティブに利用して署名が可能である。ただし、署名の検証用に allowed_signers ファイルが必須となる。これがないと、git log --show-signature で確認した際に「誰の署名か検証できない（信頼できない署名）」として扱われ、正しくユーザー名が表示されない。

# 署名フォーマットをSSHに指定
git config --global gpg.format ssh

# 署名に使用する公開鍵を設定
git config --global user.signingkey "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBlmfcTH6XdWd8axoyLFHdSwaSX6Goczh1gy8xIQtij8"

# 自身の公開鍵を信頼済みの署名者として登録
git config --global gpg.ssh.allowedsignersfile ~/.ssh/allowed_signers

~/.ssh/allowed_signers ファイルを作成し、以下のように自分のメールアドレスと公開鍵を記述する。

[e-mail] ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBlmfcTH6XdWd8axoyLFHdSwaSX6Goczh1gy8xIQtij8 Arx WSL

最後に、コミットへの署名を有効化する。

# すべてのコミットで自動的に署名を行う
git config --global commit.gpgsign true

5. Windowsネイティブ環境の最適化：「3つの罠」の回避

Windows側のGit操作において1Passwordエージェントとの通信に失敗する場合、以下の「3つの要因」が絡み合っていることが多い。

• 要因A：内蔵SSHバイナリのパイプバグ
  Git同梱の ssh.exe（MSYS2版）はWindowsの名前付きパイプにアクセスするとリソース競合（Busy）を引き起こす。

• 要因B：バックスラッシュ（\）消失バグ
  ~/.ssh/config 内で \\.\pipe\... と記述すると、プロセスの受け渡し過程でエスケープされ、パスが破壊される。

• 要因C：IdentitiesOnly yes の排斥
  この設定が有効だと、エージェント由来の鍵が設定ファイル指定外として破棄される。

これらを完全に回避し、コミット署名まで設定する手順は以下の通り。

Step 1: SSHバイナリの固定

Gitが利用するSSHバイナリを、Windows OS標準のOpenSSHに強制する。

git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"

Step 2: SSH Configの汎用化（Host * への適用）

すべてのホストに対して1Passwordのパイプを利用するよう、パスをスラッシュ（//./pipe/openssh-ssh-agent）に変更して全体（Host *）に適用する。IdentitiesOnly yes は無効化する。

~/.ssh/config の最適化記述:

Host *
    IdentityAgent "//./pipe/openssh-ssh-agent"

Host github.com
    HostName github.com
    User git

Step 3: 1Passwordを利用したGitコミット署名の統合

1Passwordが提供する署名用プログラムを利用して、デジタル署名を自動化する。

💡 コラム：なぜGPGキーではなく「SSH鍵」で署名するのか？
1Password等のモダンなパスワードマネージャーは、従来のGPGキーの直接的な管理をフルサポートしていない。そのため、現在は管理が一元化できるSSH鍵を用いたコミット署名（gpg.format = ssh）が強く推奨されている。

⚠️ 注意点（一部のGitサーバーでのUI表示）
GitHub等はSSH署名に完全対応しているが、Gitea（1.24.x系など）の一部GitサーバーではWeb UI側がSSH署名の表示に未対応の場合がある。コミット自体は正しく署名されていても、UI上では「Unverified」等になることがある点に留意すること。

# 署名フォーマットをSSHに指定
git config --global gpg.format ssh

# 1Passwordの署名プログラムを指定
git config --global gpg.ssh.program "C:/Users/dapt/AppData/Local/Microsoft/WindowsApps/op-ssh-sign.exe"

# 署名に使用する公開鍵を設定（各自の公開鍵に置き換える）
git config --global user.signingkey "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBlmfcTH6XdWd8axoyLFHdSwaSX6Goczh1gy8xIQtij8"

# すべてのコミットで自動的に署名を行う
git config --global commit.gpgsign true

6. トラブルシューティング（デバッグ手法）

環境差異による問題を特定するための標準的なデバッグ手順。

実行プロセスの追跡（Windows）

Gitが実際に呼び出しているバイナリパスと引数を検証し、意図しないSSHバイナリが使われていないか確認する。

$env:GIT_TRACE=1
$env:GIT_TRACE_SETUP=1
git clone <repository_url>

認証プロセスの詳細出力（共通）

特定のSSHバイナリを指定し、エージェントからの鍵取得や認証の各フェーズを可視化する。

# Windows
$env:GIT_SSH_COMMAND="C:\Windows\System32\OpenSSH\ssh.exe -vvv"

# WSL2
GIT_SSH_COMMAND="ssh -vvv" git clone <repository_url>

7. 結論

WindowsとWSL2で1Password SSHエージェントを共有する場合、大前提となるサービス停止に加え、WSL2側では「npiperelayによるソケットブリッジ構築とネイティブ署名設定」、Windows側では「システム標準SSHの使用とパス記法の最適化」が必須となる。これらを組み合わせることで、OSの境界を意識せず、認証からコミット署名まで一貫したセキュアな開発環境が構築される。パスフレーズの管理も手間が省けるため、非常にお勧めする。