Linux / Comando / sudo: ejecutar comandos permitidos y configurar sudoers
sudo es una herramienta que permite a un usuario autorizado por la política de seguridad ejecutar un comando con los permisos de otro usuario. Si no se especifica un usuario destinatario, generalmente se ejecuta como root, pero los permisos reales y el método de autenticación se determinan de acuerdo con la política sudo del sistema.
Es útil cuando se realizan tareas que requieren privilegios de administrador, como la instalación de paquetes o la gestión de servicios, pero si se introduce mal un comando, puede afectar a todo el sistema. Antes de ejecutar, verifique los archivos de destino y las opciones, y otorgue los mínimos privilegios necesarios solo a los comandos necesarios.
Este artículo describe principalmente sudo.ws y su política sudoers tradicional. Ubuntu 26.04 puede utilizar sudo-rs, con un conjunto distinto de funciones. Compruebe primero sudo --version y sudo --help y consulte las diferencias entre sudo.ws y sudo-rs en Ubuntu antes de aplicar opciones o reglas.
¿Qué es el comando sudo?
sudo permite a los usuarios autorizados ejecutar comandos como superusuario o como otros usuarios. No es simplemente una herramienta que otorga privilegios de administrador a todos los usuarios, sino una estructura que controla mediante políticas quién puede ejecutar qué comando con qué privilegio de usuario en qué host.
El complemento de política predeterminado es sudoers y generalmente utiliza las configuraciones de /etc/sudoers y /etc/sudoers.d/. El sistema compara las solicitudes de ejecución con la política y, si es necesario, autentica al usuario antes de ejecutar únicamente los comandos permitidos.
Puede consultar el manual oficial de sudo para la forma detallada de ejecución y el manual oficial de sudoers para la sintaxis de las políticas.
Sintaxis básica y primera ejecución
La sintaxis general es la siguiente.
sudo [OPCIONES] COMANDO [ARGUMENTOS...]
Un ejemplo de actualización de la lista de paquetes en sistemas basados en Debian o Ubuntu es el siguiente.
sudo apt update
Si se requiere autenticación, normalmente se solicita la contraseña del usuario actualmente conectado. Existen implementaciones y configuraciones que ocultan la entrada de la contraseña, pero en Ubuntu 26.04, el sudo-rs por defecto muestra un feedback con asteriscos. La visualización de estos depende del programa proporcionado y de la política pwfeedback, por lo que no se puede determinar el éxito o error únicamente por eso. Según la política del sistema, también puede requerirse la contraseña del usuario objetivo u otros métodos de autenticación.
Si se permiten los permisos y la autenticación es exitosa, solo el proceso apt update se ejecuta con los permisos del destino. La shell actual no se convierte automáticamente en una shell de administrador.
Opciones de sudo usadas con frecuencia
| Opciones | Función | Ejemplos de uso y puntos de precaución |
|---|---|---|
-u USUARIO |
Ejecutar comando como usuario especificado | sudo -u postgres psql |
-g GRUPO |
Ejecutar comando como grupo especificado | Solo disponible para grupos permitidos por la política |
-l |
Verificar los comandos permitidos para el usuario actual | Útil para revisar el alcance de permisos antes de ejecutar |
-v |
Verificar o renovar información de autenticación | Actualizar la marca de tiempo sin ejecutar el comando |
-k |
Invalidar la marca de tiempo de autenticación actual | Vuelve a pedir autenticación si la política del comando la exige; no anula NOPASSWD. |
-K |
Eliminar completamente la marca de tiempo de autenticación del usuario | Inicialización más fuerte que -k |
-i |
Ejecutar el shell del usuario objetivo | Se utiliza para varias tareas administrativas, pero el alcance se amplía |
-s |
Ejecutar shell | Puede verse afectado por el entorno de la llamada, verificar el propósito |
-n |
Ejecución no interactiva | Si se necesita la contraseña, fallar sin preguntar |
-H |
Solicitar establecer HOME como el directorio personal del usuario objetivo | Funciona según la política y no siempre es necesario |
-E |
Solicitar conservar las variables de entorno del usuario | Debe ser permitido por la política y usarse cuidadosamente por razones de seguridad |
-e, sudoedit |
Modificar archivos que requieren permisos en un flujo de edición seguro | sudoedit /etc/example.conf |
Ejecutar con permisos de otro usuario
Especificar el usuario objetivo con -u
Si omite el usuario objetivo, normalmente se utiliza root. Si se especifica -u, se puede ejecutar como otro usuario permitido por la política.
sudo -u postgres psql
Es útil cuando necesita ejecutar comandos en los permisos de archivos o en el entorno de la cuenta de servicio. Sin embargo, dado que algunas cuentas de servicio tienen shell de inicio de sesión restringido, primero verifique el propósito y la política de dicha cuenta.
Comprobar el usuario que ejecuta
Para verificar rápidamente qué permisos de usuario otorga realmente la política actual, se puede usar id.
sudo id
sudo -u postgres id
La salida real varía según la configuración de usuarios y grupos del sistema. Para una verificación simple, es más limitado examinar con comandos individuales que abrir un shell de administrador.
Comprobación de permisos permitidos y caché de autenticación
Ver los comandos que se pueden ejecutar con sudo -l
sudo -l muestra la configuración predeterminada aplicada al usuario actual y los comandos que puede ejecutar. Cuando ocurre un error de falta de permisos, puede verificar antes de cambiar la configuración sin precaución.
sudo -l
Los administradores, si tienen los permisos necesarios, pueden verificar las políticas de otros usuarios con -U, pero los usuarios normales normalmente solo consultan sus propios permisos.
Renovar la autenticación con sudo -v
sudo -v verifica o renueva la información de autenticación almacenada sin ejecutar comandos. Se puede usar para preparar el estado de autenticación antes de iniciar varios comandos de administración.
sudo -v
El tiempo y el alcance básicos del caché de autenticación dependen de la política de sudoers. Que no se pida la contraseña durante un cierto tiempo no significa que todos los comandos estén permitidos; cada comando sigue siendo verificado por la política.
Borrar el estado de autenticación con sudo -k
Para que se requiera autenticación nuevamente en la próxima ejecución después de usar un terminal público o completar tareas administrativas, use sudo -k.
sudo -k
-K elimina completamente la marca de tiempo de autenticación del usuario. Verifique los detalles según la versión de sudo instalada y la política.
Consideraciones al encadenar comandos y usar tuberías
sudo solo se aplica al comando inmediatamente posterior
En el siguiente comando, sudo se aplica solo al primer apt update. El apt upgrade posterior se ejecuta con los permisos del usuario actual.
sudo apt update && apt upgrade
Si ambos comandos requieren privilegios de administrador, la manera más clara es adjuntar sudo a cada uno.
sudo apt update && sudo apt upgrade
Para entender con precisión las condiciones de ejecución de los operadores de conexión, también puede consultar Uso de operadores de conexión de comandos de Bash.
Ambos lados de una tubería son procesos separados
Cada comando conectado por una tubería se ejecuta por separado. En el ejemplo siguiente, solo el primer comando se ejecuta con permisos de destino y grep se ejecuta con el usuario actual.
sudo some-command | grep 'pattern'
Los comandos de filtro de solo lectura a menudo son suficientes con permisos de usuario normal. En lugar de darle altos privilegios a toda la tubería, limite la ejecución a los pasos que realmente necesitan permisos.
La manera de ejecutar todo el shell tiene un alcance amplio
Aunque puede ejecutar varios comandos en el shell del destino con permisos como sudo sh -c 'COMANDO1 && COMANDO2', las reglas de citación son complicadas y el alcance de los permisos se amplía. Para tareas simples, es ventajoso para la revisión y el registro especificar sudo en cada comando.
Razón por la que se produce 'Permission denied' en la redirección
La redirección de salida la maneja el shell actual
El shell que recibe el comando procesa la redirección. Los ejemplos siguientes usan /etc/example.conf como ruta ilustrativa: no los copie sobre un archivo real sin conocer su función, guardar una copia y decidir si va a sustituir o añadir contenido. El primer comando puede fallar porque sudo no eleva los permisos del shell que abre el archivo.
sudo echo 'value' > /etc/example.conf
Elevar permisos solo para la escritura necesaria con tee
Para escribir una línea corta, puede pasar la entrada estándar a sudo tee.
printf '%s\n' 'value' | sudo tee /etc/example.conf > /dev/null
Para agregar al final de un archivo existente, use tee -a. Asegúrese de comprobar la ruta de destino y si se sobrescribirá antes de ejecutar.
printf '%s\n' 'value' | sudo tee -a /etc/example.conf > /dev/null
Editar los archivos de configuración con sudoedit
Si va a modificar varias líneas de configuración, sudoedit es más adecuado. Edite la copia temporal permitida por la política con el usuario actual y luego refleje los cambios en el archivo original.
sudoedit /etc/example.conf
Puede reducir el alcance de los permisos en lugar de ejecutar todo el editor con privilegios de administrador, pero las restricciones reales sobre enlaces simbólicos y directorios con permisos de escritura siguen la versión de sudo y la política.
Shell de administrador: sudo -i y sudo -s
| Método | Comportamiento general | Situaciones adecuadas |
|---|---|---|
sudo COMANDO |
Ejecutar un solo comando con los permisos del objetivo | Recomendado para la mayoría de las tareas administrativas de una sola vez |
sudo -i |
Ejecutar un shell que emule el entorno de inicio de sesión del usuario objetivo | Cuando son necesarias tareas administrativas consecutivas |
sudo -s |
Ejecutar el shell del usuario que llama o el shell especificado por el entorno | Entender las diferencias del entorno y usar un shell si es necesario |
En un shell de administrador, cada comando que ingrese después no mostrará sudo, por lo que es difícil comprender el alcance de los errores. Si solo realiza una o dos tareas, use el formato sudo COMANDO en lugar del shell de administrador, y si abre un shell, siga verificando el indicador de comandos y el usuario/directorio de trabajo actual.
Modificar sudoers con visudo
¿Por qué no se debe editar directamente?
Antes de editar, guarde una copia de la política y mantenga abierta una vía administrativa de recuperación. Un error puede impedir nuevas ejecuciones de sudo. Use visudo para bloquear el archivo durante la edición y comprobar la sintaxis; si detecta un error, vuelva a editar o salga sin guardar, en vez de forzar la aceptación.
sudo visudo
Puede consultar los procedimientos de edición segura en la página del manual oficial de visudo.
Usar archivos sudoers.d separados
Para dividir las reglas por rol, puede crear un archivo separado debajo de /etc/sudoers.d/. Primero, verifique si el sudoers predeterminado del sistema incluye este directorio y también revise las reglas de nomenclatura de archivos.
sudo visudo -f /etc/sudoers.d/service-maintenance
Algunas configuraciones de sudoers pueden ignorar elementos con un punto en el nombre del archivo o que terminen con una tilde, por lo que es más seguro usar nombres simples con letras, números y guiones.
Verificar toda la sintaxis después de modificar
Para verificar la sintaxis del sudoers existente y de los archivos incluidos, utilice el siguiente comando.
sudo visudo -c
El éxito en la verificación no significa que el diseño de permisos sea seguro. Es recomendable mantener una sesión administrativa separada y comprobar sudo -l con el usuario objetivo, probar los comportamientos permitidos y denegados, y luego cerrar la sesión.
Estructura básica de las reglas de sudoers
Conceptualmente, las reglas de sudoers combinan los siguientes elementos.
USUARIO HOST=(USUARIO_DESTINO:GRUPO_DESTINO) ETIQUETA: COMANDO
| Elemento | Significado | Puntos a verificar durante el diseño |
|---|---|---|
| Usuario o grupo | Sujeto al que se aplicará la regla | El grupo generalmente se representa como %NOMBRE_DE_GRUPO |
| Host | Sistema en el que la regla es válida | No ampliar excesivamente el alcance del host desde la política central |
| Usuario o grupo que ejecuta | Cuenta objetivo en la que se ejecutará el comando | Especificar solo las cuentas necesarias más que ALL |
| Etiquetas | Ajuste de la autenticación, ejecución y registro de acciones | NOPASSWD y otros se utilizan de manera limitada después de evaluar el riesgo |
| Comandos y argumentos | Archivos ejecutables permitidos y argumentos opcionales | Se limita el alcance con rutas absolutas y argumentos fijos |
El siguiente es un ejemplo que restringe al usuario deploy a realizar como root únicamente el reinicio y la verificación del estado de servicios específicos. Antes de aplicarlo realmente, se debe revisar si dicho comando permite de manera indirecta ejecutar otros comandos o modificar archivos.
deploy ALL=(root) /usr/bin/systemctl restart webapp.service, /usr/bin/systemctl is-active webapp.service
La cuenta deploy, la ruta de systemctl y webapp.service son ejemplos: confirme que existen y que corresponden al servicio autorizado. Proteja también la unidad del servicio, sus ejecutables, archivos de entorno y directorios; si deploy puede modificar contenido que luego se ejecuta como root, limitar la línea de systemctl no limita realmente sus privilegios. Compruebe con la cuenta de destino qué operaciones se permiten y cuáles se deniegan antes de cerrar la vía de recuperación.
Diseñar sudoers con los permisos mínimos
No usar ALL y NOPASSWD de manera habitual
Reglas como ALL=(ALL) NOPASSWD: ALL en realidad proporcionan amplios privilegios de administrador sin intervención. Incluso si se necesita automatización, se deben diseñar cuentas dedicadas, archivos de ejecución e argumentos fijos, registros, protección de información secreta y rutas de llamada.
Tener precaución con programas que pueden permitir escapar del shell
Programas que pueden invocar editores, paginadores o shells, herramientas que escriben archivos arbitrarios o cargan complementos pueden parecer comandos limitados pero pueden llevar a un shell de administrador. No juzgue la seguridad solo por el nombre del comando; revise todas las funciones del programa, variables de entorno y archivos de configuración.
Restringir específicamente la ruta y los argumentos del comando
Especifique los comandos con rutas absolutas y, si es posible, fije también los argumentos permitidos. Los comodines y las reglas de negación pueden coincidir con rutas inesperadas o ser eludidos, por lo que se debe entender correctamente la coincidencia de comandos en sudoers antes de usarlos.
Registrar los cambios de permisos y revisarlos regularmente
Para cambiar la política de sudo, es recomendable dejar constancia del solicitante, revisor, propósito y condiciones de expiración. Elimine cuentas y reglas que no se usan y verifique regularmente, basándose en los registros reales y los resultados de sudo -l, que no haya permisos excesivos.
Razones por las que cambian las variables de entorno y las rutas
sudo puede no copiar el entorno tal como está
La configuración predeterminada de sudoers puede eliminar variables de entorno peligrosas o configurar un entorno restringido. PATH, HOME, variables de proxy o la configuración del idioma pueden diferir de la shell habitual, haciendo que los comandos se comporten de manera diferente.
sudo env
Para solucionar problemas, se puede comparar con los resultados de env del entorno de un usuario normal, pero revise el contenido antes de compartirlo, ya que la salida puede incluir tokens o información confidencial.
Usar sudo -E con precaución
-E solicita política para preservar el entorno del usuario que llama. La política puede rechazarlo, y los valores de entorno como rutas de librerías, proxy y rutas de ejecución pueden cambiar el comportamiento de programas con altos privilegios. Generalmente, es más seguro permitir explícitamente solo las variables necesarias en sudoers.
Usar sudo en la automatización
Evitar esperar la contraseña con -n
En tareas automatizadas, si se espera la introducción interactiva de la contraseña, la tarea puede detenerse. -n hace que falle inmediatamente cuando se requiere la autenticación.
sudo -n /usr/bin/systemctl restart webapp.service
El éxito debe verificarse mediante el estado de salida y los registros. No coloque la contraseña en scripts o en la línea de comandos, ya que podría exponerse en la lista de procesos, el historial del shell o los registros.
Permitir solo los comandos necesarios de manera no interactiva
Si la ejecución sin supervisión es absolutamente necesaria, permita solo los comandos y argumentos específicos en una cuenta de servicio dedicada, y asegúrese de que esa cuenta no pueda modificar los archivos ejecutables ni la configuración relacionada. En lugar de otorgar amplios privilegios de NOPASSWD, también se pueden considerar API específicas para la tarea, servicios systemd o programas auxiliares con permisos restringidos.
Errores frecuentes y soluciones
| Mensaje o síntoma | Posibles causas | Método de verificación |
|---|---|---|
user is not in the sudoers file |
No hay reglas de permiso para el usuario | Transmitir al administrador los comandos y objetivos necesarios |
not allowed to execute |
La combinación de comando y argumento no coincide con la política | Verificar el alcance permitido en sudo -l |
command not found |
El PATH de sudo es diferente del shell del usuario | Verificar la ruta absoluta y secure_path |
| Se solicita la contraseña nuevamente | Caducidad de la caché de autenticación o diferencia entre terminal y política | Verificar la política y la configuración de la marca de tiempo |
| Acceso denegado en la redirección | El shell actual intenta abrir primero un archivo protegido | Use sudoedit o tee restringido |
| Error de sintaxis en sudoers | Edición directa o regla incorrecta | Verificación con visudo -c en la sesión de recuperación |
Principios de seguridad al usar sudo
- Verifique directamente las opciones y la ruta de destino antes de ejecutar comandos copiados de Internet o documentos.
sudo rm, los comandos relacionados con discos, particiones, firewall y cuentas deben revisar primero los métodos de recuperación y sus impactos.- No se mantiene la shell de administrador por mucho tiempo debido a un comando de una sola vez.
- No se deben introducir contraseñas, tokens y claves privadas indiscriminadamente en la línea de comandos, scripts o variables de entorno.
- No se otorgan permisos elevados a scripts o archivos ejecutables que pueden ser modificados por el usuario.
- Verifique la ubicación de los registros de sudo y la política de retención, y en entornos críticos revise los registros centrales y la auditoría de entrada/salida.
Aunque sudo registra los comandos, no todos los comandos individuales ejecutados después de sudo sh o de una salida de shell permanecen en los registros tradicionales de comandos. Debe verificarse si el registro de entrada/salida está configurado por separado.
Preguntas frecuentes
¿Siempre sudo se ejecuta con privilegios de root?
Si se omite el usuario objetivo, normalmente root es el predeterminado, pero se puede especificar otro usuario con -u y la aprobación real depende de la política. El núcleo de sudo no es la ejecución exclusiva como root, sino ejecutar comandos con los privilegios de otros usuarios permitidos.
¿Por qué sudo no pide contraseña?
Una caché válida o una regla NOPASSWD puede evitar la pregunta. sudo -k invalida la credencial almacenada para el ámbito que define la política, pero no cambia sus reglas: un comando con NOPASSWD seguirá sin pedir contraseña. Consulte sudo -l y la documentación de la implementación.
¿Por qué sudo cd no cambia el directorio actual?
cd es un comando interno del shell que cambia el directorio de trabajo del shell actual. Cambiar el directorio en un proceso separado no afecta al shell principal. Para ejecutar un comando en un directorio específico, verifique las opciones de directorio de trabajo que el comando soporta o si sudo admite -D.
¿Se puede modificar el archivo sudoers con un editor normal?
No se recomienda. Los errores de sintaxis pueden impedir el uso de sudo, por lo que debe usar visudo. También se debe editar cualquier archivo independiente con sudo visudo -f /etc/sudoers.d/ARCHIVO y verificar toda la configuración con sudo visudo -c.
Resumen
Para un comando que requiere privilegios de administrador, se verifica con sudo COMANDO, para ejecutar como otro usuario con sudo -u USUARIO COMANDO y el alcance permitido con sudo -l. El estado de autenticación se puede actualizar con -v y desactivar después de la tarea con -k.
El archivo de configuración utiliza visudo y sudoedit, y las reglas de sudoers deben diseñarse basándose en rutas absolutas, argumentos fijos y privilegios mínimos. Para revisar otros comandos administrativos básicos, se puede consultar Lista de comandos de uso frecuente en Linux.




