1Password SSH AgentでコーディングエージェントのSSH接続を安全にする

「1Passwordにパスワードを保存し、コーディングエージェントにはパスワードを見せずにサーバーへ接続してほしい」。この要望を実現する方法は、主に二つある。

ひとつは、接続するときだけ1Passwordからパスワードを取り出す「接続用ヘルパー」である。もうひとつは、1Passwordの外へ秘密鍵を出さずに使う「1Password SSH Agent」である。

結論から言えば、一時的な接続確認には接続用ヘルパーを使えるが、継続的な接続にはSSH Agentによる公開鍵認証が向いている。

そもそも公開鍵は漏れても大丈夫なのか

SSHの鍵は「公開鍵」と「秘密鍵」という、数学的に対になった2つのファイルで作られる。

公開鍵は誰に見られても構わない。接続先のサーバーへ登録し、他人の目に触れても実害はない。
秘密鍵は本人だけが保持し、絶対に人に見せない。接続時の署名にだけ使う。

この非対称な扱いが成り立つのは、「秘密鍵から公開鍵を計算するのは簡単だが、公開鍵から秘密鍵を逆算するのは現実のコンピュータでは事実上不可能」という、一方向にしか解けない数学的な関係を使っているためである。公開鍵がどれだけ広まっても、そこから秘密鍵を割り出すことはできない。

身近な例で言うと、実印と印鑑証明の関係に近い。印鑑証明書（公開鍵に相当）は誰でも確認できるが、それをいくら見ても実印（秘密鍵に相当）そのものを複製することはできない。逆に、実印を持っている本人だけが、契約書に「本人が押した」と証明できる印影を残せる。

サーバーが実際に検証しているのは「秘密鍵を持っている証拠」であって、秘密鍵そのものではない。接続のたびに、SSHクライアントは秘密鍵を使ってその場限りの署名を作り、サーバーは公開鍵を使ってその署名が正しいかを確かめる。秘密鍵自体はネットワークを一度も流れない。

公開鍵と秘密鍵の非対称性を示す図。秘密鍵から公開鍵は計算できるが、公開鍵から秘密鍵は計算できない — 図1: 公開鍵は見られても平気、秘密鍵だけが本人確認の根拠になる

何を設定しているのか

SSHの公開鍵認証では、対になる二つの鍵を使う。

公開鍵は接続先のサーバーへ登録する。
秘密鍵は本人だけが保持し、接続時の署名に使う。

秘密鍵をサーバーへ送るわけではない。サーバーは、登録された公開鍵を使って、接続者が対応する秘密鍵を持っているかを検証する。

1Password SSH Agentを使うと、秘密鍵を1Passwordから取り出さずに、この署名だけを依頼できる。SSHクライアントが受け取るのは「署名してもらった結果」だけで、秘密鍵そのものには一度も触れない。

1Password SSH Agent経由の接続シーケンス図。SSHクライアントはAgentに署名を依頼し、Agentは秘密鍵を外に出さずに署名だけを返し、SSHクライアントがサーバーへ提出、サーバーが公開鍵で検証する — 図2: 秘密鍵は1Passwordの中から一歩も出ない。SSHクライアントが受け取るのは署名の結果だけ

この仕組みでセキュリティはどう担保されているか

ここまでの内容をまとめると、安全性は二重の仕組みで担保されている。

数学的な一方向性: 公開鍵から秘密鍵を逆算できない。公開鍵がどれだけ広く知られても、それだけで他人になりすますことはできない。
秘密鍵を外に出さない運用: 1Password SSH Agentは、秘密鍵を使った署名処理を1Passwordの中だけで完結させる。SSHクライアントやコーディングエージェントが受け取るのは署名結果だけで、秘密鍵そのものには一度も触れない。

パスワード認証と比べると、この違いがはっきりする。パスワードは接続のたびに検証者へ「そのもの」を渡す情報だが、鍵認証は「秘密鍵を持っている証拠」だけを渡す。証拠（署名）を盗み見られても、そこから秘密鍵を偽造することはできない。だからこそ、1Password SSH Agentのように秘密鍵をアプリの外へ一切出さない運用が、パスワードを都度取り出す接続用ヘルパーより安全になる。

接続用ヘルパーとの違い

方法	接続時の動き	認証情報の扱い	向いている用途
接続用ヘルパー	1Passwordからパスワードを一時取得し、接続ライブラリへ渡す	メモリ内には一時的に平文で存在する	初回設定、公開鍵を登録するための接続、予備手段
1Password SSH Agent	1Password内の秘密鍵に署名を依頼する	パスワードも秘密鍵も取り出さない	日常的なSSH・SFTP接続

接続用ヘルパーも、パスワードをチャット、画面、ファイルへ表示しなければ、手入力より安全に運用しやすい。ただし、パスワードそのものを接続処理へ渡す点は変わらない。

SSH Agentでは、接続処理が受け取るのは署名結果であり、秘密鍵そのものではない。この違いが、SSH Agentを定常運用に向ける理由である。

FileZillaは使えなくならない

公開鍵をサーバーへ追加しただけでは、FileZillaのパスワード接続に影響しない。

サーバー側には、パスワード認証と公開鍵認証を並行して許可できる。今回の設定は、既存の入口を閉じず、新しい入口を追加した状態である。

FileZilla
  └─ 従来のパスワード認証を継続

Windows標準OpenSSH
  └─ 1Password SSH Agentの公開鍵認証を追加

FileZillaが使えなくなるのは、サーバー管理者が後からパスワード認証を明示的に無効化した場合である。今回の設定では、その変更を行っていない。

1Password SSH Agentの設定手順

1. SSH Agentを有効にする

1Passwordの「設定」から「開発者」を開き、「SSHエージェントを使用する」を有効にする。

有効化の途中で、SSHキーの名前を暗号化されていない状態でディスクへ保存するかを尋ねられる。

プライバシーを優先するなら、「キー指紋のみを使用」を選べばよい。接続承認画面にはキー名ではなく指紋が表示されるため、複数の鍵を見分けにくくなるが、認証機能そのものには影響しない。

「キー名の使用」は、どの鍵を使うかを名前で見分けやすくするための任意設定である。キー名を暗号化されていない状態でローカルへ保存しても問題ないと判断した場合だけ選ぶ。

2. WindowsのOpenSSH認証エージェントを無効と確認する

次の画面は、Windows標準のssh.exeやsftp.exeを無効にする確認ではない。 Windowsに付属する別の認証エージェントサービスと、1Password SSH Agentの競合を避けるための確認である。

WindowsのOpenSSH認証エージェントが無効かを確認する1Passwordの画面

Windowsの「OpenSSH Authentication Agent」サービスが停止かつ無効であれば、「はい、OpenSSHは無効です」で進める。この選択後も、Windows標準のSSHコマンドは引き続き利用できる。

ここで区別したい対象は次の二つである。

名前	役割	今回の扱い
Windows標準OpenSSHクライアント	`ssh.exe`や`sftp.exe`としてサーバーへ接続する	使用する
OpenSSH Authentication Agentサービス	Windows側で秘密鍵を保持して署名する	1Passwordと競合するため無効にする

3. 上級設定を確認する

今回の用途では、次の設定でよい。

「接続を承認するときにキー名を表示する」は、キー名をローカル保存したくなければオフにする。
「リッチ承認プロンプトを使用する」はオンにする。
「ブックマークされたホストを含むSSH設定ファイルを生成する」は、必要になるまでオフでよい。
「次のものでSSH URLを開く」は、普段使うWindows Terminalのままでよい。

新しい接続ごとの承認と、重要な承認を覚える期間は、初期設定のままで問題ない。安全性を優先する場合は、承認を求める範囲や期間を短くできる。

4. 接続専用のSSH鍵を作る

1Passwordで新しいSSHキーを作り、用途が分かる名前を付ける。鍵タイプはEd25519を選べばよい。

接続先ごと、または用途ごとに専用鍵を分けると、後から一つの接続権限だけを取り消しやすい。

秘密鍵やリカバリー情報が見える画面は、公開記事へ掲載しない。公開鍵は秘密鍵ではないが、サーバー構成や利用者を推測する材料になり得るため、必要がなければ指紋とともに伏せる。

5. 公開鍵をサーバーへ追加する

1Passwordから公開鍵だけをコピーし、接続先ユーザーの~/.ssh/authorized_keysへ1行で追加する。

すでに公開鍵が登録されている場合は、ファイルを置き換えてはいけない。先にバックアップを作り、既存行を残したまま追記する。

一般的な権限は次のとおりである。

~/.ssh                  0700
~/.ssh/authorized_keys  0600

この登録作業だけは、既存のパスワード接続やサーバー管理画面など、現在利用できる方法で行う必要がある。登録後は、パスワードを使わずに公開鍵認証を試せる。

Windowsで接続をテストする

Windowsでは、1Password SSH Agentと連携できるクライアントを確実に使うため、Windows標準OpenSSHのフルパスを指定する。

& "C:\Windows\System32\OpenSSH\ssh.exe" `
  -o PreferredAuthentications=publickey `
  -o PasswordAuthentication=no `
  -o KbdInteractiveAuthentication=no `
  <SSH_USER>@<SERVER_HOST> "echo KEY_AUTH_OK"

KEY_AUTH_OKと表示されれば、パスワードへフォールバックせずに公開鍵認証だけで接続できた。

SFTPも同じクライアント群を使える。

& "C:\Windows\System32\OpenSSH\sftp.exe" <SSH_USER>@<SERVER_HOST>

接続時に1Passwordの承認画面が出たら、接続先と使用する鍵を確認して承認する。

Git Bashでは失敗することがある

Windows上の1Password SSH Agentは、Windowsの名前付きパイプを使って署名機能を提供する。一方、Git Bash付属の/usr/bin/sshは、初期状態ではUnix形式のSSH_AUTH_SOCKを探す。

この違いにより、Git Bashから接続すると、1Passwordにある鍵が候補へ出ないことがある。追加のブリッジ設定も可能だが、まずはWindows標準OpenSSHを明示するのが簡単である。

症状	確認すること	対応
1Passwordの鍵が候補に出ない	Git Bash付属のsshを使っていないか	Windows標準OpenSSHをフルパスで実行する
サーバーは鍵を受理した後、署名に失敗する	1Passwordがロック中でないか、承認画面が出ていないか	1Passwordを開き、SSH Agentのアクティビティを確認する
`Permission denied`がすぐ返る	公開鍵が正しいユーザーの`authorized_keys`にあるか	登録先、改行、ファイル権限を確認する
FileZillaで接続できなくなった	パスワード認証設定を別途変更していないか	公開鍵追加とは別の設定変更を確認する

対話ターミナルとコーディングエージェントでは結果が違うことがある

同じWindows標準OpenSSHを使っても、1Passwordの承認画面を表示し、利用者が承認できる実行環境かどうかで結果が変わる。

今回の検証では、Claude Codeの対話ターミナルからは公開鍵認証に成功した。一方、Codexのバックグラウンド実行では、サーバーが公開鍵を受理した後、1Passwordへ署名を依頼する段階でタイムアウトした。

したがって、「公開鍵の登録に成功したこと」と「すべてのコーディングエージェントから無人接続できること」は分けて確認する必要がある。

無人接続を安易に許可すると、利用者が気づかないままサーバー操作が実行される範囲も広がる。まずは接続ごとに1Passwordで承認する運用から始め、実行環境ごとに動作を確認するのが安全である。

今回の運用方針

Windowsの対話ターミナルでは、1Password SSH AgentとWindows標準OpenSSHを使う。
FileZillaは、従来のパスワード接続を予備手段として残す。
Codexのバックグラウンド実行では、1Passwordの署名承認を安定して完了できるまで、接続用ヘルパーを予備手段として使う。
パスワード、秘密鍵、1Passwordの項目ID、実サーバーのIPアドレスは、記事やチャットへ掲載しない。

実際の接続確認と設定変更の時系列は、KUSANAGI SFTPへ1Password経由で接続した記録にまとめている。

#1Password#SSH Agent#SSH#SFTP #Windows#コーディングエージェント