cómo se administran las contraseñas de root de los servidores

Question

En nuestro equipo de administración, todos tienen contraseñas de raíz para todos los servidores de los clientes. ¿Pero qué deberíamos hacer si uno de los miembros del equipo ya no trabaja con nosotros? Él todavía tiene nuestras contraseñas y tenemos que cambiarlas todas, cada vez que alguien nos deje.

Ahora estamos utilizando claves ssh en lugar de contraseñas, pero esto no es útil si tenemos que usar algo que no sea ssh.

Answer 1

Los sistemas que ejecuto tienen una política sudo-only. es decir, la contraseña de root es * (deshabilitada), y las personas tienen que usar sudo para obtener acceso a la raíz. Luego puede editar su archivo sudoers para otorgar/revocar el acceso de las personas. Es muy granular y tiene mucha capacidad de configuración, pero tiene valores predeterminados razonables, por lo que no le tomará mucho tiempo configurarlo.

Answer 2

Si bien es una buena idea usar una política de solo sudo como Chris sugirió dependiendo del tamaño de su sistema, un enfoque de ldap también puede ser útil. Complementamos eso con un archivo que contiene todas las contraseñas de raíz, pero las contraseñas de raíz son realmente largas y no memorables. Si bien eso puede considerarse un defecto de seguridad, nos permite iniciar sesión aún si el servidor ldap no funciona.

Answer 3

Si tiene acceso ssh a través de sus certificados, no se puede acceder a través de ssh y cambiar la contraseña a través de rootpasswd o sudo passwd cuando se necesita para hacer otra cosa que requiere la contraseña?

Answer 4

Utilizamos la política sudo only donde trabajo, pero las contraseñas de raíz aún se conservan. Las contraseñas raíz solo están disponibles para unos pocos empleados seleccionados. Tenemos un programa llamado Password Manager Pro que almacena todas nuestras contraseñas y también puede proporcionar auditorías de contraseñas. Esto nos permite retroceder y ver a qué contraseñas han accedido los usuarios. Por lo tanto, solo podemos cambiar las contraseñas que realmente necesitan cambiarse.

Answer 5

Aparte de la política de sudo, que probablemente sea mejor, no hay ninguna razón por la cual cada administrador no podría tener su propia cuenta con UID 0, pero con un nombre diferente, con una contraseña diferente e incluso un directorio principal diferente. Solo elimine su cuenta cuando se hayan ido.

Answer 6

Acabamos de hacer que sea muy fácil cambiar las contraseñas de raíz en cada máquina que administramos, así que cuando la gente se fue solo ejecutamos el script. No sé muy bien pero funcionó. Antes de mi tiempo, todos en la compañía tenían acceso a la raíz en todos los servidores. afortunadamente nos alejamos de eso.

Answer 7

En general, si alguien se va de nuestro equipo, no nos molestamos en cambiar las contraseñas de root. O abandonaron la empresa (y ya no tienen forma de acceder a las máquinas ya que su VPN ha sido revocada, al igual que su acceso de placa al edificio, y su acceso inalámbrico a la red), o están en otro departamento dentro de la compañía y tener la profesionalidad para no atornillar con nuestro entorno.

¿Es un orificio de seguridad? Tal vez. Pero, realmente, si quisieran atormentarse con nuestro entorno, lo habrían hecho antes de seguir adelante.

Hasta ahora, cualquier persona que abandone el equipo que quiera tener acceso a nuestras máquinas nuevamente siempre ha pedido permiso, aunque podrían seguir adelante sin el permiso. No veo ninguna razón para impedir nuestra capacidad de hacer el trabajo, es decir, no hay razón para creer que alguien más se mueva hacia adelante y hacia arriba haría de manera diferente.

Answer 8

Contraseña de root razonablemente sólida. Diferente en cada caja. No hay inicios de sesión raíz remotos ni contraseñas para inicios de sesión, solo claves.

Answer 9

Yo sugeriría normalmente lo siguiente:

1. utilizar una contraseña raíz blanco.
2. telnet Desactivar
3. Conjunto ssh no compatibles con la raíz de inicio de sesión (o conexión de la raíz de clave pública sólo)
4. Desactivar su a root mediante la adición de esto a la parte superior de/etc/suauth: 'root: ALL: DENY '
5. activar TTY seguro para conexión de la raíz en la consola única (tty1-tty8)
6. usar sudo para acceder raíz habitual

Ahora bien, con esta configuración, todos los usuarios deben usar sudo para la administración remota, pero cuando el sistema está seriamente dañado, no hay buscando la contraseña de root para desbloquear la consola.

EDITAR: otras herramientas de administración de sistemas que proporcionan sus propios inicios de sesión también necesitarán ajustes.

Answer 10

Las llaves SSH no tienen una alternativa real.

Para la administración de muchos archivos authorized_keys en muchos servidores, debe implementar su propia solución, si no desea el mismo archivo en cada servidor. Ya sea a través de una herramienta propia o con alguna solución de administración de configuración como títere, ansible o algo así.

Si existe un ciclo for en bash o algo de clush acción será suficiente.

Hay algo además de inicios de sesión SSH:
Para los servicios que se ejecutan que son a base de iniciar sesión, utilice algún tipo de autenticación con un motor central. ¡Tenga en cuenta que nadie hará ningún trabajo si este backend no está disponible!

Ejecute el servicio en clúster. No hagas hacks con una cuenta de puerta trasera súper-duper-service, para tener siempre acceso en caso de que algo se rompa (como el acceso de administrador se rompe debido a una configuración incorrecta). No importa cuánto controle los cambios de acceso o configuración que afecten a esta cuenta, esto es 'simplemente malo' (TM).

En lugar de tener esta puerta trasera correcta, también puede agrupar la aplicación o, como mínimo, tener un sistema de repuesto que refleje periódicamente la configuración actual si la caja principal se muere, lo que puede activarse fácilmente mediante cambios de enrutamiento en la red. Si esto parece demasiado complicado, su negocio es demasiado pequeño y puede vivir con medio día o dos días de inactividad. O realmente odias los clusters debido a la falta de conocimiento y solo guardas las cosas equivocadas.

En general: Si utiliza software inutilizable con algún tipo de Active Directory o integración LDAP, tiene que saltar al tiburón y cambiar las contraseñas de estos manualmente.

También una base de datos de administración de contraseñas dedicada a la que solo pueden acceder unos pocos muy seleccionados directamente y es de solo lectura para todos los demás, es muy buena. No se moleste con los archivos de Excel, estos carecen de una gestión de derechos adecuada. Trabajar con control de versiones en archivos .csv tampoco lo corta después de un cierto umbral.