El administrador del servidor me envió una clave privada para usar. ¿Por qué?

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?

— Toby
fuente

No lo llamaría normal o sensato, pero dado que tiene la clave privada (suponiendo que ya la hayan agregado como autorizada), puede usarla como usaría cualquier otra clave privada. No necesita la clave pública correspondiente, pero si lo desea, siempre puede generarla: askubuntu.com/a/53555/158442

— muru

Superar -----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.

— Dmitry Grigoryev

6262

@DmitryGrigoryev nada miedo de ver '); DROP DATABASE;--como un nombre de usuario en la tabla de base de datos - que muestra que ha estado escapando de entrada de usuario correctamente

— HorusKol

Ciertamente no puede 'usarlo como usaría cualquier otra clave privada'. Este no es privado. Ergo no puede cumplir la función para la que fue creado. Debe desecharse y el administrador de UNIX lo castiga severamente. @muru

— usuario207421

Cualquiera que tenga esta clave privada tiene acceso a los nuevos servidores. Presumiblemente, el administrador tiene acceso de todos modos sin necesidad de la clave, ya que pudo configurar el servidor, por lo que no hay una amenaza adicional de acceso no autorizado por parte de él. Sin embargo, como esta es su clave, ahora puede hacerse pasar por usted de manera confiable. También existe la posibilidad de que alguien que no sea usted lea el correo electrónico, y luego pueda hacerse pasar por usted también.

— user253751

Respuestas:

116

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.

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:

¡Gracias! Dado que el correo electrónico no es un método de distribución seguro para las claves privadas, ¿podría poner mi clave pública en su lugar? Está adjunto.
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:

Hola, vi que no respondiste a mi comentario sobre el correo electrónico como un canal inseguro. Quiero estar seguro de que esto no volverá a suceder:

¿Entiendes por qué estoy haciendo este punto sobre el manejo seguro de claves privadas?

Mejor,

Toby

— Comodín
fuente

+1 La mejor respuesta. Y agregaría: tenga especial cuidado ya que este administrador de sistemas ha demostrado ser incompetente. Mejor cubra su espalda cuando (y no si ) él / ella arruinará el servidor para siempre.

— dr01

Gracias. Utilicé algunas frases delicadas y envié mi clave pública. Todo parece resuelto, pero desautorizaré la clave que me envió ahora.

— Toby

No es que el otro administrador "pueda verse como un idiota". Es que el otro administrador hizo algo idiota. Solo puedo pensar en un escenario en el que una clave privada se debe compartir entre las máquinas, y es donde se accede a un grupo de servidores a través del mismo nombre (resolución DNS redonda, etc.) y debe presentar la misma clave de host SSH para que los procesos automatizados aceptarán que son ese nombre. Y en ese caso, la misma persona sería la administradora de todos los servidores y se encargaría de las transferencias sin la participación de una parte externa.

— Monty Harder

@zwol En mi trabajo, tenemos una filosofía de "no culpar" que entiende que cometeremos errores, pero considera que es una alta prioridad no cometer el mismo error dos veces. Pero para no cometer el mismo error dos veces, debes saber que es un error, por eso no puedo votar las respuestas sugiriendo que el OP simplemente arregla las cosas sin decirle al otro administrador lo que hizo mal. Elegí llamar al error 'idiota' en lugar de llamar a los nombres de administrador precisamente por la razón que delineas. (Pero no estoy seguro de que su paréntesis final articule una distinción significativa).

— Monty Harder

@LightnessRacesinOrbit, sospecho que puede tener una comprensión incompleta del significado de "diplomacia". ¿Has intentado aclararlo en un buen diccionario, como el Webster's Third New International Dictionary?

— Comodín

¿Debo ignorar la clave que me envió y pedirles que pongan mi clave pública dentro de su carpeta autorizada?

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.

— Dmitry Grigoryev
fuente

Y dado que el OP no tiene forma de saber qué tan segura es la máquina del administrador (según la historia, presumiblemente muy insegura), debe asumir que la clave privada también (o será) también se filtró a otras personas. Enviar una clave privada por correo electrónico es solo un hecho adicional para la falta de información de Infosec.

— dr01

Puede suponer que un administrador que pueda crear usuarios no necesitará su clave privada para hacerse pasar por usted.

— Max Ried

@MaxRied Eso puede ser difícil de hacer con los registros de seguridad adecuados. Con su clave privada ni siquiera necesita burlarse de los registros. Es como tener la capacidad de restablecer su contraseña frente a conocer su contraseña.

— Dmitry Grigoryev

@DmitryGrigoryev Él siempre podría agregar otra clave a su archivo de claves autorizadas ...

— Max Ried

@MaxRied Me refería /var/log/secureo similar , estoy bastante seguro de que el truco espacial no engañará a este.

— Dmitry Grigoryev

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).

— usuario204269
fuente

@Toby La única razón por la que puedo imaginar que envíen la clave privada es que no entienden las herramientas que están utilizando. Y puede usar -ien la línea de comando para elegir qué clave privada usar.

— Kasperd

@kasperd La razón que puedo imaginar es un administrador de sistemas con exceso de trabajo que ha decidido que los riesgos de enviar una clave privada por correo electrónico son mayores que la molestia de tratar de explicar a los usuarios menos expertos en tecnología cómo generar correctamente un par de claves y enviar el clave pública de nuevo.

— mattdm

Gran punto que puede solucionar esto usted mismo. Es mejor hacerlo usted mismo de inmediato que esperar a que el administrador instale la clave pública para un nuevo par de claves. Evitar el uso de la clave privada que ya no es secreta no ayuda en nada; solo le da a cualquier espía potencial más tiempo para usarlo antes de que pueda ingresar y eliminarlo authorized_keys(después de agregar + probar el suyo).

— Peter Cordes

@mattdm Eso ... es completamente lógico, pero aterrador. Una persona que no puede generar un par de claves y enviarme la clave pública probablemente no lo hará mucho mejor con una clave privada que le doy.

— Monty Harder

@mattdm, es justo, pero como fui yo quien le pidió que hiciera todo esto, me resulta difícil creer que pensara que no sé cómo conectarme con ssh. En todo caso, los pasos que dio fueron más confusos, ya que solo conozco la forma común básica de usar las claves públicas. : x

— Toby