Compartir acceso de root sin compartir la contraseña

Versión corta:

1. Su solución sacrifica el registro y la auditoría de la responsabilidad, solo para que usted sepa.

2. Si el inicio de sesión directo de raíz es un problema, use un usuario genérico que no sea administrador para ssh y luego sudo para root.

3. Si desea ser inteligente, configure sudo (a través de pam) para solicitar un nombre de usuario y contraseña específicos para cada persona, de modo que la escalada de privilegios locales esté vinculada a la persona responsable.

Versión larga:

El inicio de sesión directo de raíz es malo por dos razones:

• Disminuye la barrera para que un atacante ingrese como root.
• Elimina el registro de auditoría que vincula los cambios del sistema con un individuo .
• Los auditores saltan por todas partes como comadrejas en tocino.

Si fuera a reemplazar el ssh root@[computer_in_lan1] con un usuario sin privilegios, por ejemplo, ssh myadmin@[computer_in_lan1] y luego requiera que el usuario use sudo para obtener privilegios de root, entonces deberá abordar el primer motivo. Sin embargo, el segundo sigue siendo un problema, porque si varios humanos pueden iniciar sesión en myadmin , ¿quién va a saber qué humano lo hizo?

Una forma de compensar sería exigir la autenticación por humano una vez que sea local al sistema. Una vez que el usuario inicia sesión como myadmin , ejecutará sudo su - para obtener privilegios de root. Una solución inteligente sería requerir autenticación individual de los seres humanos en este punto para que pueda vincular el acto de obtener privilegios de root de nuevo a una persona.

Como la mayoría de las cosas, sudo usa pam como su backend de autenticación. Y pam puede configurarse para pedir un nombre de usuario y salir por la red con algo como LDAP o RADIUS . Entonces, Joe inicia sesión como myadmin a través de ssh y escribe sudo su - ; Tendrá que ingresar el nombre de usuario 'joe' y su propia contraseña para obtener root. Cuando Kate inicie sesión con la misma cuenta genérica myadmin y escriba sudo su - , deberá proporcionar el nombre de usuario 'kate' y su propia contraseña para obtener la raíz.

Ahora, configurar eso sería tanto o más trabajo, en comparación con configurar una cuenta de usuario individual en todos los sistemas. El mantenimiento puede ser menor. Pero sería mucho más divertido hacerlo.

Le recomiendo que no permita el inicio de sesión directo como root a través de ssh en ningún sistema. Como se mencionó anteriormente en el comentario de gowenfawr, es mejor tener cuentas personales para todos los que administrarán el sistema en todos los nodos, y darles acceso a sudo a raíz localmente. No necesitarían una contraseña de root en ningún nodo para esto; usarían su propia contraseña u otras credenciales.

Esto se puede automatizar con herramientas de autenticación distribuidas como LDAP y RADIUS, o con una herramienta cliente-servidor en la que el cliente se ejecuta localmente en cada nodo, recopila la información de un sistema de autorización central y crea y mantiene el usuario individual. Cuentas en los sistemas.

Si falla, puede configurar una cuenta dedicada (no individual) en cada nodo cuyo propósito es ejecutar un conjunto específico de comandos como root a través del control de sudo, y tener un medio para las claves públicas de todos los los administradores en el "servidor de salto" central se distribuyeron a las authorized_keys para esta cuenta en todos los nodos.

La clave (el propósito del juego de palabras) es proteger contra el uso indebido o la intercepción de las claves privadas de los administradores en el nodo central al no permitir el acceso no restringido a la cuenta raíz de forma remota y, en cambio, confiar en la escalada de privilegios locales (sudo).