Múltiples administradores de sistemas Linux que funcionan como root

En nuestro equipo tenemos tres administradores de sistemas Linux experimentados que tienen que administrar unas pocas docenas de servidores Debian. Anteriormente, todos hemos trabajado como root utilizando la autenticación de clave pública SSH. Pero tuvimos una discusión sobre cuál es la mejor práctica para ese escenario y no pudimos acordar nada.

La clave pública SSH de todos se coloca en ~ root / .ssh / Authorizedkeke2

• Ventaja: fácil de usar, el reenvío de agentes SSH funciona fácilmente, poco gasto
• Desventaja: falta la auditoría (nunca se sabe qué "raíz" hizo un cambio), los accidentes son más probables

Usando cuentas personalizadas y sudo

De esa forma, iniciaríamos sesión con cuentas personalizadas utilizando claves públicas SSH y usaríamos sudo para realizar tareas individuales con permisos de root . Además, podríamos darnos el grupo "adm" que nos permite ver los archivos de registro.

• Ventaja: buena auditoría, sudo nos impide hacer cosas idiotas con demasiada facilidad
• Desventaja: el reenvío de agente SSH se rompe, es una molestia porque casi nada se puede hacer como no root

Usar múltiples usuarios de UID 0

Esta es una propuesta única de uno de los administradores de sistemas. Sugiere crear tres usuarios en / etc / passwd, todos con UID 0 pero diferentes nombres de inicio de sesión. Afirma que esto no está realmente prohibido y permite que todos tengan UID 0 pero aún puedan auditar.

• Ventaja: el reenvío de agentes SSH funciona, la auditoría podría funcionar (no probado), sin problemas de sudo
• Desventaja: se siente bastante sucio, no se pudo encontrar documentado en ninguna parte como una forma permitida

¿Qué sugieres?

La segunda opción es la mejor en mi humilde opinión. Cuentas personales, acceso a sudo. Deshabilite el acceso a la raíz a través de SSH por completo. Tenemos unos cientos de servidores y media docena de administradores de sistemas, así es como lo hacemos.

¿Cómo se rompe exactamente el reenvío de agentes?

Además, si se trata de un problema al usar sudocada tarea, puede invocar un shell de sudo sudo -so cambiar a un shell de raíz consudo su -

Con respecto a la tercera estrategia sugerida, aparte de useradd -o -u userXXXleer detenidamente las opciones recomendadas por @jlliagre, no estoy familiarizado con ejecutar múltiples usuarios como el mismo uid. (Por lo tanto, si continúa con eso, me interesaría si pudiera actualizar la publicación con cualquier problema (o éxito) que surja ...)

Supongo que mi primera observación con respecto a la primera opción "La clave pública SSH de todos se coloca en ~ root / .ssh / Authorizedkeys2", es que a menos que nunca vaya a trabajar en ningún otro sistema;

1. entonces al menos parte del tiempo , tendrás que trabajar con cuentas de usuario ysudo

La segunda observación sería que si trabaja en sistemas que aspiran al cumplimiento de HIPAA, PCI-DSS o cosas como CAPP y EAL, entonces tendrá que solucionar los problemas de sudo porque;

2. Es un estándar de la industria para proporcionar cuentas de usuario individuales no root, que se pueden auditar, deshabilitar, caducar, etc., generalmente utilizando alguna base de datos de usuarios centralizada.

Asi que; Usando cuentas personalizadas y sudo

Es desafortunado que, como administrador de sistemas, casi todo lo que necesite hacer en una máquina remota requiera algunos permisos elevados, sin embargo, es molesto que la mayoría de las herramientas y utilidades basadas en SSH se rompan mientras está en sudo

Por lo tanto, puedo transmitir algunos trucos que utilizo para solucionar las molestias sudoque mencionas. El primer problema es que si el inicio de sesión raíz está bloqueado usando PermitRootLogin=noo si no tiene la raíz usando la clave ssh, entonces los archivos SCP son algo así como un PITA.

Problema 1 : desea scp archivos desde el lado remoto, pero requieren acceso de root, sin embargo, no puede iniciar sesión en el cuadro remoto como root directamente.

Solución aburrida : copie los archivos en el directorio de inicio, chown y scp down.

ssh userXXX@remotesystem, sudo su -etc., cp /etc/somefilesa /home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefilesuse scp para recuperar archivos de forma remota.

Muy aburrido de hecho.

Solución menos aburrida : sftp admite el -s sftp_serverindicador, por lo tanto, puede hacer algo como lo siguiente (si ha configurado sudo sin contraseña /etc/sudoers);

sftp  -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf 

(también puedes usar este truco con sshfs, pero no estoy seguro de que sea recomendable ... ;-)

Si no tiene derechos de sudo sin contraseña, o por alguna razón configurada de que el método anterior no funciona, puedo sugerir un método de transferencia de archivos menos aburrido, para acceder a los archivos raíz remotos.

Método Ninja de reenvío de puertos :

Inicie sesión en el host remoto, pero especifique que el puerto remoto 3022 (puede ser cualquier cosa libre y no reservado para administradores, es decir,> 1024) se debe reenviar al puerto 22 en el lado local.

 [localuser@localmachine ~]$ ssh userXXX@remotehost -R 3022:localhost:22
Last login: Mon May 21 05:46:07 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------

Echar raíces en la moda normal ...

-bash-3.2$ sudo su -
[root@remotehost ~]# 

Ahora puede scp los archivos en la otra dirección evitando el paso aburrido aburrido de hacer una copia intermedia de los archivos;

[root@remotehost ~]#  scp -o NoHostAuthenticationForLocalhost=yes \
 -P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password: 
resolv.conf                                 100%  
[root@remotehost ~]#  

Problema 2: reenvío de agente SSH : si carga el perfil raíz, por ejemplo, al especificar un shell de inicio de sesión, las variables de entorno necesarias para el reenvío de agente SSH, como por ejemplo, SSH_AUTH_SOCKse restablecen, por lo tanto, el reenvío de agente SSH está "roto" sudo su -.

Respuesta a medias :

Todo lo que cargue correctamente un shell raíz restablecerá el entorno correctamente, sin embargo, hay una pequeña solución que puede usar cuando necesita AMBOS permisos de root Y la capacidad de usar el Agente SSH, AL MISMO TIEMPO

Esto logra un tipo de perfil de quimera, que realmente no debería usarse, porque es un truco desagradable , pero es útil cuando necesita archivos SCP desde el host remoto como root, a algún otro host remoto.

De todos modos, puede habilitar que su usuario pueda preservar sus variables ENV, configurando lo siguiente en sudoers;

 Defaults:userXXX    !env_reset

esto le permite crear entornos de inicio de sesión híbridos desagradables como este;

iniciar sesión de forma normal;

[localuser@localmachine ~]$ ssh userXXX@remotehost 
Last login: Mon May 21 12:33:12 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------
-bash-3.2$ env | grep SSH_AUTH
SSH_AUTH_SOCK=/tmp/ssh-qwO715/agent.1971

crear un shell bash, que se ejecute /root/.profiley /root/.bashrc. pero conservaSSH_AUTH_SOCK

-bash-3.2$ sudo -E bash -l

Entonces este shell tiene permisos de root y root $PATH(pero un directorio de inicio descifrado ...)

bash-3.2# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t
bash-3.2# echo $PATH
/usr/kerberos/sbin:/usr/local/sbin:/usr/sbin:/sbin:/home/xtrabm/xtrabackup-manager:/usr/kerberos/bin:/opt/admin/bin:/usr/local/bin:/bin:/usr/bin:/opt/mx/bin

Pero puede usar esa invocación para hacer cosas que requieren sudo root remoto, pero también el acceso del agente SSH como tal;

bash-3.2# scp /root/.ssh/authorized_keys ssh-agent-user@some-other-remote-host:~
/root/.ssh/authorized_keys              100%  126     0.1KB/s   00:00    
bash-3.2# 

La tercera opción parece ideal, pero ¿realmente la has probado para ver qué sucede? Si bien es posible que vea los nombres de usuario adicionales en el paso de autenticación, cualquier búsqueda inversa devolverá el mismo valor.

Permitir el acceso ssh directo a la raíz es una mala idea, incluso si sus máquinas no están conectadas a Internet / usan contraseñas seguras.

Por lo general, uso 'su' en lugar de sudo para el acceso a la raíz.

Yo uso (1), pero me pasó a escribir

rm -rf / tmp *

en un día desafortunado. Puedo ver que es lo suficientemente malo si tienes más de un puñado de administradores.

(2) Probablemente esté más diseñado, y puede convertirse en root de pleno derecho a través de sudo su -. Sin embargo, los accidentes aún son posibles.

(3) No tocaría con un poste de barcaza. Lo usé en Suns, para tener una cuenta raíz no barebone-sh (si no recuerdo mal) pero nunca fue sólida, además dudo que sea muy auditable.

Definitivamente responde 2.

1. Significa que está permitiendo el acceso SSH como root. Si esta máquina es de alguna manera pública, esta es una idea terrible; cuando ejecuté SSH en el puerto 22, mi VPS recibió múltiples intentos cada hora para autenticarse como root. Tenía un IDS básico configurado para registrar y prohibir las IP que hicieron múltiples intentos fallidos, pero siguieron llegando. Afortunadamente, deshabilité el acceso SSH como usuario root tan pronto como configuré mi propia cuenta y sudo. Además, no tiene prácticamente ninguna pista de auditoría para hacer esto.

2. Proporciona acceso a la raíz cuando sea necesario. Sí, apenas tiene privilegios como usuario estándar, pero esto es exactamente lo que desea; Si una cuenta se ve comprometida, desea que tenga capacidades limitadas. Desea que cualquier acceso de superusuario requiera una nueva entrada de contraseña. Además, el acceso a sudo puede controlarse a través de grupos de usuarios y restringirse a comandos particulares si lo desea, lo que le brinda más control sobre quién tiene acceso a qué. Además, los comandos ejecutados como sudo se pueden registrar, por lo que proporciona una pista de auditoría mucho mejor si las cosas salen mal. Ah, y no solo ejecutes "sudo su -" tan pronto como inicies sesión. Esa es una práctica terrible, terrible.

3. La idea de tu administrador de sistemas es mala. Y debería sentirse mal. No, las máquinas * nix probablemente no le impedirán hacerlo, pero tanto su sistema de archivos como prácticamente todas las aplicaciones esperan que cada usuario tenga un UID único. Si comienzas a seguir este camino, te puedo garantizar que tendrás problemas. Quizás no de inmediato, pero eventualmente. Por ejemplo, a pesar de mostrar nombres amigables, los archivos y directorios usan números UID para designar a sus propietarios; Si se encuentra con un programa que tiene un problema con UID duplicados en el futuro, no puede cambiar un UID en su archivo passwd más adelante sin tener que hacer una limpieza manual seria del sistema de archivos.

sudoEs el camino a seguir. Puede causar problemas adicionales con la ejecución de comandos como root, pero le proporciona un cuadro más seguro, tanto en términos de acceso como de auditoría.

Definitivamente la opción 2, pero use grupos para dar a cada usuario el mayor control posible sin necesidad de usar sudo. sudo frente a cada comando pierde la mitad del beneficio porque siempre estás en la zona de peligro. Si hace que los administradores de sistemas puedan escribir los directorios relevantes sin sudo, devuelve sudo a la excepción que hace que todos se sientan más seguros.

En los viejos tiempos, el sudo no existía. Como consecuencia, tener múltiples usuarios UID 0 era la única alternativa disponible. Pero todavía no es tan bueno, especialmente con el registro basado en el UID para obtener el nombre de usuario.

Hoy en día, sudo es la única solución adecuada. Olvida cualquier otra cosa.

Está documentado permitido de hecho. Las unidades de BSD han tenido sus cuentas por mucho tiempo, y los usuarios de bashroot tienden a ser una práctica aceptada en sistemas donde csh es estándar (mala práctica aceptada;)

Quizás soy raro, pero el método (3) es lo que también se me ocurrió primero. Pros: tendría todos los nombres de usuarios en los registros y sabría quién hizo qué como root. Contras: cada uno de ellos sería root todo el tiempo, por lo que los errores pueden ser catastróficos.

Me gustaría preguntar por qué necesita que todos los administradores tengan acceso de root. Los 3 métodos que propone tienen una desventaja distinta: una vez que un administrador ejecuta un sudo bash -lo sudo su -tal, pierde su capacidad de rastrear quién hace qué y después de eso, un error puede ser catastrófico. Además, en caso de posible mal comportamiento, esto incluso podría terminar mucho peor.

En cambio, es posible que desee considerar ir de otra manera:

• Crea tus usuarios administradores como usuarios regulares
• Decida quién necesita hacer qué trabajo (administración de apache / administración de postfix, etc.)
• Agregue usuarios a grupos relacionados (como agregar "martin" a "postfix" y "mail", "amavis" si lo usa, etc.)
• Permisos corregidos (chmod -R g + w postfix: postfix / etc / postfix)
• dé solo poderes de sudo relativos: (visudo -> deje que Martin use /etc/init.d/postfix, / usr / bin / postsuper, etc.)

De esta manera, Martin podría manejar con seguridad el postfix, y en caso de error o mal comportamiento, solo perdería su sistema de postfix, no todo el servidor.

La misma lógica se puede aplicar a cualquier otro subsistema, como apache, mysql, etc.

Por supuesto, esto es puramente teórico en este punto y puede ser difícil de configurar. Parece una mejor manera de hacerlo. Al menos para mi. Si alguien intenta esto, avíseme cómo le fue.