Claude Desktop の Code タブで Permission denied (publickey) が出る本当の原因と解決法【Windows】

更新日：2026年7月26日｜カテゴリ：その他・技術メモ

1. 起きた症状：PowerShell では繋がるのに Claude Desktop からだけ失敗する

もとの環境はシンプルです。UGREEN DXP2800（UGOS Pro）の上に Docker でサンドボックス用コンテナを立て、OpenSSH を待ち受けにしています。手元の Windows 11 PC から PowerShell の ssh でログインする運用で、これは安定して動いていました。

あるとき、Claude Desktop アプリの Code タブから SSH 接続できる機能を知って、いつもの NAS サンドボックスに繋いでみました。~/.ssh/config も同じ、ホスト名も同じ、鍵も同じ。それなのに、Code タブで接続を作って実行すると次のエラーが出ます。

パスワード認証は無効にしてあるので、入力しても弾かれて終わりです。PowerShell の ssh yamakashi@dxp2800-sandbox-1 なら一発で繋がるのに、Claude Desktop からだけ通らない。同じ Windows 上の同じユーザーの同じ鍵を使っているのに、です。最初は authorized_keys の権限を疑い、コンテナ側を再構築し、サブネットを変え……と、ありとあらゆる場所を触りましたが解決せず、丸 2 日ハマりました。

2. 切り分け：Windows 上には 2 種類の OpenSSH が同居している

転機は、「Claude Desktop は内部でどの ssh 実行ファイルを呼んでいるのか」と疑い始めたところです。Windows 11 には、実は OpenSSH が 2 つ入っています。これは多くの開発者が見落としがちなポイントで、私自身もこの問題を踏むまで明確に意識していませんでした。

結論を先に書くと、Claude Desktop は内部処理で Git for Windows 同梱の OpenSSH を経由しているようでした。これを確認するために、2 つの ssh を直接比較する検証を行います。

検証コマンド：2 つの ssh を -v で動かして比較する

PowerShell を開いて、まず Windows 標準の ssh で接続テストを行います。

# Windows 標準 OpenSSH（9.5p2）
ssh -v dxp2800-sandbox-1 'whoami'

こちらは普段通り yamakashi が返ってきて、接続成功です。問題はもう一方です。

# Git for Windows 同梱 OpenSSH（10系）
& "C:\Program Files\Git\usr\bin\ssh.exe" -v dxp2800-sandbox-1 'whoami' 2>&1

こちらを実行すると、私の環境では次のようなプロンプトが出ました。

同じ鍵ファイル、同じ ~/.ssh/config、同じホストです。それでも一方は通り、もう一方は passphrase を要求する。鍵自体には passphrase をかけていないのに、です。これでようやく、問題は鍵やサーバ側ではなく「Claude Desktop が呼び出す側の ssh」にあると切り分けられました（なぜ 2 つで挙動が分かれたのかは、第 3 章で分かっている範囲を書きます）。

3. 原因の絞り込み：passphrase を聞かれた時点で Claude Desktop は詰む

ここが本記事の核心です。ポイントは鍵の暗号方式でもサーバ設定でもなく、「passphrase を聞かれるかどうか」の一点でした。

つまり、Git 版 ssh が passphrase プロンプトを出した第 2 章の時点で、Claude Desktop 側の勝負はついていたわけです。やるべきことは「Claude Desktop が呼ぶ ssh が、passphrase を聞かずに読める鍵」を用意し、その鍵だけを確実に使わせること。この方針で実際に解決しました。

筆者環境で見えた 9 系と 10 系の違い（観察としての記録）

ひとつ補足しておきます。私の環境では、同じ鍵ファイルに対して Windows 標準の 9.5p2 は無言で通り、Git 版の 10 系だけが passphrase を要求しました。鍵を作るときに passphrase はかけていないので、これは私自身も納得のいっていない挙動です。

ssh-keygen を -t ed25519 でデフォルトのまま実行すると、秘密鍵は OpenSSH 独自フォーマット（冒頭が -----BEGIN OPENSSH PRIVATE KEY----- の形式）で保存されます。この形式自体は OpenSSH の標準的な出力なので、それ自体が悪いわけではありません。9 系と 10 系で読み方が分かれた理由まではこちらでは特定できておらず、OpenSSH 側の確定した仕様・不具合として公表されているものではない点はお断りしておきます。旧鍵ファイルの状態（作成時期や作られ方）に依存した可能性も残ります。

本章の機序説明は筆者環境での切り分けに基づく観察です。環境によって挙動が異なる可能性があります。

原因の断定はできていませんが、対処法は原因の断定を待たずに実行できます。以降の手順は「passphrase なしの鍵を新規に作り、config でそれだけを参照させる」という、原因が何であれ効く方向の対処です。

なお、エラーメッセージ「All configured authentication methods failed」だけで Web 検索すると、ほとんど別原因（authorized_keys の権限、サーバ側の sshd 設定、UNC パス、SELinux など）の記事ばかりが出ます。「PowerShell では動くのに IDE / GUI アプリからだけ失敗する SSH」というシチュエーション自体がレアで、クライアント側を疑う記事が少ないのが厄介な点です。

4. 解決手順：passphrase なしの鍵を作り直して config で指定する

方針が決まれば対処は明快です。Claude Desktop 専用に passphrase なしの ed25519 鍵を 1 本追加し、~/.ssh/config でそれだけを参照させます。古い鍵を消す必要はなく、並走させるだけで済みます。

ステップ 1：新しい ed25519 鍵を passphrase なしで作成

PowerShell を開いて以下を実行します。オプションは -t（鍵の種類）・-f（出力先）・-C（コメント）だけで十分です。

ssh-keygen -t ed25519 -f $env:USERPROFILE\.ssh\id_ed25519_claude -C "yamakashi@windowspc-claude"

passphrase を 2 回聞かれるので、両回とも空 Enterで通します。ここで passphrase を設定してしまうと、第 3 章のカスケード失敗に逆戻りです。

作成できたら、~/.ssh に id_ed25519_claude（秘密鍵）と id_ed25519_claude.pub（公開鍵）の 2 ファイルが並んでいることを確認します。

Get-ChildItem $env:USERPROFILE\.ssh\id_ed25519_claude*

ここで鍵ファイルの中身を開いて確認する必要はありません。ed25519 の秘密鍵は冒頭が -----BEGIN OPENSSH PRIVATE KEY----- になりますが、それは passphrase の有無とは無関係で、見ても判断材料になりません。本当に確認すべきは「passphrase を聞かれずに接続できるか」で、これはステップ 4 で行います。

ssh-keygen -t ed25519 -m PEM は使えません（当サイト実測）

本記事の初出版では、ここで -m PEM を付けて PEM 形式の鍵を作るよう案内していました。記事の内容を見直す過程で「ed25519 に -m PEM は効かないのでは」という疑いが出たため、2026 年 7 月 26 日に手元の Windows で追試したところ、-m PEM は ed25519 では機能しないことが確認できました。訂正してお詫びします。当サイトで実測した結果は次のとおりです。

比較のため、同じ端末で次の 2 つも実行しています。

なお ssh-keygen の man ページも -m PEM について「a supported private key type（対応する秘密鍵の種類）」に限った書き方をしており、ed25519 を PEM 対応の鍵種として挙げてはいません（ssh-keygen マニュアル）。上記の実測結果と矛盾しない記述です。

上記は当サイトが 2026 年 7 月 26 日に実測した結果です（環境：Git for Windows 同梱 OpenSSH_10.3p1 ／ Windows 標準 OpenSSH_for_Windows_9.5p2）。バージョンにより挙動が変わる可能性があります。

初出版で問題が解決したこと自体は事実ですが、効いていたのは鍵の形式変更ではなく、「鍵ファイルを新しく作り直し、IdentityFile と IdentitiesOnly yes でそれだけを名指ししたこと」だったと考えるのが妥当です。旧鍵にも passphrase はかけていなかったはずなのに Git 版 ssh だけが passphrase を要求していた（第 3 章の観察）ので、passphrase を設定しないことに加えて、鍵ファイルそのものを作り直すところまでが必要だった、という整理になります。現在の手順はその形に直してあります。

ステップ 2：新しい公開鍵をリモートホストに登録

まず PowerShell で新しい公開鍵を表示してクリップボードにコピーします。

Get-Content $env:USERPROFILE\.ssh\id_ed25519_claude.pub

ssh-ed25519 AAAA... yamakashi@windowspc-claude という 1 行が表示されるので、これを丸ごとコピーします。続いて、既存の経路（PowerShell の Windows 標準 ssh）を使ってリモートホストにログインし、authorized_keys に追記します。私の場合は NAS 上の Docker コンテナが対象なので、コンテナ越しの追記コマンドを使いました。

ssh yamakashi@dxp2800-sandbox-1
# コンテナ越しに authorized_keys に追記（ヒアドキュメント方式）
docker exec -u yamakashi -i claude-workspace bash -c \
  'cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

カーソルが待機状態になったらコピーしておいた公開鍵を貼り付け、Enter キーを 1 回押し、Ctrl+D で終了します。nano エディタ越しに貼り付けると入力がもたつくことがあるため、ヒアドキュメント方式がストレスフリーです。

普通の VPS や別のサーバなら、ssh-copy-id や直接 echo 'ssh-ed25519 ...' >> ~/.ssh/authorized_keys でも問題ありません。

ステップ 3：~/.ssh/config を新しい鍵に向ける

config ファイルを書き換えます。注意点が 2 つあります。

PowerShell で次のように書き出します。

@"
Host dxp2800-sandbox-1
    HostName dxp2800-sandbox-1
    User yamakashi
    IdentityFile C:/Users/yamakashi/.ssh/id_ed25519_claude
    IdentitiesOnly yes
"@ | Out-File -FilePath $env:USERPROFILE\.ssh\config -Encoding ascii

IdentitiesOnly yes を入れておくと、SSH エージェント側に残っている古い鍵を自動で試行することがなくなり、確実に新しい鍵だけが使われます。複数の鍵を持っているマシンでは特に有効です。

ステップ 4：Git 版 OpenSSH で動作確認

ここが本当の合否判定です。Claude Desktop を起動する前に、Claude Desktop が使うのと同じ Git 版 OpenSSH でテストして、passphrase を聞かれずに認証が通ることを確認しておきます。

& "C:\Program Files\Git\usr\bin\ssh.exe" dxp2800-sandbox-1 'whoami'

passphrase を聞かれずに yamakashi（リモート側のユーザー名）が即座に返れば成功です。ここで通れば、Claude Desktop からも同じ経路で繋がるはずです。逆にここで passphrase を聞かれたり弾かれたりするなら、まだ何かおかしいので config の IdentityFile のパスと、公開鍵が authorized_keys に入っているかを再確認します。

5. Claude Desktop で再接続する手順

Claude Desktop はキャッシュの都合か、設定変更が反映されにくいことがあります。タスクトレイからの完全終了を経由してから接続し直すと確実です。

1. Claude Desktop アプリを通常の閉じるボタンで閉じる
2. タスクトレイのアイコンを右クリックして「終了」を選び、バックグラウンドプロセスも止める
3. Claude Desktop を再起動する
4. Code タブを開き、SSH 接続編集ダイアログで以下のように設定する
   • SSH host：dxp2800-sandbox-1（yamakashi@ は付けない。~/.ssh/config 側で User を指定済みなので不要）
   • SSH port：空欄（デフォルト 22 が使われる）
   • Identity file：空欄（config を参照させる方が安定）
5. 「保存」して接続を開始する

接続が成功したら、必ず最後にもう 1 つ作業があります。Code タブのプロンプト入力欄の上にある 「フォルダを選択」 ボタンを押して、作業対象のディレクトリを明示的に指定します。これを省くと Claude Code がホームディレクトリ /home/yamakashi で起動し、設定ファイルやシークレットを置いている領域が技術的には触れる状態になります。セキュリティは設計だけでなく操作習慣でも担保する必要がある、というのを身をもって学んだポイントでした。

6. なぜこの情報はネット検索で見つからないのか

同じ問題で時間を溶かす人を一人でも減らしたいので、見つけにくさの理由も書いておきます。私が最初に検索したクエリと、それで出てきた結果はだいたい次のような感じでした。

どの結果も「Windows 上に 2 種類の OpenSSH が同居していて、片方だけが同じ鍵ファイルに passphrase を要求してくる」というニッチなケースには行き着きません。公式ドキュメントにも記載がなく、Claude Desktop のリリースノートでも触れられていないので、自力で切り分けるしかないというのが現状です（2026 年 5 月時点）。本記事が、同じ症状で詰まっている方の検索結果にいち早く出てくれることを願っています。

7. 検証環境とバージョン情報

本記事の検証は、以下の環境で実施しました。今後のバージョンアップで挙動が変わる可能性があるため、念のため記録として残しておきます。

OpenSSH のバージョンは PowerShell で ssh -V と & "C:\Program Files\Git\usr\bin\ssh.exe" -V を実行すれば確認できます。Git for Windows のバージョンは git --version、Claude Desktop のバージョンはアプリのメニューから「Claude について」で確認可能です。

8. よくある質問（FAQ）

9. まとめ：「PowerShell では動くのに GUI からだけ失敗する SSH」はクライアント側を疑う

同じシチュエーションでハマっている方に、この記事が届くことを願っています。SSH のトラブルシューティングは「サーバ側を疑い、鍵を疑い、最後にクライアントを疑う」という順で詰めがちですが、クライアント側の ssh が対話入力を求めていないか、同じプロトコルの実装が複数同居していないかを確認することも、選択肢として持っておくと時間を節約できます。

関連記事：自宅 NAS 上に Claude Code 専用サンドボックスを構築した全記録／Tailscale × Docker で NAS を公開しないリモート開発環境を作る方法