40 votos

¿Cuáles son las mejores prácticas para la gestión de claves SSH en un equipo?

Yo trabajo con equipos pequeños (<10) de los desarrolladores y administradores con las siguientes características:

  • La mayoría de los miembros del equipo tienen >1 computadora personal, la mayoría de los cuales son portátiles
  • Los miembros del equipo tienen acceso a 10-50 servidores, por lo general con sudo

Creo que esto es bastante típico para la mayoría de las nuevas empresas pequeñas y de tamaño medio de TI de la empresa grupos.

¿Cuáles son las mejores prácticas para la gestión de claves SSH en un equipo como este?

Deben compartir una clave única para todo el equipo?

Cada persona tiene su propia clave en una cuenta compartida ("ubuntu" en cada servidor)?

Cuentas separadas?

Cada miembro del equipo de mantener una tecla separada para cada uno de sus ordenadores portátiles o de escritorio?

31voto

Martin Atkins Puntos 361

En mi empresa utilizamos LDAP para tener un conjunto coherente de cuentas a través de todas las máquinas y, a continuación, utilizar una configuración de la herramienta de administración (en nuestro caso actualmente cfengine) para distribuir authorized_keys archivos para cada usuario a través de todos los servidores. La clave de los archivos se mantienen (junto con otra información de configuración del sistema) en un repositorio de git, así que podemos ver cuando las teclas de ir y venir. cfengine también distribuye un sudoers archivo que controla quién tiene acceso a ejecutar lo que como root en cada host, el uso de los usuarios y grupos del directorio LDAP.

Autenticación de contraseña está completamente desactivado en nuestros servidores de producción, por lo que la clave SSH auth es obligatorio. Política favorece el uso de una tecla separada para cada ordenador portátil/escritorio/lo que sea y usando una frase de paso en todas las claves para reducir el impacto de una pérdida o robo de la laptop.

También tenemos un bastión host que se utiliza para acceder a los hosts en la red de producción, lo que nos permite tener muy restrictivas reglas de cortafuegos alrededor de la red. La mayoría de los ingenieros tienen algunos especiales de configuración de SSH para hacer que este transparente:

Host prod-*.example.com
     User jsmith
     ForwardAgent yes
     ProxyCommand ssh -q bastion.example.com "nc %h %p"

La adición de una nueva clave o la eliminación de un viejo uno requiere un poco de ceremonia en esta configuración. Yo diría que para añadir una nueva clave es conveniente que sea una operación que deja un rastro de auditoría y es visible para todo el mundo. Sin embargo, debido a la sobrecarga que implica pienso que la gente a veces descuido para eliminar una clave de edad, cuando ya no se necesita y no tenemos manera real a la pista de que, excepto para limpiar cuando un empleado abandona la empresa. También crea algunos adicionales fricción cuando la incorporación de un nuevo ingeniero, ya que ellos necesitan para generar una nueva clave y lo han expulsado a todos los hosts antes de que puedan ser totalmente productivo.

Sin embargo, el mayor beneficio es tener un nombre de usuario para cada usuario, lo que hace que sea más fácil hacer más control de acceso granular cuando la necesitamos y le da a cada usuario una identidad que se muestra en los registros de auditoría, que puede ser muy útil a la hora de realizar el seguimiento de un problema de producción de regreso a un sysadmin acción.

Es molesto en virtud de este programa de instalación para tener sistemas automatizados que tomar acción en contra de la producción de los ejércitos, ya que su "conocido" claves SSH puede servir como una alternativa de la ruta de acceso. Hasta ahora sólo hemos hecho las cuentas de usuario de estos sistemas automatizados tienen únicamente el acceso mínimo que necesitan para hacer su trabajo y se acepta que un usuario malintencionado (que ya debe ser un ingeniero con acceso a producción) también podría hacer las mismas acciones semi-anónima mediante la aplicación de la clave.

6voto

peteches Puntos 318

Personalmente me gusta la idea de que cada miembro del personal con una tecla dedicada ssh bastión de la máquina en la que tienen una cuenta de usuario básica. Que la cuenta de usuario tiene 1 clave ssh que permite el acceso a todos los servidores que necesitan para su uso. ( estos otros servidores también debe estar detrás de un firewall desactivado tan sólo el acceso ssh desde el bastión de la máquina está habilitado )

A continuación, en su trabajo diario, máquinas, ordenadores portátiles, tablets, etc que puede hacer su propia elección de tener una de las claves entre ellos o varias teclas.

Como administrador de sistemas en los que la red tiene un número mínimo de teclas para cuidar (uno por dev), puede controlar fácilmente el acceso ssh a través de la red ( ya que todas las rutas a través de el bastión de la máquina ) y si el desarrollador desea varias teclas o simplemente uno que comparten entre sus máquinas no es ningún problema real, ya que sólo tienen una máquina para actualizar. ( a menos que el bastiones claves ssh están en peligro, ut tbh que es mucho más raro que uno de los usuarios de teclado)

5voto

Tina Puntos 21

He tenido la situación en la que he necesitado para proporcionar SSH clave de acceso para un equipo de 40 desarrolladores a ~120 remoto a los servidores de sus clientes.

Yo controlaba el acceso al obligar a los desarrolladores a conectar a través de un único "salto de acogida". A partir de ese host, me genera claves privadas/públicas y empujó a los servidores de sus clientes. Si los desarrolladores necesitan el acceso desde un ordenador portátil, se puede utilizar el mismo par de claves en su sistema local.

2voto

Diego Puntos 611

Un método que he oído, pero no se utiliza mí mismo, es que cada usuario tiene un paquete (por ejemplo, .deb, .rpm) que contiene su clave pública ssh configuración, así como cualquier dotfiles que les gusta personalizar (.bashrc, .perfil .vimrc etc). Esto está firmado y se almacena en una empresa repositorio. Este paquete también podría ser responsable de la creación de la cuenta de usuario, o se podría complementar algo más de la creación de la cuenta (cfengine/títeres, etc) o central de un sistema de autenticación como LDAP.

Estos paquetes están instalados en los ejércitos a través de cualquier mecanismo que prefieren (cfengine/títeres etc, cron job). Un enfoque es tener un metapaquete que tiene una dependencia en la per-paquetes de usuario.

Si desea eliminar una clave pública, pero no para el usuario, entonces el paquete por el usuario se actualiza. Si desea eliminar un usuario, eliminar el paquete.

Si usted tiene sistemas heterogéneos y tienen que mantener a ambos .y las rpm .archivos deb, a continuación, puede ver que esta siendo un poco molesto, aunque herramientas como extranjero podría hacer que en un poco más fácil.

Como digo, yo no he hecho esto por mí mismo. El beneficio de este enfoque a mí es que los suplementos de una central de LDAP del sistema central y de gestión de cuentas de usuario, que permite una fácil actualización de su paquete de incluir .vimrc archivo, por ejemplo, sin tener que tener ese archivo manejadas por herramientas como títere, que un usuario no puede tener acceso.

2voto

KeithS Puntos 161

Yo personalmente iría con cada usuario, a continuación, tendrás instantáneamente la rendición de cuentas y establecer restricciones mucho más fácilmente - no sé lo que piensa la gente?

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: