Est-ce que Heartbleed affecte les clés ssh?

Non, Heartbleed n'affecte pas vraiment les clés SSH, donc vous n'avez probablement pas besoin de remplacer les clés SSH que vous utilisez.

Tout d'abord, SSL et SSH sont deux protocoles de sécurité différents pour deux utilisations différentes. De même, OpenSSL et OpenSSH sont également deux logiciels complètement différents, malgré les similitudes de leurs noms.

Deuxièmement, l'exploit Heartbleed fait en sorte que le voleur OpenSSL TLS / DTLS vulnérable renvoie un 64kB de mémoire aléatoire, mais il est presque certainement limité à la mémoire accessible à ce processus OpenSSL. Si ce processus utilisant OpenSSL n'a pas accès à votre clé privée SSH, il ne peut pas le filtrer via Heartbleed.

En outre, vous ne metz généralement que votre clé publique SSH sur les serveurs sur lesquels vous utilisez SSH pour vous connecter et, comme le nom l'indique, une clé publique est une clé que vous pouvez publier. Peu importe qui le connaisse. En fait, vous souhaitez que le public connaisse votre clé publique correcte.

Merci à @Bob de souligner que la vulnérabilité peut affecter les applications clientes qui utilisent des versions vulnérables d'OpenSSL comme leur bibliothèque TLS / DTLS côté client. Donc, si, par exemple, votre navigateur Web ou votre client VPN basé sur SSL utilisait une version vulnérable d'OpenSSL et connecté à un serveur malveillant, ce serveur malveillant pourrait utiliser Heartbleed pour voir des extraits aléatoires de la mémoire de ce logiciel client. Si cette application client, pour une raison quelconque, avait une copie de vos clés privées SSH dans la mémoire, cela pourrait être transmis par Heartbleed.

Au-dessus de ma tête, je ne pense à aucun logiciel en dehors de SSH qui pourrait avoir une copie de votre clé privée SSH non cryptée en mémoire. Eh bien, cela suppose que vous gardez vos clés privées SSH chiffrées sur le disque. Si vous ne gardez pas vos clés privées SSH chiffrées sur le disque, alors je suppose que vous auriez pu utiliser un programme de transfert de fichiers ou de sauvegarde OpenSSL TLS pour copier ou sauvegarder votre répertoire personnel sur le réseau (y compris votre ~/.ssh/id_rsa ou une autre clé privée SSH), il pourrait avoir une copie non cryptée de votre clé privée SSH en mémoire. Encore une fois, si vous sauvegardiez votre clé privée SSH non chiffrée sur un serveur malveillant, vous avez probablement eu de plus gros soucis que Heartbleed. 🙂

"Deuxièmement, l'exploit Heartbleed fait en sorte que le voleur OpenSSL TLS / DTLS vulnérable renvoie un 64kB de mémoire aléatoire, mais il est presque certainement limité à la mémoire accessible à ce processus OpenSSL".

Si la machine est compromise alors comment pouvez-vous faire confiance à quoi que ce soit, y compris ssh? De heartbleed.com

"Quelles fuites dans la pratique?

Nous avons testé certains de nos propres services du point de vue de l'attaquant. Nous nous sommes attaqués de l'extérieur, sans laisser de traces. Sans utiliser d'informations privilégiées ou d'informations d'identification, nous avons pu nous renvoyer les clés secrètes utilisées pour nos certificats X.509, nos noms d'utilisateurs et nos mots de passe, vos messages instantanés, vos courriels et vos documents et nos communications stratégiques. "

Quelqu'un pourrait avoir mis une clé privée, sans phrase de passe, sur un serveur qu'ils ont supposé qu'il n'était pas malveillant … mais s'est avéré être. B / c bug SSL a permis le mot de passe d'un utilisateur, un utilisateur qui avait 'sudo' … c'est probablement pas un problème … mais …

Les gens font des choses folles parfois

http://blog.visionsource.org/2010/08/28/mining-passwords-from-public-github-repositories/