☰

この SSH 構成は誤っており、セキュリティ上のリスクがありますか?

tag-icon • tag-icon ssh security
この SSH 構成は誤っており、セキュリティ上のリスクがありますか?

編集：下記の回答を参照してください。私の仮定は間違っていました。

SSH 設定 ( ~/.ssh/configOS X 上) に次の内容がある場合、セキュリティ上のリスクはありますか?

Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/my-secret-key.pem

私の理解では、私がアクセスするすべてのホストに秘密鍵を送信することになりますssh。これは正しいですか? 正しい場合、これはセキュリティ上のリスクですか? 理論上、ホストが私の秘密鍵を使用して主要な SSH ホスト (GitHub など) にログインしようとする可能性はありますか?

を指定した場合HostName、キーはそのホストにのみ送信されると考えるのは正しいでしょうか。

Host *
  HostName github.com
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/my-secret-key.pem

のGitHub の SSH 設定に関する公式ドキュメント最初の設定を使用することを推奨しているようです...

答え1

SSHはない秘密鍵をサーバーに送信します。このメカニズムは、エンティティが所有するものを使用して計算に基づいています。サーバーは公開鍵に基づいて計算し、クライアントは秘密鍵に基づいて計算します（この情報セキュリティスタックエクスチェンジの投稿多くのための）。

いずれにせよ、エージェントにキーを追加するかどうかに関わらず、SSHは成功するまですべてのキーを試します。エージェント転送を設定していない限り、サーバエージェントに追加されたキーを使用できるようになります。

Host *
  HostName github.com
  AddKeysToAgent yes

これにより、Hostnameすべての のHostが に設定されますgithub.comが、これは間違いなく望ましいことではありません (つまり、ssh foo.barは に接続しますgithub.com)。 への接続にのみ何らかの設定を適用する場合はgithub.com、次のパターンを使用しますHost。

Host github.com
    IdentityFile ~/.ssh/my-secret-key.pem

セキュリティ リスクかどうかは、防御対象が誰であるかによって異なります。SSH キーがパスワードで保護されていて、他の誰かがシステム上の SSH エージェントにアクセスできる場合、パスワードで保護されたキーがエージェントに追加されると、すべてのキーにアクセスできるようになります。

しかし、その脅威は起こりそうにないと思います。

関連情報