KUSANAGI SFTPへ1Password経由で接続した記録

結論

初回接続では、1Password CLIからパスワードを一時的に取得し、PythonのSFTPライブラリへ渡す「接続用ヘルパー」方式を使った。

その後、1Passwordで専用のEd25519鍵を作り、公開鍵だけをサーバーへ追加した。 Windows標準のOpenSSHを使う対話ターミナルでは、パスワードを入力せずに接続できることまで確認した。

ただし、Codexのバックグラウンド実行では、1Passwordによる署名承認を待つ処理がタイムアウトした。サーバーは公開鍵を受理しているため、鍵やサーバー設定の問題ではなく、実行環境から1Passwordの承認を完了できるかどうかが残る課題である。

FileZillaのパスワード接続設定と、サーバーのパスワード認証設定は変更していない。したがって、今回の公開鍵追加によってFileZillaが使いにくくなることはない。

初回接続の確認

1. SSHポートへの到達性を確認

最初に、接続先の22番ポートへ到達できることを確認した。公開記事では接続先を伏せるため、以下ではプレースホルダーを使う。

Test-NetConnection -ComputerName <SERVER_HOST> -Port 22

TcpTestSucceeded: Trueを確認してから、認証方法の調査へ進んだ。

2. 公開鍵認証だけを試す

パスワードを使う前に、すでに利用できる公開鍵がないかを調べた。

& "C:\Windows\System32\OpenSSH\ssh.exe" `
  -o PreferredAuthentications=publickey `
  -o PasswordAuthentication=no `
  -o BatchMode=yes `
  -o ConnectTimeout=10 `
  <SSH_USER>@<SERVER_HOST> "echo OK"

この時点ではPermission deniedとなった。これは、後で作成する1Passwordの公開鍵が、まだサーバーのauthorized_keysに登録されていなかったためである。

3. 1Passwordのパスワードで接続

パスワードはチャットやスクリプトへ直接書かなかった。 1Password CLIで一時取得し、環境変数を経由してPythonのParamikoへ渡した。

1Password
  ↓ 一時取得
プロセスの環境変数
  ↓
ParamikoによるSFTP接続

この方式では、パスワードは画面、チャットログ、接続用ファイルに表示されない。一方で、接続処理のメモリ内には一時的に平文で存在する。

接続後は、サーバー上のホームディレクトリを読み取れることまで確認した。検証に使った一時環境とスクリプトは、作業後に削除した。

1Password SSH Agentを使う公開鍵認証の追加

パスワードを取り出さずに接続できるよう、次の設定を追加した。

1Passwordで接続専用のEd25519鍵を作成した。
1Password SSH Agentを有効にした。
既存の~/.ssh/authorized_keysを日時付きの名前でバックアップした。
既存の公開鍵を残したまま、新しい公開鍵を1行だけ追記した。
~/.sshを0700、authorized_keysを0600に設定した。
書き込み後に、新しい公開鍵が存在することを再確認した。

秘密鍵は1Passwordの外へ出していない。サーバーへ登録したのは、公開しても秘密鍵を復元できない公開鍵だけである。

接続テストで判明したWindows上の違い

Git Bash付属のsshでは鍵が見えなかった

Git Bash付属の/usr/bin/sshを使ったテストでは、1Passwordに保存した鍵が候補に現れず、公開鍵認証に失敗した。

1Password SSH Agentは、Windowsの名前付きパイプを通じて鍵の署名機能を提供する。 Git Bash付属のsshは、初期状態ではUnix形式のSSH_AUTH_SOCKを探すため、このWindows側の経路を利用できなかった。

Windows標準OpenSSHでは成功した

Claude Codeの対話ターミナルから、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"

1Password SSH Agentが専用鍵を提示し、サーバーが受理した。最終的にKEY_AUTH_OKが返り、この対話ターミナルではパスワードなしで接続できることを確認した。

Codexのバックグラウンド実行で残った課題

Codexから同じWindows標準OpenSSHを使った詳細ログでは、サーバーが新しい公開鍵を受理するところまで進んだ。その後、1Passwordに署名を依頼する段階で通信がタイムアウトした。

公開鍵の提示
  ↓
サーバーが公開鍵を受理
  ↓
1Passwordへ署名を依頼
  ↓
Codexのバックグラウンド実行では承認待ちがタイムアウト

この結果は、Claude Codeの成功と矛盾しない。サーバーと鍵の設定は正しいが、1Passwordの承認画面を扱えるかどうかが、対話ターミナルとバックグラウンド実行で異なるためである。

現時点の検証結果は次のとおり。

実行環境	結果	状態
Windows標準OpenSSHを使う対話ターミナル	成功	公開鍵認証を利用可能
Git Bash付属のssh	失敗	1Password SSH AgentのWindows側経路を認識しない
Codexのバックグラウンド実行	署名段階でタイムアウト	1Passwordの承認方法を追加確認する必要がある

FileZillaへの影響

今回行ったのは、サーバーへ新しい公開鍵を追加する作業である。パスワード認証を無効にする作業ではない。

そのため、FileZillaは従来どおりパスワードで接続できる。将来、FileZillaも公開鍵認証へ移行することはできるが、今回の作業とは分けて判断できる。

今後の運用

対話ターミナルから接続するときは、Windows標準OpenSSHと1Password SSH Agentによる公開鍵認証を優先する。

Codexのバックグラウンド実行では、署名承認を安定して完了できる方法が確認できるまで、1Passwordのパスワードを一時利用する接続用ヘルパーを代替手段として残す。この場合も、パスワードを画面、チャット、ファイルへ出さない。

設定の意味と画面ごとの選び方は、1Password SSH AgentでコーディングエージェントのSSH接続を安全にするに整理した。

#1Password#SFTP#SSH#接続テスト #Claude Code #Codex