Entonces, estoy obteniendo información conflictiva de los miembros de mi equipo. La premisa es que, si un atacante puede seguir solicitando fragmentos de memoria de 64 kb desde mi servidor, podría obtener toda la huella de memoria de mi servidor, y así obtener la clave privada que usé de la memoria.
Entonces, ¿la clave SSH privada que solía iniciar sesión está almacenada en la memoria? ¿Tengo que preocuparme por mis claves SSH?
No. OpenSSH usa un subconjunto muy limitado de la biblioteca OpenSSL, y ese subconjunto no incluye el código involucrado en la vulnerabilidad de Heartbleed (o cualquiera de los otros códigos SSL / TLS, en este caso).
Además, la vulnerabilidad Heartbleed no permite que una aplicación lea la memoria fuera de su espacio de direcciones, por lo que, por ejemplo, un servidor web vulnerable no puede acceder a las claves de un servidor SSH.
Cuando inicia sesión con SSH, su cliente tiene la clave privada y el servidor tiene la clave pública. Por lo tanto, ninguna vulnerabilidad en el servidor puede filtrar su clave privada, ya que el servidor no la tiene.
El servidor no puede usar Heartbleed para obtener la clave privada de su cliente, ya que es una implementación de SSH, y solo las conexiones OpenSSL SSL / TLS en la versión 1.0.1 a 1.0.1f son vulnerables. Ninguna otra implementación de ningún tipo tiene este problema, incluidas todas las implementaciones de SSH.
Ahora, si el servidor tiene sus propias claves SSH privadas en la memoria en algún lugar, entonces se requerirá una investigación más profunda ... pero sería más barato corregir la vulnerabilidad y luego volver a generar el par de claves SSH del servidor, ya que no hay Autoridad certificadora a pagar para firmar claves SSH!
En general, no, pero depende de qué tan paranoico seas y de los aspectos específicos del sistema vulnerable.
Como han dicho otros, las teclas openssh no pueden ser filtradas directamente por un servidor openssl que sangra el corazón. Pero si la información se filtra (como, por ejemplo, un inicio de sesión https), quizás un atacante podría usar esa contraseña para acceder al sistema. A partir de ahí, su clave privada ssh del usuario es segura si no está en el sistema de archivos local. Pero si el atacante usa esa información para obtener acceso a la raíz, ocurren muchos más problemas (por supuesto). Por ejemplo, ahora podrían descifrar su tráfico ssh y, si tenía un agente ssh habilitado en el sistema, el atacante ahora podría ssh a otros sistemas como usted, pero no recuperar la clave privada original si no está en ese sistema.
Lea otras preguntas en las etiquetas ssh openssl heartbleed