¿El mejor sistema para administrar claves ssh? [cerrado]


42

Tengo varias computadoras cliente (es decir, laptops, computadoras de escritorio, etc.), y me conecto a varias máquinas de servidor que administro, y me conecto a todas ellas a través de SSH. Puedo imaginar varios esquemas de administración de claves ssh que tendrían sentido, y tengo curiosidad por saber qué hacen los demás.

Opción 1: un par de claves público / privado global.

Generaría un par de claves público / privado, y pondría la clave privada en cada máquina del cliente, y la clave pública en cada máquina del servidor.

Opción 2: un par de llaves por máquina servidor.

Generaría un par de claves en cada máquina del servidor y pondría cada clave privada en mis máquinas cliente.

Opción 3: un par de claves por máquina cliente.

Cada máquina cliente tendría una clave privada única, y cada máquina del servidor tendría las claves públicas para cada máquina cliente desde la que me gustaría conectarme.

Opción 4: un par de claves por par cliente / servidor

¿Totalmente al agua?

¿Cuál de estos es el mejor? ¿Hay otras opciones? ¿Qué criterios utiliza para evaluar la configuración correcta?

Respuestas:


33

Uso la Opción 3: un par de claves por máquina cliente y tiene más sentido para mí. Estas son algunas de las razones:

  • Si un cliente se ve comprometido, entonces esa clave (y solo esa clave) debe eliminarse de los servidores.
  • Es lo suficientemente flexible como para decidir a qué puedo acceder desde dónde, sin otorgar acceso general a todos los servidores de todos los clientes.
  • Muy conveniente. Solo hay 1 clave para ssh-add, sin confusión.
  • Fácil de configurar y administrar sobre la Opción 4

La opción 4 es buena, pero es demasiado trabajo. La opción 3 lo lleva al 98% allí con mucha menos molestia.


44
No veo el punto de la Opción 4. No sirve para nada.
niXar

26

Utilizo una solución que es un poco más complicada pero muy versátil, ya que quiero mantener cierta separación en las claves de identidad SSH utilizadas para los servidores de mi red doméstica, los servidores de oficina, los servidores de red de clientes de consulta y otros sistemas diversos en los que tengo cuentas.

Ahora, dicho esto, trabajo desde estaciones de trabajo Linux casi exclusivamente, así que tengo una memoria USB que se configura usando el cifrado LUKS y mi administrador de ventanas X11 junto con el demonio HAL detectan la unidad cifrada LUKS y solicitan la frase de descifrado cuando se inserta e intenta ser montado Al almacenar esto en una unidad encriptada como lo hago, nunca almaceno mis claves SSH en ninguna estación de trabajo.

Luego tengo la siguiente configuración en mi ~/.ssh/configarchivo:

Host *
    Protocol 2
    IdentityFile %d/.ssh/keys.d/id_rsa.%l
    IdentityFile %d/.ssh/keys.d/id_dsa.%l
    IdentityFile %d/.ssh/keys.d/%u@%l

El % d se traduce a ser el directorio personal del usuario mediante OpenSSH y en el ~ / .ssh directorio He creado keys.d como un enlace a la ruta del directorio en la unidad USB cifrada cuando se monta correctamente.

La expresión % l se traduce como el nombre de host de las máquinas del cliente local y % u se traducirá al nombre de usuario del cliente local.

Lo que hace esta configuración es permitir que SSH busque una clave usando 3 expresiones diferentes. Por ejemplo, si el nombre de usuario de jdoemi cliente local era y el nombre de mi máquina del cliente local examplehost, se vería en el siguiente orden hasta que encontrara una clave que existiera y que fuera aceptada por el servidor remoto.

/home/jdoe/.ssh/keys.d/id_rsa.examplehost
/home/jdoe/.ssh/keys.d/id_dsa.examplehost
/home/jdoe/.ssh/keys.d/jdoe@examplehost

Incluso podría usar la expresión % r para buscar una clave específica para el nombre de usuario del servidor remoto o % h para el nombre de host del servidor remoto al igual que se usaron % u y % l .

Actualización: ahora en realidad utilizo el gnuPG gpg-agent con compatibilidad ssh-agent para simplemente leer y usar la clave de autenticación de mi tarjeta inteligente OpenPGP v2.


Wow, gran solución, gracias! Me encanta la configuración universal en ~ / .ssh / config
slacy

Está demostrado que es bastante conveniente mantener las cosas separadas para el trabajo, los servidores de red de clientes personales y de consultoría ... No quiero mezclar la autenticación entre ellos, pero también quiero que sea fácil para mí.
Jeremy Bouse

¡Asombroso! Realmente me encanta este.
balu

Supongo que está utilizando diferentes llaves USB para diferentes máquinas cliente. De lo contrario, ¿cuál es el punto en claves separadas si todas están almacenadas en el mismo lugar? En caso de incumplimiento, deberá revocarlos todos. A menos que (y probablemente) me falte algo, esto parece complicar las cosas.
Halil Özgür

@ HalilÖzgür, Sí, consulto y no siempre quiero usar la misma clave. Como la clave USB está encriptada y no está conectada a ninguna computadora, a menos que la necesite para establecer una conexión, no hay preocupación de que el servidor se haya violado y la frase de contraseña para descifrar el sistema de archivos de la unidad sea lo suficientemente larga como para hacer que la revocación de claves sea lo suficientemente simple.
Jeremy Bouse

6

Eliminaría sus dos opciones 1 (de las cuales sospecho que se suponía que una era la opción 2 ;-) porque las claves privadas son datos confidenciales, y tiene sentido mantenerlas en el menor número de lugares posible. Yo personalmente nunca copiaría una clave privada de una computadora a otra (o incluso de un archivo a otro en la misma computadora), excepto tal vez para hacer copias de seguridad. Aunque a diferencia de la mayoría de las claves de cifrado, si una clave SSH se pierde, no es el fin del mundo (solo cree una nueva, no perderá ningún dato).


Sí, renombrado a una "Opción 2" adecuada. Me gusta la regla de "nunca copiar una clave privada". Esa es una buena regla.
Slacy


1

Opcion 3.

Esto también le permite controlar a qué servidores puede acceder un cliente. por ejemplo, si el cliente X necesita acceso a los servidores A y B, pero C o D, usted copia su clave pública solo a esos hosts.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.