ホストよりB他のさまざまなホストにSSH接続できます（CD) は、対応する authorized_keys ファイル (ホスト C および D) に公開鍵を配置したため、パスワードを使用せずに実行できます。
ホストよりあSSHホストできますB（経由パスワード認証）。しかし、ホストにログインするとB私毎回キーを認証する必要があるC と D に接続する場合 (原則としてそうではないはずですが)。
要約すると、ホスト B (例: オフィス) に直接接続する場合、C または D に接続するためにパスワードを入力する必要はありません。A (例: 自宅) に接続し、次に AI から B に接続すると、BI では D または C に接続するためにパスワードが必要になります。ssh-agent にパスワードを追加することで (ssh-add を使用して)、この問題を部分的に解決できますが、BI で新しいシェルを開くたびにこれを再度実行する必要があります。
アップデート
役に立つコメントのおかげで、問題は次の通りであることが判明しました。B に直接接続すると、キーリング プログラムが実行されます (私の場合は seahorse です)。したがって、暗号化されたすべての秘密キーのパスワードは自動的に使用できます。A から B に接続すると、これは起こりません。不思議なことに、A から B へのリモート セッション (vnc / remmina) を開始しても、プログラム seahorse は B でアクティブではないため、パスワードを何度も手動で入力する必要があります。
インストールしましたキーチェーンそして問題は解決しました。
ただし、特定のサーバーへの SSH 接続にのみ使用される秘密鍵を暗号化する価値があるかどうかはわかりません。秘密鍵を暗号化しないことで具体的なセキュリティ上のリスクはありますか?原則として、秘密鍵にアクセスできる人は、キーチェーンに保存されているパスワードも使用できます...したがって、秘密鍵を暗号化しても大きな利点はないと思われます。
答え1
SSH キーのパスフレーズの保存場所として を使用することで、問題の一部は解決しましたkeychain。その他の質問については、次のとおりです。
しかし、特定のサーバーへの SSH 接続にのみ使用される秘密鍵を暗号化する価値があるかどうかはわかりません。秘密鍵を暗号化しないことで具体的なセキュリティ上のリスクはありますか? 原則として、秘密鍵にアクセスできる人はキーチェーンに保存されているパスワードも使用できます...したがって、秘密鍵を暗号化しても大きな利点はないようです。
秘密鍵が暗号化されていないわけではなく、パスフレーズで保護されていないのです。そのため、ホームディレクトリの.sshディレクトリにアクセスできる人なら誰でも、問題なく SSH キーを制御できます。
完全に制御できるシステムにこれらのキーを残しておいても問題ない場合は、パスフレーズなしで残しても問題ないと思います。また、このようなセカンダリ システムに残すことができる別のキー セット、またはこのサーバー専用の一意のセットを生成することもお勧めします。そうすれば、侵害されたことが判明した場合に、ほとんど問題なく完全に放棄できます。
キーの管理に を使用keychainする場合、SSH キーにパスフレーズを設定してもkeychain、keychain使用時にのみ保存されるという点を除けば、あまりメリットはないと思います。キーを頻繁に使用せず、使用後はこまめにクリーンアップする場合はkeychain、パスフレーズが有利ですが、私見では、その利点は小さいと思います。