En mi empresa, utilizamos LDAP para tener un conjunto consistente de cuentas en todas las máquinas y luego utilizamos una herramienta de administración de configuración (en nuestro caso actualmente cfengine) para distribuir authorized_keysarchivos para cada usuario en todos los servidores. Los archivos de claves se guardan (junto con otra información de configuración del sistema) en un repositorio de git para que podamos ver cuándo van y vienen las claves. cfengine también distribuye un sudoersarchivo que controla quién tiene acceso para ejecutar qué como raíz en cada host, utilizando los usuarios y grupos del directorio LDAP.
La autenticación de contraseña está completamente deshabilitada en nuestros servidores de producción, por lo que la autenticación de clave SSH es obligatoria. La política alienta el uso de una clave separada para cada computadora portátil / computadora de escritorio / lo que sea y el uso de una frase de contraseña en todas las teclas para reducir el impacto de una computadora portátil perdida / robada.
También tenemos un host de bastión que se utiliza para acceder a los hosts en la red de producción, lo que nos permite tener reglas de firewall muy restrictivas alrededor de esa red. La mayoría de los ingenieros tienen alguna configuración SSH especial para hacer esto transparente:
Agregar una nueva clave o eliminar una antigua requiere un poco de ceremonia en esta configuración. Yo diría que para agregar una nueva clave es deseable que sea una operación que deje un rastro de auditoría y sea visible para todos. Sin embargo, debido a los gastos generales involucrados, creo que las personas a veces descuidan quitar una clave antigua cuando ya no es necesaria y no tenemos una forma real de rastrearla, excepto para limpiar cuando un empleado deja la empresa. También crea una fricción adicional al incorporar un nuevo ingeniero, ya que necesitan generar una nueva clave y enviarla a todos los hosts antes de que puedan ser completamente productivos.
Sin embargo, el mayor beneficio es tener un nombre de usuario separado para cada usuario, lo que facilita el control de acceso más granular cuando lo necesitamos y le da a cada usuario una identidad que aparece en los registros de auditoría, lo que puede ser realmente útil al tratar de rastrear un problema de producción de vuelta a una acción de administrador de sistemas.
En esta configuración, es molesto tener sistemas automatizados que actúen contra los hosts de producción, ya que sus claves SSH "conocidas" pueden servir como una ruta de acceso alternativa. Hasta ahora hemos hecho que las cuentas de usuario para estos sistemas automatizados tengan solo el acceso mínimo que necesitan para hacer su trabajo y aceptamos que un usuario malintencionado (que ya debe ser un ingeniero con acceso de producción) también podría hacer esas mismas acciones semi- utilizando de forma anónima la clave de la aplicación.
Esta es una muy buena respuesta! Pregunta de seguimiento: utiliza cfengine para distribuir claves autorizadas. ¿Buscó alguna de las formas de almacenar claves públicas SSH en su servidor LDAP directamente? En su mayoría requieren parches sshd, que se siente frágil.
Evan Prodromou
He hecho algo similar con el chef.
gWaldo
1
@EvanProdromou He configurado claves públicas SSH en LDAP, pero fue mucho más complicado de lo que valía, dado que tuve que mantener los paquetes SSH actualizados yo mismo, y fue en el momento de algunas vulnerabilidades SSH
Me gusta tu ProxyCommand ssh -qparte allí! Nunca he visto eso. Dudo en poner un servidor bastión, pero si puede ser transparente para los usuarios finales, entonces podría estar a favor. Gracias martin
the0ther
6
Personalmente, me gusta la idea de que cada miembro del personal tenga una clave en una máquina de bastión ssh dedicada en la que tienen una cuenta de usuario básica. Esa cuenta de usuario tiene 1 clave ssh que otorga acceso a todos los servidores que necesitan usar. (estos otros servidores también deben tener un cortafuegos para que solo se habilite el acceso ssh desde la máquina de bastión)
Luego, en sus máquinas de trabajo cotidianas, computadoras portátiles, tabletas, etc., pueden elegir tener una clave entre ellas o varias claves.
Como administrador de sistemas en esa red, tiene un número mínimo de claves para cuidar (una por desarrollador), puede monitorear fácilmente el acceso ssh a través de la red (ya que todo se enruta a través de la máquina de bastión) y si el desarrollador quiere múltiples claves o solo uno que comparten entre sus máquinas no es un problema real, ya que solo tiene una máquina para actualizar. (a menos que las claves ssh de los bastiones estén comprometidas, pero eso es mucho más improbable que una de las claves de los usuarios)
Tuve la situación en la que necesitaba proporcionar acceso de clave SSH para un equipo de 40 desarrolladores a ~ 120 servidores de clientes remotos.
Controlé el acceso obligando a los desarrolladores a conectarse a través de un único "host de salto". Desde ese host, generé claves privadas / públicas y las envié a los servidores del cliente. Si los desarrolladores necesitaran acceso desde una computadora portátil, podrían usar el mismo par de llaves en su sistema local.
Yo personalmente iría por usuario, entonces instantáneamente tienes responsabilidad y estableces restricciones mucho más fácilmente. ¿No sé lo que piensan otras personas?
Un enfoque que he escuchado, pero que no utilicé, es que cada usuario tenga un paquete (por ejemplo, .deb, .rpm) que contenga su configuración de clave pública ssh, así como cualquier archivo de puntos que desee personalizar (.bashrc , .profile, .vimrc, etc.). Esto está firmado y almacenado en un repositorio de la compañía. Este paquete también podría ser responsable de crear la cuenta de usuario, o podría complementar algo más creando la cuenta (cfengine / puppet, etc.) o un sistema de autenticación central como LDAP.
Estos paquetes se instalan en los hosts a través del mecanismo que prefiera (cfengine / puppet, etc., trabajo cron). Un enfoque es tener un metapaquete que depende de los paquetes por usuario.
Si desea eliminar una clave pública, pero no el usuario, se actualiza el paquete por usuario. Si desea eliminar un usuario, elimine el paquete.
Si tiene sistemas heterogéneos y tiene que mantener los archivos .rpm y .deb, entonces puedo ver que esto es un poco molesto, aunque herramientas como alien podrían hacerlo un poco más fácil.
Como digo, no lo he hecho yo mismo. El beneficio de este enfoque para mí es que complementa un sistema LDAP central y la administración central de las cuentas de usuario, ya que le permite al usuario actualizar fácilmente su paquete para incluir su archivo .vimrc, por ejemplo, sin tener que tener ese archivo administrado mediante herramientas como títeres, a las que un usuario puede no tener acceso.
Debe tomar la ruta más segura y obligar a cada usuario a tener claves separadas, y probablemente para cada dispositivo.
Si tiene claves compartidas entre usuarios, incluso si es un equipo pequeño, revocar una clave es un inconveniente para todos los demás.
Si permite que su personal tenga una clave para todos sus dispositivos, entonces pueden elegir a qué servidores pueden conectarse con ese dispositivo. Por ejemplo, una computadora portátil móvil podría estar restringida a uno o dos servidores, pero el escritorio de la oficina puede tener acceso a todos los servidores.
Hace unos años, Envy Labs escribió una herramienta llamada Keymaster (en asociación con el cliente Gatekeeper) para manejar algo como esto para los equipos de desarrollo.
El proyecto no ha tenido mucho amor en los últimos dos años, pero es probable que sea algo con lo que puedas jugar y quizás revivir.
Un enfoque podría ser configurar el servidor NIS con / home share a través de NFS. Eso se combina con sudo en los servidores y permite que solo los usuarios que desee accedan a cada servidor a través de la configuración ssh.
De esta forma, todos los miembros del equipo utilizan solo un usuario y su clave para acceder a todos los servidores. Sudo y una contraseña para las tareas de administrador.
ProxyCommand ssh -qparte allí! Nunca he visto eso. Dudo en poner un servidor bastión, pero si puede ser transparente para los usuarios finales, entonces podría estar a favor. Gracias martinPersonalmente, me gusta la idea de que cada miembro del personal tenga una clave en una máquina de bastión ssh dedicada en la que tienen una cuenta de usuario básica. Esa cuenta de usuario tiene 1 clave ssh que otorga acceso a todos los servidores que necesitan usar. (estos otros servidores también deben tener un cortafuegos para que solo se habilite el acceso ssh desde la máquina de bastión)
Luego, en sus máquinas de trabajo cotidianas, computadoras portátiles, tabletas, etc., pueden elegir tener una clave entre ellas o varias claves.
Como administrador de sistemas en esa red, tiene un número mínimo de claves para cuidar (una por desarrollador), puede monitorear fácilmente el acceso ssh a través de la red (ya que todo se enruta a través de la máquina de bastión) y si el desarrollador quiere múltiples claves o solo uno que comparten entre sus máquinas no es un problema real, ya que solo tiene una máquina para actualizar. (a menos que las claves ssh de los bastiones estén comprometidas, pero eso es mucho más improbable que una de las claves de los usuarios)
fuente
Tuve la situación en la que necesitaba proporcionar acceso de clave SSH para un equipo de 40 desarrolladores a ~ 120 servidores de clientes remotos.
Controlé el acceso obligando a los desarrolladores a conectarse a través de un único "host de salto". Desde ese host, generé claves privadas / públicas y las envié a los servidores del cliente. Si los desarrolladores necesitaran acceso desde una computadora portátil, podrían usar el mismo par de llaves en su sistema local.
fuente
Yo personalmente iría por usuario, entonces instantáneamente tienes responsabilidad y estableces restricciones mucho más fácilmente. ¿No sé lo que piensan otras personas?
fuente
Un enfoque que he escuchado, pero que no utilicé, es que cada usuario tenga un paquete (por ejemplo, .deb, .rpm) que contenga su configuración de clave pública ssh, así como cualquier archivo de puntos que desee personalizar (.bashrc , .profile, .vimrc, etc.). Esto está firmado y almacenado en un repositorio de la compañía. Este paquete también podría ser responsable de crear la cuenta de usuario, o podría complementar algo más creando la cuenta (cfengine / puppet, etc.) o un sistema de autenticación central como LDAP.
Estos paquetes se instalan en los hosts a través del mecanismo que prefiera (cfengine / puppet, etc., trabajo cron). Un enfoque es tener un metapaquete que depende de los paquetes por usuario.
Si desea eliminar una clave pública, pero no el usuario, se actualiza el paquete por usuario. Si desea eliminar un usuario, elimine el paquete.
Si tiene sistemas heterogéneos y tiene que mantener los archivos .rpm y .deb, entonces puedo ver que esto es un poco molesto, aunque herramientas como alien podrían hacerlo un poco más fácil.
Como digo, no lo he hecho yo mismo. El beneficio de este enfoque para mí es que complementa un sistema LDAP central y la administración central de las cuentas de usuario, ya que le permite al usuario actualizar fácilmente su paquete para incluir su archivo .vimrc, por ejemplo, sin tener que tener ese archivo administrado mediante herramientas como títeres, a las que un usuario puede no tener acceso.
fuente
Debe tomar la ruta más segura y obligar a cada usuario a tener claves separadas, y probablemente para cada dispositivo.
Si tiene claves compartidas entre usuarios, incluso si es un equipo pequeño, revocar una clave es un inconveniente para todos los demás.
Si permite que su personal tenga una clave para todos sus dispositivos, entonces pueden elegir a qué servidores pueden conectarse con ese dispositivo. Por ejemplo, una computadora portátil móvil podría estar restringida a uno o dos servidores, pero el escritorio de la oficina puede tener acceso a todos los servidores.
fuente
Hace unos años, Envy Labs escribió una herramienta llamada Keymaster (en asociación con el cliente Gatekeeper) para manejar algo como esto para los equipos de desarrollo.
El proyecto no ha tenido mucho amor en los últimos dos años, pero es probable que sea algo con lo que puedas jugar y quizás revivir.
El repositorio está disponible en github: https://github.com/envylabs/keymaster
fuente
Un enfoque podría ser configurar el servidor NIS con / home share a través de NFS. Eso se combina con sudo en los servidores y permite que solo los usuarios que desee accedan a cada servidor a través de la configuración ssh.
De esta forma, todos los miembros del equipo utilizan solo un usuario y su clave para acceder a todos los servidores. Sudo y una contraseña para las tareas de administrador.
Saludos,
Rafael
fuente