Se supone que debo acceder a un servidor para vincular los servidores de puesta en marcha y en vivo de una empresa en nuestro bucle de implementación. Un administrador de su lado configuró las dos instancias y luego creó un usuario en el servidor para que podamos usar SSH como. A esto estoy acostumbrado.
En mi mente, ahora lo que sucedería es que les enviaría mi clave pública que podría colocarse dentro de su carpeta de claves autorizadas. Sin embargo, me enviaron un nombre de archivo id_rsaque contiene dentro del archivo -----BEGIN RSA PRIVATE KEY-----por correo electrónico. ¿Esto es normal?
Miré a mi alrededor y puedo encontrar toneladas de recursos para generar y configurar mis propias claves desde cero, pero nada sobre comenzar desde las claves privadas del servidor. ¿Debo usar esto para generar alguna clave para mí o para mí?
Le pediría directamente al administrador del sistema, pero no quiero parecer un idiota y perder el tiempo de todos entre nosotros. ¿Debo ignorar la clave que me envió y pedirles que pongan mi clave pública dentro de su carpeta autorizada?
-----BEGIN RSA PRIVATE KEY-----el correo electrónico es lo siguiente que da miedo después de ver a un usuario nombrado'); DROP DATABASE;--en su tabla de nombre de usuario.'); DROP DATABASE;--como un nombre de usuario en la tabla de base de datos - que muestra que ha estado escapando de entrada de usuario correctamenteRespuestas:
Lo que está "en su mente" como lo que debería suceder ahora es correcto.
El correo electrónico no es un canal seguro de comunicación, por lo que desde el punto de vista de la seguridad adecuada, usted (y ellos) deben considerar que esa clave privada está comprometida.
Dependiendo de su habilidad técnica y de lo diplomático que quiera ser, podría hacer varias cosas diferentes. Yo recomendaría uno de los siguientes:
Genere su propio par de claves y adjunte la clave pública a un correo electrónico que les envíe, diciendo:
Agradézcales y pregúnteles si se oponen a que instale su propio par de claves, ya que la clave privada que han enviado debe considerarse comprometida después de haber sido enviada por correo electrónico.
Genere su propio par de claves, use la clave que le enviaron para iniciar sesión por primera vez y use ese acceso para editar el
authorized_keysarchivo para contener la nueva clave pública (y elimine la clave pública correspondiente a la clave privada comprometida).En pocas palabras: no parecerás un idiota. Pero, el otro administrador podría verse como un idiota muy fácilmente. La buena diplomacia podría evitar eso.
Edite en respuesta a los comentarios de MontyHarder:
Ninguno de mis cursos de acción sugeridos implica "arreglar las cosas sin decirle al otro administrador lo que hizo mal"; Lo hice sutilmente sin tirarlo debajo del autobús.
Sin embargo, agregaré que también haría un seguimiento (cortésmente) si no se captaran las pistas sutiles:
fuente
Sí, eso es exactamente lo que debes hacer. El punto con las claves privadas es que son privadas , lo que significa que solo usted tiene su clave privada. Como recibió esa clave del administrador, él también la tiene. Para que pueda hacerse pasar por ti en cualquier momento que quiera.
Si la clave le fue enviada a través de un canal seguro o no es irrelevante: incluso si ha recibido su clave privada en persona, eso no cambiaría nada. Aunque estoy de acuerdo con los comentarios de que el envío por correo electrónico de claves de criptografía sensibles es la guinda del pastel: su administrador ni siquiera pretende que haya algún tipo de política de seguridad.
fuente
/var/log/secureo similar , estoy bastante seguro de que el truco espacial no engañará a este.Para mí, parece que el administrador generó un par de claves privadas / públicas para usted, agregó la clave pública a las claves autorizadas y le envió la privada. De esta manera, solo tiene que usar esta clave privada para sus sesiones ssh con el servidor. No es necesario generar un par de claves usted mismo o enviar al administrador una clave pública a su clave privada posiblemente corrupta (siempre piense en el peor de los casos: P).
Sin embargo, no confiaría en la clave privada que se le envió por correo no cifrado.
Mi enfoque sería: usar la clave privada para iniciar sesión una vez, agregar su propia clave pública a las claves autorizadas en el servidor (reemplazando la clave pública original) y desechar esta clave privada de correo electrónico. Luego, puede agradecer al administrador que le haya proporcionado la clave privada, pero preferiría que dicha información / claves no se envíen por correo electrónico (/ en absoluto).
fuente
-ien la línea de comando para elegir qué clave privada usar.authorized_keys(después de agregar + probar el suyo).