システムがHeartbleedに対して脆弱である場合、SSHキーについて心配する必要がありますか？
チームのメンバーから矛盾する情報を受け取っています。前提は、攻撃者がサーバーから64 kbのメモリチャンクを要求し続けることができる場合、サーバーのメモリフットプリント全体を取得し、使用していた秘密キーをメモリから取得する可能性があることです。
では、ログインに使用した秘密のSSHキーはメモリに保存されますか？ SSHキーについて心配する必要がありますか？
いいえ。OpenSSHはOpenSSLライブラリの非常に限られたサブセットを使用しており、そのサブセットにはHeartbleedの脆弱性に関連するコード（または、他のSSL/TLSコード）は含まれていません。
さらに、Heartbleedの脆弱性により、アプリケーションはアドレス空間外のメモリを読み取ることができないため、たとえば、脆弱なWebサーバーがSSHサーバーにアクセスしてキーを取得することはできません。
十分に繰り返すことはできません:-)
いいえしかし！ホストマシンで他のサービスを実行する場合、たとえばOpenVPNは、OpenSSLを使用します。OpenSSLは脆弱であり、悪用される可能性があります。
SSHでログインすると、クライアントには秘密鍵があり、サーバーには公開鍵があります。したがって、サーバーに秘密鍵がないため、サーバーの脆弱性によって秘密鍵が漏洩することはありません。
サーバーはHeartbleedを使用してクライアントから秘密鍵を取得できません。これはSSHの実装であり、バージョン1.0.1から1.0.1fのOpenSSL SSL/TLS接続のみが脆弱です。すべてのSSH実装を含め、他のどのタイプの実装にもこの問題はありません。
さて、サーバーがメモリ内の独自のプライベートSSHキーをどこかに持っている場合、より深い調査が必要になります...しかし、認証局がないため、脆弱性を修正してからサーバーのSSHキーペアを再生成する方が安上がりです。 SSHキーに署名するために支払う！
一般的にはありませんが、それはあなたがどれだけ妄想的であるか、および脆弱なシステムの詳細に依存します。
他の人が言ったように、opensshキーは心血を流すopensslサーバーによって直接漏洩することはできません。しかし、情報が漏えいした場合（たとえば、httpsユーザーのログインなど）、攻撃者はそのパスワードを使用してシステムにアクセスする可能性があります。そこから、ローカルファイルシステムにない場合、ユーザーのssh秘密鍵は安全です。しかし、攻撃者がその情報を使用してルートアクセスを取得すると、さらに多くの問題が発生します（もちろん）。たとえば、SSHトラフィックを復号化できるようになり、システムでSSHエージェントが有効になっている場合、攻撃者は他のシステムにSSHで接続できますが、元の秘密鍵がシステムにない場合は復元できません。