Consejos para administrar claves SSH


13

¿Cuál es la mejor práctica que ha encontrado para administrar muchos pares de claves SSH?

Utilizo SSH para conectarme a varios sistemas, tanto en casa como en el trabajo. Actualmente tengo una colección bastante pequeña y manejable de pares de llaves tanto para el trabajo como para el hogar. Tengo un script que genera un par de claves con nombre para evitar confusiones.

Mi red doméstica está compuesta por mi computadora portátil (ubuntu), dos computadoras de escritorio (arranque dual ubuntu / fedora, arranque dual fedora / windows) y un sistema de medios (ubuntu). En el trabajo tengo mi computadora portátil personal (que uso para trabajar desde casa), mi computadora de escritorio (fedora), un sistema de producción (RHEL) y una computadora portátil con Windows (suspiro) y una VM (fedora). Todo bien hasta ahora.

(No tengo ningún interés en poner mi par de claves de inicio en mi sistema de trabajo o mi par de claves de trabajo en mis sistemas de inicio. Y tenemos cuentas de usuario virtuales para mecanizar las transferencias de archivos con otros sistemas, donde la clave privada debe residir en la máquina de producción, para transferir archivos entre otros sistemas).

Pero ahora viene Hadoop, un gran grupo de más de 100 sistemas, y con eso más complejidad, más usuarios y más pares de claves. Ahora necesito administrar las llaves.

(Necesito aclararlo. Soy un desarrollador de software que consulta a un cliente que está implementando un clúster de Hadoop. Necesitan administrar las claves. Habrá muchas personas que accedan al clúster y necesiten colocar sus claves públicas en el sistema. Como residente Sabio de Linux, me pidieron ayuda. Aconsejé contratar a un administrador del sistema, pero hasta que lo hagan, estoy ayudando)

Cuando necesito publicar la clave pública en un sistema remoto, todas las páginas web "prácticas" sugieren sobrescribir (>) (destruir las claves existentes) o agregar (>>) (lo cual es bueno, conserva las claves existentes) . Pero creo que preservar cada clave pública en la máquina de destino por separado, y combinarlas sería mejor. Estoy buscando consejos

¿Cuál es la mejor práctica que ha encontrado para administrar muchas claves?

¡Gracias!


Editar: Un aspecto es la necesidad de colocar claves en muchos sistemas, y el CRUD concomitante (crear, leer, actualizar, eliminar / deshabilitar) para usuarios específicos, lo que significa que es necesario poder identificar qué claves pertenecen a qué usuarios.


¿Estás hablando de pares de claves de usuario o host? sshfpresuelve el problema de la clave de host colocando las firmas de la clave pública en DNS. Para las credenciales de usuario, es posible que desee buscar certificados OpenSSH o usar algo como Spacewalk o títere para guardar todos los pares de claves en una ubicación central e implementarlos según sea necesario. Parece que probablemente desee este último ya que simplemente configuraría el nuevo servidor como cliente y luego implementaría la última versión del archivo.
Bratchley

Tengo otra computadora portátil (fedora), para discos de red MyBook Live (ejecutando Linux), dos computadoras de escritorio integradas que esperan discos duros, y planes para dos más para construir un clúster de hadoop en casa (aprendizaje). Sí, necesito entender la gestión de claves.
ChuckCottrill

Respuestas:


12

En general, no debe tener más de 1 clave por máquina cliente (énfasis en "generalmente"). No estoy seguro si entiendo su pregunta correctamente, pero si está diciendo que tiene una clave separada para cada sistema remoto, entonces definitivamente lo está haciendo mal.

Ssh utiliza criptografía de clave pública. La clave que instale en el sistema remoto es la clave pública, no hay absolutamente ningún daño en reutilizar esta clave en otro lugar. Es la clave privada que debe protegerse y permanece en su sistema personal.

También es una buena idea que la clave privada resida en un solo cliente, no compartido. Esto es para que si un cliente se ve comprometido, puede revocar solo esa clave.


Ahora, si está preguntando cómo puede llevar su clave pública a cientos de sistemas, hay un par de formas de hacerlo.

La forma más común es mediante el uso de directorios de inicio compartidos. Tener un NFS (u otro sistema de archivos de red) montado (o montado automáticamente) en todos los sistemas.

La otra forma es aprovechar una nueva característica en ssh. Es una directiva de configuración llamada AuthorizedKeysCommand. Básicamente es un comando que sshd se ejecutará cada vez que necesite buscar una clave pública. El comando simplemente escribe la clave pública del usuario que se está consultando en su STDOUT. Esto se usa principalmente cuando no ha montado directorios de inicio, pero todavía tiene un servidor de autenticación central ( FreeIPA se aprovecha de esto).

Por supuesto, puede hacer otras cosas como cron job rsync /homedesde un servidor central. Pero esa no es una práctica común.


Tengo 8 máquinas en casa y un número variable de "servidores" en la nube (escalados según sea necesario). Sería una tontería tener 300 claves de cliente cuando escalo hasta 300 instancias de servidor. Entonces tengo 16 claves públicas (2 usuarios por cada uno de 8 hosts). Para máquinas duras, presiono las teclas cada 3 meses. Para las instancias en la nube, están integradas en la imagen personalizada.
Skaperen

2

Cuando necesito publicar la clave pública en un sistema remoto, todas las páginas web "prácticas" sugieren sobrescribir (>) (destruir las claves existentes) o agregar (>>) (lo cual es bueno, conserva las claves existentes) . Pero creo que preservar cada clave pública en la máquina de destino por separado, y combinarlas sería mejor. Estoy buscando consejos. A

no veo ninguna ventaja en el almacenamiento de las claves públicas tanto en .ssh/authorized_keysy en un archivo separado.

si echa un vistazo a las claves reales almacenadas en el archivo * Authorized_keys *, verá que ya contienen metainformación legible por humanos sobre el origen de la clave. Por ejemplo, la clave pública para user@foogeneralmente tiene una entrada como:

ssh-rsa AAAAB3Nza...LiPk== user@example.net

por lo tanto, es muy fácil inspeccionar / extraer / eliminar ciertas claves (adjuntas a ciertos usuarios) del archivo * Authorized_keys *.

la identificación de usuario es realmente un campo de "comentario" de forma libre, por lo que puede incluir cualquier información que considere necesaria para identificar la clave dada.

en cualquier caso, solo debe generar pares de claves para los "usuarios" que necesitan acceder a recursos remotos. lo más probable es que no necesite iniciar sesión desde cada host hadoop entre sí. más bien tendrá algunas máquinas de administración, que necesitan acceder a todos los hosts hadoop. solo necesita un único par de claves por máquina de administración e instale cada clave pública en todos los hosts hadoop.


Cada usuario generará sus propias claves, creo que está diciendo que cada usuario debe proporcionar username @ hostname como parte del origen de la clave. Lo que significa que se debe proporcionar un script que haga cumplir ese nombre de usuario @ nombre de host, ¿verdad?
ChuckCottrill

depende de cómo creen sus claves; por ejemplo ssh-keygen, agregará un comentario de la forma user@host; otros generadores de claves (como el que viene con masilla) podrían no hacerlo. pero sí, debería ser trivial hacer un pequeño script que se asegure de que cada clave tenga un campo de comentario que identifique una combinación usuario / host.
umläute

1

OpenSSH reciente permite obtener claves ssh de LDAP, consulte 'AuthorizedKeysCommand' en la página de manual de sshd_config . Personalmente, preferiría los certificados OpenSSH, no las claves, consulte http://blog.habets.pp.se/2011/07/OpenSSH-certificates . Puede administrar las claves con cualquier administrador de configuración como cfengine, puppet, chef, salt ...


0

Otra forma de usar que es súper fácil de implementar y permite un poco más de flexibilidad en términos de agregar múltiples usuarios. https://userify.com/

Le permite definir diferentes grupos de servidores y tener claves para diferentes usuarios habilitadas o deshabilitadas para esos servidores.

Instalación y administración súper simples.

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.