Visudo en Linux: modificar sudoers sin perder el acceso de root

un error en /etc/sudoers puede eliminar su último acceso de administrador mientras la sesión SSH aún está en ejecución. El riesgo a menudo proviene de una regla mal escrita, una ruta de comando incorrecta o un archivo agregado demasiado rápido a .

Nunca edito sudoers con un editor que se ejecuta directamente sobre el archivo. visudo Bloquea la configuración durante la edición y verifica su sintaxis antes de guardar. En un servidor remoto, mantén también abierta una segunda sesión de root hasta la prueba final. Esta medida de seguridad es tan importante como el propio comando.

Compruebe el acceso de superusuario antes de modificar una regla.

Primero, confirma que tu cuenta aún tiene privilegios de sudo y verifica qué comandos está autorizada a usar:

sudo-v
sudo-l
identificación
grupos

sudo-v Valida la información de autenticación sin ejecutar ningún comando sensible. sudo-l Muestra las reglas aplicadas a la cuenta. Si este paso falla, no modifique los permisos de sudo de esta sesión.

A continuación, abre una segunda terminal y mantén una sesión de administrador allí:

sudo-yo
OMS
w

Cuentas y grupos de Linux puede ayudarte a confirmar la cuenta objetivo antes de otorgarle privilegios.

Antes de editar, copie el archivo principal a una carpeta reservada para el usuario root. La opción -tiene conserva, en particular, al propietario, al grupo y al modo:

sudo cp -a /etc/sudoers "/root/sudoers.backup-$(date +%F-%H%M)"
sudo stat -c '%A %a %U:%G %n' /etc/sudoers /etc/sudoers.d

raíz: raíz cuatrocientos cuarentaNo modifique los permisos al azar si su distribución utiliza una política diferente. Primero, anote el estado actual y guarde la ruta exacta a la copia de seguridad.

Edita el archivo principal con visudo.

Para abrir la configuración principal, simplemente ejecute:

sudo visudo

Una regla de sudoers normalmente sigue esta lógica: usuario o grupo, hosts involucrados, identidad de ejecución y luego comandos autorizados. Para autorizar la cuenta Alicia Para reiniciar y comprobar solo Nginx, primero verifique la ruta del binario:

comando -v systemctl

Si el comando regresa /usr/bin/systemctlLa regla puede adoptar esta forma:

alice ALL=(root) /usr/bin/systemctl is-active nginx, /usr/bin/systemctl restart nginx

no usar SIN CONTRASEÑA Por costumbre. Para la automatización, limítela a una sola cuenta, un solo comando y argumentos controlados. Una regla general que otorga acceso a un intérprete de comandos, editor o comando que puede ejecutar otros programas suele equivaler a otorgar acceso de administrador completo.

Para una regla específica de un departamento o equipo, prefiero un fragmento separado del archivo principal grande. Ábralo con la opción -F :

sudo visudo -f /etc/sudoers.d/administration

Elija un nombre simple, sin espacios, puntos ni caracteres especiales, como por ejemplo: ~Según la directiva Utilizados por la distribución, algunos nombres pueden ser ignorados. Después del registro, verifique el propietario y el modo:

sudo chown root:root /etc/sudoers.d/administration

sudo stat -c '%A %a %U:%G %n' /etc/sudoers.d/administration

El tutorial general sobre sudo en linux Se detalla la delegación por usuarios, grupos y alias. En este caso, el objetivo es más específico: instalar una regla verificable sin perder la posibilidad de revertir a la versión anterior.

Confirme la configuración completa antes de realizar la prueba.

sudo visudo -c

El resultado debería indicar que los archivos analizados son sintácticamente correctos. Si se informa de un fragmento, vuelva a abrir ese archivo exacto con visudo -fNo reinicie la máquina ni cierre la sesión de root mientras la comprobación esté fallando.

Desde la sesión raíz conservada, muestre los derechos de la cuenta de destino:

sudo -l -U alice

Esta lectura permite identificar una regla que no se ha cargado, un nombre de usuario incorrecto o una autorización mucho más amplia de lo esperado.

Inicie una tercera sesión con la cuenta en cuestión. No utilice simplemente la sesión que ya tiene un ticket sudo en caché. Invalide esta caché, solicite la lista de privilegios y, a continuación, ejecute únicamente el comando autorizado:

sudo-k
sudo-v
sudo-l
sudo systemctl status nginx

Verifique también que se siga rechazando un comando inesperado. Una regla es correcta si el usuario conserva el acceso esperado sin obtener más privilegios de los necesarios. Cierre la sesión de root de respaldo solo después de esta prueba.

Restaurar sudoers si falla la validación o el acceso.

Si visudo -c Si falla, corrija el fragmento defectuoso de la sesión raíz aún abierta. Para volver al archivo guardado principal, reemplace la ruta con su copia de seguridad actual:

cp -a /root/sudoers.backup-AAAA-MM-DD-HHMM /etc/sudoers
visudo -c

Si todas las sesiones de administrador están cerradas, utilice la consola del proveedor, el modo de recuperación o un entorno en vivo para montar el sistema y reparar la configuración. Editar el archivo sudoers desde una cuenta sin privilegios no funcionará.

sudo journalctl -t sudo -b --no-pager
sudo tail -n 100 /var/log/auth.log

documenta el bloqueo, el control y la opción -F. Documentación sudoers(5) Esto describe la sintaxis, las inclusiones y las reglas de comandos. Sobre todo, mantenga este orden: acceso de copia de seguridad, guardar, editar con visudo

sudo apt update && sudo apt upgrade