Tienes que hacer distinciones importantes: hay claves públicas y claves privadas . Cuando se "almacenan de forma segura", requieren diferentes nociones de "de forma segura".

Cada servidor SSH posee un par de claves pública / privada. Cada servidor debe generar su propio par de claves, y la clave privada nunca debe salir del servidor. La clave pública es pública , lo que significa que todos pueden aprenderla. Cuando te conectas al servidor, esa es una de las primeras cosas que te dice el servidor: su clave pública. Lo grita por toda la red. Cuando se trata de claves públicas SSH y su almacenamiento, la cuestión es realmente la integridad : un cliente SSH dado debe recordar las claves públicas de todos los servidores con los que quiere hablar. a (el archivo $ HOME / .ssh / known_hosts con los clientes SSH de Linux habituales); el atacante puede querer incluir una clave pública falsa allí, para ejecutar un servidor falso.

Cada cliente SSH puede poseer un par de claves pública / privada: tal clave El servidor utilizará el par para la autenticación del cliente. Si usa la autenticación de cliente basada en contraseña, los clientes no tienen esos pares de claves. Si utiliza la autenticación de cliente basada en claves, cada servidor debe conocer las claves públicas de los "clientes autorizados" (el $ HOME / .ssh / allowed_keys para las implementaciones de SSH de Linux).

En su caso, tiene 50 clientes SSH hablando con 4000 servidores SSH. Por lo tanto, utilizando el modelo SSH normal, debería asegurarse de que:

• Cada uno de los 50 clientes conozca una copia de las claves públicas para los 4000 servidores.
• Si al utilizar la autenticación de cliente basada en claves, cada uno de los 4000 servidores debe conocer una copia de las 50 claves públicas del cliente.

Dadas estas cifras, los archivos relevantes serán voluminosos y la administración de claves será un problema (si agrega un nuevo cliente, la clave pública del nuevo cliente debe importarse a 4000 servidores, con integridad protegida). Las infraestructuras de clave pública se inventaron para resolver ese problema. Una instancia de OpenSSH "oficial" sin formato no sabe cómo utilizar los certificados X.509; sin embargo, existe una versión modificada (consulte también la pregunta anterior). Con una base de código SSH compatible con X.509, puede ejecutar su propia Autoridad de certificación (p. Ej., La EJBCA de código abierto) y emitir certificados para sus clientes y servidores. De esa manera, el cliente y los servidores SSH se enviarán sus certificados cuando sea necesario, de forma dinámica. Cada máquina solo tendrá que almacenar su propia clave privada y certificado, y también "conocer" el certificado de CA (en el "almacén de confianza" correspondiente). Agregar un nuevo cliente o un nuevo servidor a la mezcla es simplemente emitir un certificado, y el problema de administración se resuelve (o, más bien, trasladado : ahora tiene una PKI que manejar).

Este es un trabajo para un software de administración de configuración como Puppet, Chef, etc. Fue creado para manejar exactamente este tipo de problemas. Le recomiendo encarecidamente que utilice un software de gestión de la configuración si tiene tantos servidores.

En lo que respecta a la parte sobre el almacenamiento de claves de forma segura, una opción es almacenar las claves privadas en un HSM (módulo de seguridad de hardware). Hay algunos proveedores bien conocidos que ofrecen estos, pero existen alternativas. Consulte, por ejemplo, Cryptostick.

La ventaja de usar un HSM es que las claves privadas solo se pueden usar mientras el dispositivo de hardware está presente en el sistema y no se pueden copiar las claves privadas en otra parte.

Este tipo de solución también requeriría una auditoría y una gestión adecuadas de las claves SSH autorizadas en los servidores SSH. De lo contrario, nada evitaría que un intruso genere y coloque su propio conjunto de claves en el servidor SSH.

Sin embargo, administrar esas claves es un problema. Existen productos comerciales para administrar claves SSH, pero no conozco ninguna buena solución de código abierto.

Como dijo Thomas, una opción es cambiar a un enfoque basado en PKI, sin embargo, esto requeriría actualizar todos sus clientes y servidores SSH.

Descargo de responsabilidad: trabajo para una empresa que vende un producto comercial de administración de claves SSH.

Considere algún software de administración de claves ssh que pueda almacenar y administrar (cambiar) claves ssh dinámicamente, esto es directamente análogo a un sistema de administración de contraseñas.

¡Sin embargo, estas soluciones tienen un costo!