HeartbleedはSSHキーに影響しますか？
最近のHeartbleedバグは、Github、Heroku、およびその他の同様のサイトでコードをプッシュ/プルするために生成して使用したsshキーに影響しますか？
使用していたキーを交換する必要がありますか？
いいえ、Heartbleedは実際にはSSHキーに影響を与えないので、使用していたSSHキーを置き換える必要はおそらくありません。
まず、SSLとSSHは、2つの異なる用途のための2つの異なるセキュリティプロトコルです。同様に、OpenSSLとOpenSSHも、名前が似ているにもかかわらず、2つの完全に異なるソフトウェアパッケージです。
次に、Heartbleedエクスプロイトにより、脆弱なOpenSSL TLS/DTLSピアがランダムな64kBのメモリを返しますが、そのOpenSSLを使用するプロセスがアクセスできるメモリにほぼ制限されます。 OpenSSLを使用するプロセスがSSH秘密鍵にアクセスできない場合、Heartbleed経由でリークすることはできません。
また、通常、SSH publicキーは、SSHを使用して接続するサーバーにのみ配置します。名前が示すように、公開キーは公開できるキーです。誰が知っているかは関係ありません。実際、あなたは正しい公開鍵を知っているwant publicです。
この脆弱性が脆弱なバージョンのOpenSSLをクライアント側のTLS/DTLSライブラリとして使用するクライアントアプリに影響を与える可能性があることを指摘してくれた@Bobに感謝します。たとえば、WebブラウザまたはSSLベースのVPNクライアントが脆弱なバージョンのOpenSSLを使用し、悪意のあるサーバーに接続している場合、その悪意のあるサーバーはHeartbleedを使用して、そのクライアントソフトウェアのメモリのランダムなスニペットを見ることができます。なんらかの理由でそのクライアントアプリのSSH秘密鍵のコピーがメモリにある場合、Heartbleed経由でリークする可能性があります。
頭の中で、暗号化されていないSSH秘密キーのコピーをメモリに保持できるSSH以外のソフトウェアについては考えていません。まあ、それはあなたがSSH秘密鍵をディスク上で暗号化しておくことを前提としています。 SSH秘密鍵をディスク上で暗号化しない場合は、OpenSSL TLSを使用したファイル転送またはバックアッププログラムを使用して、ネットワーク経由でホームディレクトリ（~/.ssh/id_rsaを含む）をコピーまたはバックアップした可能性がありますまたは他のSSH秘密鍵）、SSH秘密鍵の暗号化されていないコピーがメモリにある可能性があります。次に、暗号化されていないSSH秘密キーを悪意のあるサーバーにバックアップしている場合、おそらくHeartbleedよりも大きな心配事があります。 :-)
「2番目に、Heartbleedの悪用により、脆弱なOpenSSL TLS/DTLSピアがランダムな64kBのメモリを返しますが、ほぼ確実に、そのOpenSSLを使用するプロセスがアクセスできるメモリに制限されます。」
マシンが危険にさらされた場合、sshを含め、その上にあるものをどのように信頼できますか？ heartbleed.comから
「実際には何が漏れていますか？
攻撃者の観点から、独自のサービスのいくつかをテストしました。私たちは痕跡を残さずに外から攻撃しました。特権情報や資格情報を使用せずに、X.509証明書、ユーザー名とパスワード、インスタントメッセージ、電子メール、ビジネスに重要なドキュメントと通信に使用される秘密鍵を自分から盗むことができました。 」
誰かがパスフレーズのない秘密鍵を悪意のないものと想定したサーバーに置いた可能性があります...しかし、そうであることが判明しました。 b/c SSLバグにより、ユーザーのパスワードを許可しました。「Sudo」を持っているユーザー...これはおそらく問題ではありません......
人々は時々クレイジーなことをします
http://blog.visionsource.org/2010/08/28/mining-passwords-from-public-github-repositories/