SFTPのホスト鍵の警告に対処する

SSHのホスト鍵の警告はサーバーの正当性に関するもので、dosyaのパスワードやAPIキーに関する警告ではありません。予期しない確認画面が表示された場合、別のホストやポートが示された場合、保存済みの鍵が変わったと報告された場合は認証前に操作を止めてください。dos_…認証情報をローテーションしてもホスト鍵の不一致は解消しません。

アプリに記載された本番環境の接続先はsftp.dosya.dev、ポート2222です。サーバーは起動時にホスト鍵を読み込みますが、このリポジトリには、このガイドで安全に公開できる認証済みの本番環境のフィンガープリントは含まれていません。ssh-keyscanでは同じネットワーク経路で提示された鍵を取得できますが、それだけではその鍵がdosyaのものであることを証明できません。

手順

1. 表示された鍵を受け入れず、APIキーのパスワードも入力せずに接続をキャンセルしてください。表示されたホスト名、ポート、鍵アルゴリズム、フィンガープリント、クライアント名、時刻を正確に記録してください。
2. 保存済みの接続先がsftp.dosya.dev:2222であることを確認してください。ポート22、生のIPアドレス、プロキシのホスト名、FTP、FTPSに対する警告は、文書化されたdosyaのSFTPエンドポイントではありません。
3. 初回接続か、信頼記録のない新しいデバイスか、既存の記録に対する**REMOTE HOST IDENTIFICATION HAS CHANGED!**の警告かを確認してください。鍵の変更が示された場合は、より高いリスクとして扱います。
4. dosyaサポートまたは管理者から、別の信頼できる経路で現在のフィンガープリントを取得してください。フィンガープリントのすべての文字と鍵の種類を比較し、警告ダイアログ自体を確認元として使わないでください。
5. 値が一致する場合は、元のクライアントで鍵を受け入れ、パスワード認証に進んでください。異なる場合や信頼できる値が得られない場合は接続を閉じたままにし、記録した秘密ではない情報をサポートに送ってください。
6. 受け入れた後、正確なアカウントのメールアドレスと専用APIキーで接続し、目的のワークスペースを一覧表示して、読み取り専用のテストを行ってください。恒久的にすべてのホスト鍵を受け入れる設定やStrictHostKeyChecking=noによる回避策を有効にしないでください。

初回利用時の確認画面は、クライアントに保存された信頼記録がないため正常な場合があります。鍵の変更警告は正当なサーバーのローテーション後にも表示されることがありますが、独立した確認前に古い記録を削除すると警告による保護が失われます。ネットワークでの傍受や、保存済みの誤ったホストへの接続でも同じ症状になるため、確認画面だけでは区別できません。

APIキー、保存済みホストのファイル、完全なデバッグログを公開のサポートリクエストに貼り付けないでください。サーバーの正当性の確認には、ホスト、ポート、アルゴリズム、フィンガープリント、タイムスタンプ、クライアントのバージョンで十分です。

確認できる結果

クライアントは、別の経路で得たフィンガープリントが表示値と一致した後にのみホスト鍵を保存し、sftp.dosya.dev:2222に対して認証します。一致しない場合はセッションを閉じたままにし、認証情報は送信されません。

関連ガイド

• SFTPクライアントを接続する
• 制限付きキーでSFTP接続する