Cuando aprendemos a conectarnos a un servidor por primera vez a través de SSH, lo hacemos con el único medio que sabemos: contraseñas. Esos textos pequeños, predecibles e inseguros. Una vez que descubrimos que podemos hacerlo mejor, usamos un administrador de contraseñas o un mecanismo similar para hacer que nuestras contraseñas sean más seguras y proteger nuestros servidores de nuestra mente perezosa (que quiere que usemos la misma contraseña para todo).
Después de eso, aprendemos sobre la criptografía de clave pública y cómo podemos usarla para crear claves SSH, que se consideran una mejor práctica que usar contraseñas. Simplemente les decimos a nuestros servidores cuál es nuestra clave pública y nos otorgarán acceso sin más preguntas.
Eso funciona bien, tenemos acceso a lo que necesitamos y estamos contentos con nuestro flujo. Luego, nuestra organización comienza a crecer y nos damos cuenta de que debemos otorgar acceso manual a cada usuario por servidor. O eso, o use la misma clave para todos los servidores y comparta la clave (no).
Se está yendo de las manos. Necesitamos recordar quién tiene acceso a qué y si queremos restringir el acceso, será más complejo con el tiempo.
¿Cuál podría ser una buena solución a este dilema? Piense por un segundo. Desea administrar el acceso a sus servidores y saber en todo momento quién tiene acceso a qué. Lo que descubrimos al buscar una solución de este tipo fue LDAP (Lightweight Directory Access Protocol). En resumen, podemos tener un servidor de autenticación donde los otros servidores pueden buscar claves públicas y otorgar acceso si se les permite, sin tener que ir directamente a cada servidor para actualizar esa información.
Existe una implementación de código abierto conocida como OpenLDAP. LDAP le permite tener una base de datos centralizada para sus usuarios, donde guarda toda la información relevante para ellos. Puede agregar campos al esquema de los usuarios, lo que le permite tener un campo con la clave pública, que es la que deben solicitar los servidores.
En cada servidor, instala un cliente LDAP, le otorga acceso para leer la información de sus usuarios en el servidor LDAP y cambiar la forma en que SSH busca AuthorizedKeys para que use el resultado de la consulta en lugar de los locales. El proceso de instalación del cliente puede parecer demasiado trabajo al principio, porque debe hacerse servidor por servidor, pero eso puede automatizarse fácilmente.
Los usuarios pueden tener acceso por nombre, grupo, etc. Eso nos da mucha más flexibilidad que la que teníamos anteriormente.
Suponga que tiene un grupo de servidores de bases de datos y que desea permitir el acceso a esos servidores solo a sus dbadmins. Crea un grupo dbadmin y concede acceso a ese grupo en cada servidor db. Si desea evitar que alguien inicie sesión en esos servidores, simplemente elimínelos del grupo y listo, no podrán seguir autenticándose.
Otra ventaja es que sabrá quién inició sesión, porque utilizarán sus propias credenciales, e incluso si esto no fuera escalable sin un servidor de inicio de sesión centralizado, ahora lo es. Si algo sucede, tiene los registros para indicarle quién inició sesión cuando ocurrió el incidente.
Siempre hay un millón de formas de hacer las cosas y siempre debe buscar la que le ofrezca un buen equilibrio entre complejidad y seguridad. Administrar muchos servidores como su organización puede salirse de sus manos bastante rápido, y esta es una alternativa viable para mantener todo bajo control.
No he agregado una sola línea de código o configuración porque es más importante para mí exponer el comportamiento que quiero que mi implementación específica, que aún puede tener espacio para mejorar.