Sistema de gestión centralizado para claves SSH?

27

Estamos buscando cambiar a la administración basada en claves de los inicios de sesión SSH, y nos preguntamos si existe algún sistema de administración de claves que nos permita administrar centralmente las claves de acceso en todo el mundo.

Lo ideal es que el sistema permita emitir claves por cliente y revocarlas si es necesario, actualizando las claves de la máquina del servidor sobre la marcha.

¿Alguien sabe de tal sistema, ya sea comercial o de código abierto?

NOTA: Para aclarar, necesitamos la administración de claves para una cantidad bastante grande de servidores en la nube (tipo EC2) y una pequeña cantidad de usuarios de servicios. Supongo que el parche LDAP + sugerido a continuación podría ser el camino a seguir.

ssh cloud keys

— SyRenity
fuente

77

Soy solo yo quien piensa que "las claves privadas y la nube" son como "beber y conducir". Ambos se burlan por separado pero nunca van juntos.

— mailq

1

"Nube" es probablemente la palabra incorrecta: parece que lo que quieren es autenticación centralizada, con consistencia mundial.

— voretaq7

Hola. Exactamente, eso es lo que estamos buscando.

— SyRenity

He estado luchando con este problema con algunos de los entornos híbridos de mis clientes. También está la cuestión de dónde mantener el OPenLDAP o la instancia central en una implementación en la nube. He estado usando webmin de todas las cosas como una herramienta de administración de claves y un libro de cocina de chef para sincronizar las claves con los nodos.

— Tom H

Userify cubre lo que está buscando (consulte serverfault.com/questions/647797/… )

— Jamieson Becker

8

Hay muchas formas de hacerlo. El almacenamiento de claves LDAP se ha mencionado un par de veces, y lo he hecho y funciona, en la medida de lo posible. Sin embargo, LDAP tiene sus propias curiosidades de gestión, que requieren algo de aprendizaje.

Soy un gran admirador de los servidores simples y robustos que tienen dependencias de red externas mínimas para cosas simples como la autenticación de administradores, por lo que me inclino hacia una estrategia de distribución de claves SSH mucho más robusta: tengo el sistema de administración de configuración que se encarga de eso. La clave pública de todos se mantiene en el sistema de gestión de la configuración, y cada vez que la persona necesita poder iniciar sesión, se agrega su clave. El sistema de configuración también sabe eliminar las claves que no están especificadas, por lo que cuando alguien se va o sus claves cambian, es una simple cuestión de eliminar la configuración de la clave y en la próxima ejecución del sistema de configuración, la clave se elimina.

— womble
fuente

Este enfoque es ciertamente bueno, y como señala Womble, tiene la ventaja de que los servidores permanecen en funcionamiento (y accesibles) en caso de que LDAP esté inactivo: cada sistema respaldado por LDAP debería (me atrevo a decir que debe ) al menos un usuario cuyas teclas se eliminan de la manera que describe Womble. La desventaja es que debe realizar una ejecución de configuración para desautorizar a los usuarios. No es un problema para una "cuenta de emergencia" con solo unos pocos usuarios autorizados. Mayor problema para una gran cantidad de cuentas :)

— voretaq7

1

Realmente tiene que tener una manera de activar las ejecuciones de configuración masiva de todos modos, por lo que no debería ser un gran problema hacerlo para un cambio de cuenta.

— womble

Estoy de acuerdo, desafortunadamente, las necesidades / mentalidades del negocio no: la paranoia en muchos lugares (incluida la mía) dicta que los cambios de configuración ocurren durante las horas de descanso, pero el personal nuevo / el personal que sale puede ocurrir en cualquier momento: - /

— voretaq7

1

Entonces, ¿está contento de dejar cosas rotas para un día hábil solo porque no puede ejecutar una inserción de configuración durante el día? El hecho de que sea común no significa que no sea estúpido.

— womble

2

Hola. Entonces, ¿una buena idea sería usar Puppet para esto, por ejemplo?

— SyRenity

23

Los pares de claves deben ser generados por el usuario.

El usuario retiene la mitad privada: nunca debería verla. Si tiene la clave privada de alguien en un formulario donde puede leerla / usarla, está haciendo un error de seguridad.

Se le entrega la mitad pública (por cualquier mecanismo que desee: formulario web, correo electrónico, darme-en-un-CD), para que se centralice como quiera. Algunos lugares almacenan las claves públicas en LDAP. Otros expulsan authorized_keysarchivos usando su sistema de implementación.

En mi entorno, los usuarios que necesitan acceso de shell me dan sus claves públicas. Estas claves se agregan a nuestro sistema LDAP y sshdconsulta las claves públicas enumeradas para cada usuario para autenticarlas, a través del parche de clave pública LDAP .
Cuando alguien necesita agregar una clave adicional o revocar una clave existente, le avisa a un administrador y nosotros nos encargamos de ello. Eventualmente, a medida que escalemos, implementaré un sistema que permita a las personas rotar sus propias claves públicas.

Cada uno de nuestros sitios tiene un par de servidores LDAP, sincronizados con nuestro maestro con replicación LDAP, que mantiene los datos consistentes (y accesibles) en cada ubicación.

Todo lo que he descrito se puede hacer con software de código abierto. También hay productos comerciales que hacen lo mismo.
Debe investigar las opciones disponibles más a fondo y decidir cuál (es) se adapta mejor a su entorno. Si tiene más preguntas (más específicas), probablemente podamos ser más útiles.

— voretaq7
fuente

Básicamente, ¿sugiere utilizar la infraestructura LDAP, con OpenSSH parcheado que funcionará con LDAP? ¿Qué tan bien esto escala en la producción? ¿Puede soportar una gran cantidad de máquinas? Necesitamos admitir solo una pequeña cantidad de usuarios del servicio.

— SyRenity

1

@SyRenity: LDAP admite la replicación y la agrupación por lo que se escala muy bien

— Hubert Kario

@SyRenity Teóricamente puede admitir un número ilimitado de máquinas en un número ilimitado de ubicaciones (piense en "Implementación de Active Directory realmente grande" - AD es básicamente LDAP con algunos accesorios de moda). Para los usuarios de servicios, mi sugerencia es estandarizarlos en su entorno y eliminar los archivos /etc/passwdy estandarizados /etc/group(permite que las máquinas funcionen normalmente y que los servicios asociados se inicien / ejecuten incluso si LDAP no está disponible)

— voretaq7

@ voretaq7 ¿Significa que los usuarios del servicio se gestionarán por separado de LDAP, a través de la gestión de la configuración?

— SyRenity

@SyRenity sí, y lo que es más importante, está disponible para los servicios que los usan si LDAP no funciona . Planifique las fallas o experimentará desastres.

— voretaq7

9

Los pares de claves no deben generarse en ningún lugar sino en la computadora de cada usuario. Las claves privadas se nombran como tales por una razón.

Dicho esto, pude ver un caso de uso para algún tipo de repositorio centralizado de claves públicas de los usuarios. Una opción sería almacenar claves públicas en OpenLDAP: las versiones recientes de OpenSSH pueden leer claves desde LDAP.

— EEAA
fuente

2

¿Está la clave pública de LDAP en OpenSSH mainline ahora? Solo conozco el parche LPK (que puedo garantizar, funciona muy bien). También +1 para mantener las claves privadas privadas.

— voretaq7

@ voretaq7 Creo que escuché que se estaba fusionando con la línea principal, pero aún no lo he verificado. Compartimos directorios de inicio a través de NFS, de modo que nos ocupamos de nuestra distribución de claves.

— EEAA

+1 bueno, no lo sabía. eso me ahorraría muchos problemas. eso está ahora en mi lista de cosas a considerar.

— Tom H

1

Sé que esta es una pregunta un poco más antigua, pero Google la devuelve bastante alta cuando busca este tipo de cosas.

Para aquellos de nosotros que buscamos una solución aparte de LDAP, acabo de encontrar el proyecto "SKM": https://sites.google.com/site/jeromeboismartel/code-s-corner/ssh-key-management-with-skimp

— fukawi2
fuente

1

Hay muchas soluciones comerciales y de código abierto excelentes, como Userify [1] (donde trabajo), Universal Key Manager [2], SSH Key Box [3], etc. Depende de cuáles sean sus necesidades y si usted es buscando algo que centralice la administración mientras descentraliza la operación (para que sus servidores no confíen en una autoridad central para iniciar sesión ... en ese caso, es posible que no pueda iniciar sesión en ninguno de sus servidores, si, por ejemplo, su ¡El servidor LDAP está caído!)

Vea también esta discusión sesgada:

https://www.slant.co/topics/8010/~managers-for-ssh-keys

— Jamieson Becker
fuente