Múltiples administradores de sistemas Linux que funcionan como root

40

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?

Signum
fuente
2
Acerca de su declaración "no se pudo documentar en ninguna parte como una forma permitida": Eche un vistazo a la -obandera en la useraddpágina del manual. Esta bandera está ahí para permitir que múltiples usuarios compartan el mismo uid.
jlliagre
66
¿Puede explicar qué quiere decir con "interrupciones de reenvío de agentes SSH" en la segunda opción? Usamos esto en mi trabajo y el reenvío de agentes ssh funciona bien.
Patrick
44
Debe salir de su cuenta no root en lugar de hacerlo desde sudo.
Random832
44
Otra consecuencia del método sudo: ya no puede SCP / FTP como root. Las transferencias de archivos primero deberán trasladarse al directorio de inicio de la persona y luego copiarse en el terminal. Esto es una ventaja y una desventaja dependiendo de la perspectiva.
user606723
1
¿Por qué no se consideran los sistemas de tipo títere / chef / ansible?
Alex Holst

Respuestas:

64

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 -

thepearson
fuente
10
En lugar de deshabilitar completamente el acceso a la raíz mediante SSH, recomiendo hacer que el acceso a la raíz por SSH requiera claves, crear una clave con una frase clave muy fuerte y mantenerla bloqueada solo para uso de emergencia. Si tiene acceso permanente a la consola, esto es menos útil, pero si no lo tiene, puede ser muy útil.
EightBitTony
17
Recomiendo deshabilitar el inicio de sesión raíz a través de SSH por motivos de seguridad. Si realmente necesita iniciar sesión como root, inicie sesión como usuario no root y su.
taz
+1 ... iría más allá de decir "La segunda opción es la mejor". Es la única opción razonable. Las opciones uno y tres disminuyen enormemente la seguridad del sistema contra ataques externos y errores. Además, # 2 es cómo se diseñó el sistema para usarse principalmente.
Ben Lee
2
Por favor, explique sudo -s. ¿Estoy en lo cierto al entender que sudo -ino hay diferencia en usar su -o básicamente iniciar sesión como root aparte de la entrada de registro adicional en comparación con el inicio de sesión de root simple? Si eso es cierto, ¿cómo y por qué es mejor que el inicio de sesión raíz simple?
PF4Public
9

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;

  1. 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# 
Tom H
fuente
1
Me gustan los hacks.
sjbotha
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.

symcbean
fuente
44
Agregar múltiples usuarios con el mismo UID agrega problemas. Cuando las aplicaciones buscan el nombre de usuario para un número de UID, pueden buscar el nombre de usuario incorrecto. Las aplicaciones que se ejecutan bajo root pueden pensar que se están ejecutando como el usuario incorrecto, y comenzarán a aparecer muchos errores extraños (lo intenté una vez).
Patrick
8
La tercera opción es solo una mala idea . Básicamente, está rompiendo la relación 1: 1 entre UID y nombres de usuario, y literalmente todo en Unix espera que esa relación se mantenga. El hecho de que no haya una regla explícita de no hacerlo no significa que sea una buena idea.
Shadur
Lo siento, pero la tercera opción es una idea horrible. Tener múltiples UID 0 personas que inician sesión es solo pedir que se multipliquen los problemas. La opción número 2 es la única sana.
Doug
La tercera opción no merece tantos votos negativos. No hay ningún comando en Unix. Soy consciente de que este truco lo confunde, la gente podría estarlo, pero a los comandos no les debería importar. Es solo un nombre de inicio de sesión diferente, pero tan pronto como inicie sesión, se usará el primer nombre que coincida con el uid en la base de datos de contraseñas, así que asegúrese de que el nombre de usuario real (aquí raíz) aparezca primero allí.
jlliagre
@Patrick ¿Has visto esto en la práctica? Por mucho que lo probé, las aplicaciones eligen al rootusuario si el rootusuario es el primero /etc/passwdcon UID 0. Tiendo a estar de acuerdo con jlliagre. El único inconveniente que veo es que cada usuario es un rootusuario y, a veces, puede ser confuso comprender quién hizo qué.
Martin
2

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.

Forma de vida alienígena
fuente
2

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.

Rohaq
fuente
1

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.

Julian
fuente
1

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.

Plaf
fuente
0

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;)

rackandboneman
fuente
0

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.

Tuncay Göncüoğlu
fuente
Debo agregar que manejar conexiones SSH es bastante básico en este contexto. Cualquiera sea el método que utilice, no permita los inicios de sesión de raíz a través de SSH, permita que los usuarios individuales ssh con sus propias credenciales y maneje sudo / nosudo / etc desde allí.
Tuncay Göncüoğlu