Un amigo mío logró exponer tanto el archivo id_rsa como el archivo id_rsa.pub desde su servidor a través de apache. Le mencioné que se trata de un grave problema de seguridad, pero lo descartó como si no fuera gran cosa. Ya que no tengo suficiente conocimiento de seguridad para explicarle por qué esto es malo, ¿puede alguien ayudarme aquí? O tal vez mi amigo tenga razón y no sea tan malo como me imagino?
Supongo que estos archivos son para "su clave SSH" como cliente.
Revelar la clave pública ( id_rsa.pub ) no tiene ninguna consecuencia: cuando la llamamos clave pública , lo decimos en serio. La clave privada ( id_rsa ) es, por supuesto, el problema.
La forma en que utiliza, como cliente, su clave privada, es insertar la clave pública correspondiente en el servidor, en el .ssh/authorized_keys de la cuenta de destino. Cuando la clave pública está en este archivo, quienquiera que conozca la clave privada puede iniciar sesión en el servidor con ese nombre. Así es como funcionan las claves públicas / privadas en el lado del cliente en SSH.
Básicamente, hay tres razones posibles y racionales que le permitirían a tu amigo ignorar la divulgación de su archivo id_rsa :
Tal vez nunca presionó la clave pública en ninguna parte. Cuando inicia sesión en un servidor, lo hace escribiendo la contraseña de su cuenta para ese servidor, siempre. Si su par de claves nunca se usa , revelar la clave privada es inofensivo. Pero entonces, ¿por qué tendría ese par de claves?
Posiblemente, todos los servidores a los que se conecta, con autenticación de clave privada, están ubicados en una red privada, con solo usuarios no hostiles y fuerte aislamiento del mundo exterior.
Es concebible que la clave privada esté protegida por una contraseña (o "frase de contraseña" en la terminología SSH), lo que significa que realmente está cifrada con una clave derivada de la contraseña; y tu amigo tiene una gran confianza en la fortaleza de su contraseña.
Tenga en cuenta que incluso si la clave privada está desprotegida (o protegida con una contraseña adivinable) y otorga acceso a algunos servidores a los que pueden acceder los atacantes, lo que los atacantes pueden hacer es iniciar sesión en estos servidores con el nombre de su amigo (que ya es un gran problema). Esto NO otorga a los atacantes el poder de realizar un ataque Man-in-the-Middle ( MitM es una doble imitación, por lo que un atacante MitM debe conocer las claves privadas tanto en el cliente como en el servidor); no pueden descifrar las sesiones pasadas o futuras que escucharon, ni alterar los datos de las sesiones en curso (en particular, las claves asimétricas en SSH se utilizan para la autenticación, pero el intercambio de claves utiliza Diffie-Hellman ).
- Autenticación / Control de acceso
Las personas que poseen sus credenciales podrían iniciar sesión en los sistemas haciéndose pasar por él.
- No repudio
Otros podrán firmar mensajes como él, y no podrá negar el envío de ellos.
- Confidencialidad
Todas sus comunicaciones privadas se pueden descifrar y filtrar.
- Integridad
Los documentos anteriores pueden estar ya firmados / renovados nuevamente, ya que ya no son enteros como en la última versión anterior al incidente.
En pocas palabras: tiene que revocarlo cuanto antes y conseguir uno nuevo.
Las claves privadas SSH generalmente están cifradas (de manera predeterminada) con un cifrado simétrico fuerte. En algunas circunstancias (por supuesto, no el uso de producción) puede ser viable tener esas claves en una ubicación compartida accesible para facilitar la operación. Esto apenas reduce la fuerza de la clave a la fuerza de la contraseña con la que está cifrada, lo que puede ser tolerable, dependiendo del patrón de uso de las claves mencionadas y de los servidores a los que pertenecen también.
Solo tenía que jugar al abogado del diablo aquí;)
Lea otras preguntas en las etiquetas certificates ssh