Un sistema para distribuir claves públicas SSH

26

Tenemos muchos sistemas diferentes que son administrados por varias personas. Hemos optado por utilizar la autenticación de clave pública SSH para acceder a esos sistemas. Esto funciona muy bien, ya que no es necesario administrar o compartir las contraseñas de las cuentas administrativas, no es necesario recordar las contraseñas de los diversos sistemas (solo la frase de contraseña de su clave privada), no es necesario interactuar (ingresar la contraseña) con cada comando remoto .

El problema es que las claves públicas instaladas en los sistemas deben administrarse de alguna manera. Las personas van y vienen, las claves pueden verse comprometidas, las responsabilidades cambian (una persona autorizada para ingresar a un sistema hoy puede estar autorizada para acceder a uno diferente mañana). Actualmente lo gestionamos editando manualmente archivos ~ / .ssh / Authorized_keys en cada cuenta que lo necesite, pero eso es mucho trabajo y es propenso a errores.

¿Existe alguna herramienta lista para administrar claves públicas en tal escenario? ¿Tienes tus propias soluciones? ¿O es que toda la idea de administrar sistemas de esta manera es defectuosa?

ssh ssh-keys public-key

— Jacek Konieczny
fuente

Realmente no puedo responder a su pregunta, pero cuando la leí pude escucharla gritar por algún tipo de sistema de base de datos.

— John Gardeniers

De hecho, puedo ver un lugar para una base de datos en el 'backend' (el 'servidor de claves'), aunque preferiría limitar el acceso a la base de datos allí y tener las claves distribuidas por el canal SSH. No abrir ningún otro canal de comunicación en los sistemas administrados. De hecho, me siento capaz de implementar dicha herramienta / sistema yo mismo, aunque preferiría algo listo y probado como efectivo.

— Jacek Konieczny

18

Como ya se mencionó en pulegium, cualquier software genérico de administración de configuración como Puppet , Chef , Bcfg2 o cfengine podría realizar la tarea.

Dado que el archivo Authorized_keys no es tan complicado, también puede usar rsync o un (D) SCM como git o hg para administrar este archivo. Tiene el archivo "maestro" en uno de sus servidores y lo sirve a través de rsync / git / hg / .... En todos los demás servidores, ejecuta un trabajo cron que recupera periódicamente la copia maestra (si se modificó) y la copia en la ubicación local correcta. Diablos, esto incluso funcionaría con HTTP o FTP puro.

La conclusión es: tener una copia "maestra" de su archivo autorizado_claves y actualizarla. Deje que los "clientes" (las computadoras, que deben tener el archivo autorizado de claves actualizadas) lo traigan de su servidor maestro y lo implementen localmente.

— joschi
fuente

1

Utilizamos cómodamente puppet para administrar ~ 200 servidores Linux (las claves de publicación son solo un archivo para imponer como un atributo de un usuario).

— ForgeMan

1

Aceptaré esta respuesta porque parece que no mejoraré. Parece que las opciones para mí son: 1. Mantener las cosas como están ahora 2. Construir una cadena de herramientas propia para administrar archivos de claves autorizadas 3. Usar alguna herramienta genérica existente para administrar servidores, como Puppet o Chef ... aunque esas herramientas parecen demasiado grandes para Esta simple tarea. 4. Utilice otro mecanismo de autenticación / autorización (como Kerberos) ... aunque esto también parece una herramienta demasiado sofisticada para una tarea simple. Gracias.

— Jacek Konieczny

Este sistema es tan seguro como el canal a través del cual se extrae la copia maestra.

— yrk

1

Ansible es un sistema CM muy liviano que tiene un módulo para manipular archivos de claves autorizados a través de ssh. Ver ansible.cc/docs/modules.html#authorized-key

— RS

11

Hay un parche disponible para OpenSSH que le permite usar claves públicas de un servidor LDAP, pero esto solo tiene sentido si sus verificaciones de autenticación / cuenta también se realizan en ese servidor LDAP (que es cómo está configurado mi entorno). Además, es tan seguro como su configuración LDAP (por lo que desea utilizar SSL y claves de verificación).

Consulte http://code.google.com/p/openssh-lpk/ para ver el parche y más detalles. No conozco ningún sistema operativo que se envíe con este parche de forma predeterminada, pero si está ejecutando FreeBSD, es un parche opcional si utiliza OpenSSH desde los puertos.

— voretaq7
fuente

1

Por cierto, el uso de pam_ldap también le permite resolver el problema de "alguien autorizado para acceder a la máquina A hoy puede no tener autorización para acceder a él mañana". Lea sobre pam_ldap si está interesado en ese aspecto ...

— voretaq7

5

ejecuto una solución muy fácil, que hace lo mismo con las reglas de firewall

archivo de ejemplo hosts.conf:

192.168.0.1
192.168.2.99
192.168.2.100

distribuir.sh:

#!/bin/bash
for d in `cat ./hosts.conf`; do
  echo "copying to $d ...";
  scp /root/.ssh./authorized_keys root@$d:/root/.ssh./authorized_keys
done;

esa es toda la magia :-)

— bmaeser
fuente

5

Actualmente estoy revisando SSH KeyDB . Está destinado a hacer exactamente eso, administrar roles, servidores y usuarios, distribuir claves de usuario, recopilar claves de host, etc. Incluso tiene algo llamado "ubicaciones".

Todavía no lo he resuelto todo y no estoy seguro de si está funcionando completamente. Sin embargo, el código está en Python y parece ser bastante manejable, por lo que no debería ser demasiado difícil desempolvarlo y hacerlo funcionar.

— andsens
fuente

1

No estoy seguro de lo que quieres decir con muchos, ni sé si estás dispuesto a cambiar, pero Kerberos es el droide que estás buscando. Eso resolverá sus problemas con elegancia y autenticará tanto a las personas como a las máquinas.

— pboin
fuente

1

Tiene dos (que generalmente se convierten en 3) problemas diferentes que está tratando de resolver:

Autenticación (¿Quién eres?)
Autorización (¿Se le permite acceder a este servidor?)
Auditoría (¿Qué hiciste?)

La autenticación de clave pública es una forma correcta de autenticar a veces, pero no aborda la autorización en absoluto. No me gusta la autenticación de clave pública, ya que es muy fácil comprometerla (especialmente internamente) a menos que tenga algunos buenos controles.

Ahí es donde entran en juego soluciones como Kerberos. En el mundo de Windows, Active Directory resuelve este problema. En el mundo de Unix, hay una gran cantidad de opciones, lo que es bueno y malo.

Verificaría el proyecto Red Hat FreeIPA , que es un paquete de software que facilita la instalación y ejecución rápida de un sistema Kerberos / LDAP / DNS tipo AD.

— duffbeer703
fuente

Entiendo la diferencia entre autenticación, autorización y auditoría. Y las 'claves_autorizadas' de SSH proporcionan datos de autenticación y autorización. Está lejos de ser perfecto, pero es simple. Y la simplicidad es a menudo una gran ventaja, también en seguridad. Kerberos, con su infraestructura complicada, puede fallar en la seguridad en más formas que ssh con sus archivos autorizado_claves. Sin embargo, no significa que uno u otro sea más seguro.

— Jacek Konieczny

Administrar los archivos autorizado_keys es np para un puñado de servidores, pero rápidamente llega a un punto donde es imposible administrarlo. No estaba tratando de decir que es una solución "mala". Del mismo modo, las complejidades en Kerberos son inapropiadas para dos servidores ... pero la inversión en diseño / implementación de Kerberos vale la pena en un entorno más grande.

— duffbeer703

1

Puede usar Bcfg2 con bcfg2-accounts para distribuir authorized_keys. Como beneficio adicional, tendrá la capacidad de controlar usuarios y grupos.

Bcfg2 también permite un mantenimiento /etc/ssh/ssh_known_hostssin problemas con SSHbase .

— myroslav
fuente

1

También hay SKM

— andsens
fuente