Tienes que hacer distinciones importantes: hay claves públicas y claves privadas . Cuando se "almacenan de forma segura", piden nociones diferentes 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 debe nunca abandonar el servidor. La clave pública es pública , lo que significa que todos pueden aprenderla. Cuando se conecta al servidor, esa es una de las primeras cosas que el servidor le dice: su clave pública. Se grita en toda la red. Al tratar con las claves públicas de SSH y su almacenamiento, la pregunta es realmente acerca de integridad : un determinado cliente de SSH debe recordar las claves públicas de todos los servidores de los que quiere hablar. a (el archivo $HOME/.ssh/known_hosts
con clientes habituales de Linux SSH); el atacante puede querer incluir una clave pública falsa para ejecutar un servidor falso.
Cada cliente SSH puede poseer un par de claves pública / privada: dicho par de claves se utilizará para la autenticación del cliente por parte del servidor. Si utiliza la autenticación de cliente basada en contraseña, entonces los clientes no tienen tales pares de claves. Si utiliza la autenticación de cliente basada en clave, entonces cada servidor debe conocer las claves públicas de "clientes autorizados" (el $HOME/.ssh/authorized_keys
para implementaciones de Linux SSH).
En su caso, tiene 50 clientes SSH que hablan con servidores 4000 SSH. Por lo tanto, utilizando el modelo SSH normal, debería asegurarse de que:
- Cada uno de los 50 clientes conoce una copia de las claves públicas de los 4000 servidores.
- Si utiliza la autenticación de cliente basada en clave, cada uno de los 4000 servidores debe conocer una copia de las 50 claves públicas de 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). Se crearon Infraestructuras de clave pública para resolver ese problema. Una instancia en bruto, "oficial" OpenSSH no sabe cómo usar los certificados X.509; sin embargo, existe una versión modificada (consulte también esa pregunta anterior ). Con una base de código SSH compatible con X.509, puede ejecutar su propia Autoridad de Certificación (por ejemplo, el código abierto EJBCA ), y emita certificados para sus clientes y servidores. De esa manera, el cliente y los servidores SSH se enviarán entre sí 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 solo emitir un certificado y el problema de administración se resuelve (o, mejor dicho, se movió : ahora tiene que manejar una PKI).