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

更新日：2026年5月11日｜カテゴリ：NAS応用

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 をかけていないのに、です。これでようやく、問題は鍵やサーバ側ではなく「クライアント側の OpenSSH バージョン差」にあると確信できました。

3. 真の原因：OpenSSH 10 系の ed25519 鍵解釈の振る舞い

ssh-keygen を -t ed25519 オプション付きでデフォルトのまま実行すると、出力される秘密鍵は OpenSSH 独自の新しいフォーマットになります。鍵ファイルの冒頭は次のような行です。

-----BEGIN OPENSSH PRIVATE KEY-----

このフォーマット自体は OpenSSH の公式仕様ですが、Windows 環境において OpenSSH 9 系と 10 系で振る舞いが分かれるケースがあります。OpenSSH 9 系（Windows 標準）は passphrase なしと正しく判定して鍵を開くのに対し、OpenSSH 10 系（Git for Windows 同梱）は passphrase 付きと判定して入力を要求することがあるのです。

同じ鍵を PowerShell から使うと通るのは、Windows 標準 OpenSSH 9.5p2 が passphrase を要求しないからです。検索しても直接これを指摘しているページが見当たらず、エラーメッセージ「All configured authentication methods failed」だけで Web 検索すると、ほとんど別原因（authorized_keys の権限、サーバ側の sshd 設定、UNC パス、SELinux など）の記事ばかりが出ます。「PowerShell では動くのに IDE / GUI アプリからだけ失敗する SSH」というシチュエーション自体がレアで、解説記事がほぼないのが厄介な点です。

4. 解決手順：PEM 形式の新しい鍵を作って差し替える

原因がわかれば対処は明快です。PEM 形式（RFC 1421 由来の従来 PEM コンテナ）で ed25519 鍵を作り直し、~/.ssh/config でそちらを参照させます。古い鍵を消す必要はなく、Claude Desktop 用に並走する鍵を 1 本追加するだけで済みます。

ステップ 1：PEM 形式で新しい ed25519 鍵を作成

PowerShell を開いて以下を実行します。

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

passphrase を聞かれますが、両回とも 空 Enter でかまいません。サーバ側でアクセス制御（Tailscale ACL や IP 制限）が別途あるなら、passphrase なし運用で実用上の問題は少ないです。私の場合は Tailscale VPN 経由でしか到達できない構成にしているため、鍵側は passphrase なしにしています。

作成後、鍵ファイルの冒頭が -----BEGIN PRIVATE KEY-----（OPENSSH ではない）であることを確認しておくと安心です。

ステップ 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 でテストして、認証が通ることを確認しておきます。

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

passphrase を聞かれずに yamakashi（リモート側のユーザー名）が即座に返れば成功です。ここで通れば、Claude Desktop からも問題なく繋がります。逆にここで通らなければ、まだ何かおかしいので config と鍵のパスを再確認します。

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 が同居していて、それらが同じ ed25519 鍵を別解釈する」というニッチなケースには行き着きません。公式ドキュメントにも記載がなく、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 のトラブルシューティングは「サーバ側を疑い、鍵を疑い、最後にクライアントを疑う」という順で詰めがちですが、クライアント側に同じプロトコルの実装が複数同居していないかを確認することも、選択肢として持っておくと時間を節約できます。

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

yamakashi（クラウドじゃない人）

絶対保存領域の継承者

自宅やオフィスでのNAS活用をもっと身近に、わかりやすく伝えることを目指して「ありがとNAS」を運営しています。IT企業でサーバー・ストレージの導入や運用を経験し、現在は趣味と実務を活かして記事を執筆。初心者でも安心してNASを使いこなせるよう、最新機種レビューからトラブル解決まで実際に検証した情報を発信しています。