Establecer la contraseña de sudo de manera diferente a la de inicio de sesión

Como usuario privilegiado, estoy tratando de establecer la sudocontraseña a otra que la utilizada al iniciar sesión.

He investigado un poco pero no he encontrado una respuesta. ¿ sudoSoporta ese tipo de configuración?

Si alguna vez pierde su contraseña, lo pierde todo. Alguien podría iniciar sesión y promocionarse rootcon la misma contraseña.

sudotiene una opción para solicitar una rootcontraseña en lugar de una contraseña de usuario invocada, ( rootpw), pero compartir la rootcontraseña definitivamente no es una opción, es por eso que configuramos sudo.

Lo hice config 2FAen el pasado, funcionó muy bien, pero también derrota el propósito de la automatización. Por ejemplo, si desea ejecutar un comando privilegiado en una docena de servidores con un expectscript, agregar 2FAno le permite hacerlo.

La solución más cercana que he encontrado es permitir solo la clave privada SSH y configurar la sudocontraseña con una clave que difiera de la contraseña (inicio de sesión). Aún así, no es cómodo, porque en una situación de emergencia no puede iniciar sesión con una PC donde no tiene esa clave.

Si desea solicitar la contraseña de root, en lugar de la contraseña del usuario, hay opciones que puede ingresar /etc/sudoers. rootpwen particular hará que solicite la contraseña de root. Hay runaspwy targetpwtambién; vea la página de manual de sudoers (5) para más detalles.

Aparte de eso, sudo hace su autenticación (como todo lo demás) a través de PAM. PAM admite la configuración por aplicación. La configuración de Sudo está en (al menos en mi sistema Debian) /etc/pam.d/sudo, y se ve así:

$ cat sudo 
#%PAM-1.0

@include common-auth
@include common-account
@include common-session-noninteractive

En otras palabras, de manera predeterminada, se autentica como todo lo demás en el sistema. Puede cambiar esa @include common-authlínea y hacer que PAM (y, por lo tanto, sudo) use una fuente de contraseña alternativa. Las líneas no comentadas en common-auth tienen un aspecto similar (de forma predeterminada, esto será diferente si está utilizando, por ejemplo, LDAP):

auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Puede usar, por ejemplo, en pam_userdb.solugar de pam_unix.soy almacenar sus contraseñas alternativas en una base de datos de Berkeley DB.

ejemplo

Creé el directorio /var/local/sudopass, propietario / grupo root:shadow, modo 2750. Dentro de él, seguí adelante y creé un archivo de base de datos de contraseñas usando db5.1_load(que es la versión de Berkeley DB en uso en Debian Wheezy):

# umask 0027
# db5.1_load -h / var / local / sudopass -t hash -T passwd.db
Antonio
WMaEFvCFEFplI
^D

Ese hash se generó con mkpasswd -m desla contraseña "contraseña". Muy seguro! (Desafortunadamente, pam_userdb parece no admitir nada mejor que el crypt(3)hashing antiguo ).

Ahora, edite /etc/pam.d/sudoy elimine la @include common-authlínea, y en su lugar ponga esto en su lugar:

auth    [success=1 default=ignore]      pam_userdb.so crypt=crypt db=/var/local/sudopass/passwd
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Tenga en cuenta que pam_userdb agrega una .dbextensión a la base de datos pasada, por lo que debe dejarla .dbdesactivada.

Según dannysauer en un comentario , es posible que también deba realizar la misma edición /etc/pam.d/sudo-i.

Ahora, para sudo, debo usar en passwordlugar de mi contraseña de inicio de sesión real:

anthony @ sudotest: ~ $ sudo -K
anthony @ sudotest: ~ $ sudo echo -e '\ nit trabajado'
[sudo] contraseña para anthony: passwordRETURN

funcionó

Para Redhat / Centos, el requisito se puede lograr con los siguientes pasos:

Crear usuario personalizado y pasar:

# db_load -t hash -T /usr/local/etc/passwd.db
user
pass
^d

Edite el archivo sudo pam.d para que se vea así:

$ cat /etc/pam.d/sudo

auth            required        pam_userdb.so db=/usr/local/etc/passwd
account         required        pam_userdb.so db=/usr/local/etc/passwd
password        include         system-auth

session         optional        pam_keyinit.so revoke
session         required        pam_limits.so

Todavía estoy buscando la forma de configuración, de modo que solo un determinado usuario / grupo debe ser autenticado por este método personalizado, otros aún pueden ser autenticados por el método normal de autenticación del sistema. ¿Alguien puede darme algunos consejos?

No creo que sudo sea compatible con tal configuración. El propósito de la solicitud de contraseña de sudo es garantizar que la persona que emite el comando sudo sea la misma persona que inició sesión, y la forma más fácil de hacerlo es solicitar que el usuario actualmente conectado se vuelva a autenticar.

En otras palabras, el propósito de la solicitud de contraseña de sudo no es establecer autoridad , es establecer identidad . Según la identidad establecida y la configuración de sudo, se puede tomar una decisión si el usuario en cuestión tiene la autoridad o los derechos de acceso necesarios.

Su preocupación es que la contraseña de su cuenta pueda ser revelada. La solución es no usar la contraseña de inicio de sesión de manera que pueda ser revelada. Con ssh, la contraseña se cifra en el cable, por lo que está bien. La gente apaga la autenticación de contraseña con ssh para evitar ataques de adivinación de contraseña, no para proteger la confidencialidad de la contraseña. Si usa la misma contraseña de cuenta para cualquier otra cosa, asegúrese de estar usando un canal seguro y encriptado para proporcionar la contraseña. Si le preocupa un keylogger o lo que sea, deje de usar máquinas que no sean de confianza para iniciar sesión.

Si alguien puede obtener su contraseña ssh, probablemente también pueda obtener la contraseña alternativa de sudo, por lo que es mejor invertir tiempo en hacer que sus conexiones sean más seguras que pasar tiempo simplemente complicando las cosas solo por la ilusión de una mayor seguridad.

No tengo acceso inmediato a un sistema donde pueda probar esto y resolver los detalles, pero tengo una idea:

• (Suponga que su cuenta de inicio de sesión normal es shau).
• Crear una segunda cuenta: shau2. (No estoy seguro de si desea que tenga el mismo UID que shau).
• Configure shau2para tener privilegios de sudo con NOPASSWD.
• Configure un alias o un script de shell para hacer su shau2 -c sudo "$@". Esto debería pedir shau2la contraseña de. Si se ingresa correctamente, se ejecutará sudocomo shau2 (lo que no debería solicitar una contraseña).
• Eliminar shaulos privilegios de sudo.

Desafortunadamente, tendría que repetir esto para cada usuario que tenga privilegios de sudo.

Gracias @ Shâu Shắc por la respuesta ! Esa solución también funciona para LinuxMint 17.1 Cinnamon 32bit (solo he instalado el db-utilpaquete para ejecutarlo db_load).

Pero estoy muy confundido con el passwd.dbarchivo resultante . Hice lo mismo que en su respuesta (pero usé a David y Jones , se ven más llamativos):

# db_load -t hash -T /usr/local/etc/passwd.db
david
jones
^d

Pero las credenciales ingresadas se almacenan dentro del archivo hash como texto sin formato:

# grep 'jones.*david'  /usr/local/etc/passwd.db
Binary file /usr/local/etc/passwd.db matches

También puede ver a David y Jones a través de mcedit :

Sí, es posible restringir los permisos de /usr/local/etc/passwd.db. Pero de todos modos, el nombre de usuario y la contraseña almacenados como texto sin formato son incorrectos.

Incluso con una contraseña de sudo separada, existen algunos posibles agujeros de seguridad (por defecto, configuración de distribución). Por lo tanto, una contraseña separada no es aplicable para su (por lo que es posible iniciar sesión raíz usando una sucontraseña de inicio de sesión). Además, Policy Kit no respeta las contraseñas separadas (es posible iniciar Synaptic con una synaptic-pkexeccontraseña de inicio de sesión. Luego, elimine los paquetes ...). Estos problemas pueden eliminarse mediante el ajuste adicional de los archivos de configuración.

En general, parece que la contraseña segura de sudo por separado solo se puede lograr con la ayuda del módulo PAM personalizado (tal vez, dicho módulo comparará la contraseña y la lectura de hash SHA-512 del archivo) o la funcionalidad de SELinux.

PD: lo siento, debería ser un comentario. Pero va como respuesta debido al formato de texto. Gracias por entender.