Cómo usar sudo en Linux y dominar el archivo sudoers

  • sudo permite ejecutar comandos como otro usuario (normalmente root) de forma controlada y temporal.
  • La configuración de permisos se define en /etc/sudoers y en los archivos de /etc/sudoers.d usando visudo.
  • Grupos como sudo o wheel y alias en sudoers facilitan otorgar privilegios específicos a usuarios concretos.
  • Opciones como NOPASSWD permiten ajustar la seguridad y la comodidad al usar sudo en distintos escenarios.

usar sudo en linux

Si trabajas con Linux a diario, tarde o temprano te toparás con el comando sudo. Es la llave que te permite hacer tareas de administración sin tener que entrar como usuario root todo el rato, algo que además de incómodo, es bastante peligroso. Entender bien cómo funciona, qué opciones tiene y cómo se configura es fundamental si no quieres cargarte el sistema por un despiste o dejar un agujero de seguridad sin darte cuenta.

En este artículo vamos a bajar al detalle de qué es exactamente sudo, qué relación tiene con el usuario root y con el archivo /etc/sudoers, qué diferencias hay entre usar su y sudo, y cómo puedes afinar la configuración para dar permisos muy concretos (incluso sin pedir contraseña) a determinados usuarios o grupos. La idea es que, cuando termines de leer, tengas muy claro cuándo usar sudo, qué hace por debajo y cómo controlarlo sin miedo.

Qué es sudo y por qué es tan importante en Linux

El comando sudo es una de las piezas clave de cualquier sistema Linux moderno. Su nombre suele explicarse como “superuser do” o “substitute user and do”, y su función es sencilla pero potente: permite que un usuario autorizado ejecute comandos como si fuera otro usuario del sistema, normalmente root, durante un tiempo limitado.

En la práctica, esto significa que un usuario normal puede realizar tareas administrativas -instalar paquetes, modificar configuración del sistema, gestionar servicios, cambiar permisos de archivos sensibles- sin iniciar sesión directamente como root. Esta separación entre el usuario habitual y el superusuario es uno de los pilares de la seguridad en Linux.

La mayoría de distribuciones actuales (Debian, Ubuntu, muchas derivadas, sistemas tipo SLE, etc.) traen sudo preinstalado, y no se recomienda desinstalarlo ni “toquetearlo” a la ligera. Además, en muchos sistemas el usuario que se crea durante la instalación se añade automáticamente al grupo administrativo que tiene permiso para usar sudo, convirtiéndose en el usuario con privilegios por defecto.

Algo muy importante a tener en cuenta es que sudo no “convierte” a un usuario en root para todo, sino que le permite ejecutar comandos concretos como otro usuario, bajo unas reglas definidas en su configuración. De esta forma, se pueden conceder permisos muy específicos sin regalar acceso total al sistema.

Cómo funciona sudo internamente

El funcionamiento básico de sudo es muy simple desde el punto de vista del usuario: se coloca la palabra sudo delante del comando que queremos ejecutar con privilegios. Por ejemplo, para actualizar la lista de paquetes con apt-get en Debian o Ubuntu, un usuario normal necesitará hacer algo como:

> sudo apt-get update

Si intentas ejecutar un comando administrativo sin sudo, lo más habitual es que recibas errores del tipo “Permiso denegado” o mensajes indicando que no se puede abrir un determinado archivo de bloqueo en /var/lib o en otro directorio del sistema. En cuanto repites el mismo comando añadiendo sudo delante, el sistema te pedirá la contraseña y, si está todo bien configurado, la orden se ejecutará con privilegios de superusuario.

Cuando ejecutas un comando con sudo, el programa comprueba primero si tu usuario está autorizado a usarlo y para qué comandos concretos, consultando el archivo de configuración /etc/sudoers y, en muchos sistemas, los ficheros adicionales del directorio /etc/sudoers.d/. Si las reglas lo permiten, sudo solicita la contraseña (normalmente la tuya, no la de root) y eleva temporalmente tus privilegios para ejecutar el comando como el usuario de destino.

Un detalle curioso que suele despistar al principio es que, cuando se te pide la contraseña en la terminal, no aparece ningún carácter ni siquiera asteriscos mientras escribes. Es totalmente normal: la entrada va “a ciegas” y forma parte de las medidas de seguridad para que no se vea cuántos caracteres tiene tu contraseña.

Además, sudo mantiene una especie de “sesión de confianza”: tras introducir correctamente la contraseña, los privilegios elevados permanecen activos durante un intervalo de tiempo (por defecto, unos 15 minutos en muchas distribuciones) en esa misma terminal. Durante ese periodo, podrás ejecutar más comandos con sudo sin que te vuelva a preguntar la contraseña una y otra vez.

Sintaxis básica y opciones más útiles de sudo

La sintaxis general de sudo es muy sencilla:

> sudo comando

Lo más habitual es usarlo simplemente como sudo comando, pero tiene un buen puñado de opciones interesantes. Algunas de las más usadas (y que muchas guías oficiales destacan) son las siguientes:

  • -h: muestra un mensaje de ayuda con la sintaxis y todas las opciones disponibles del programa sudo.
  • -V: enseña la versión actual de sudo y algunos detalles de compilación.
  • -v: renueva el “tiempo de gracia” de la autenticación, es decir, refresca el contador para que no caduquen tus privilegios y no tengas que volver a meter la contraseña en breve.
  • -k: invalida de inmediato las credenciales almacenadas; es como decirle a sudo que “olvide” que ya te has autenticado, obligando a volver a pedir la contraseña la próxima vez.
  • -l: muestra qué comandos estás autorizado a ejecutar con sudo según la configuración actual de sudoers.

También hay opciones muy útiles para ejecutar comandos como otros usuarios distintos de root. Por ejemplo, con -u puedes especificar un usuario de destino para un comando concreto:

> sudo -u pedro whoami

En este caso, aunque tu sesión sea de otro usuario, el comando whoami devolverá “pedro”, porque se ha ejecutado como si fueras ese usuario. Esto resulta muy cómodo para probar permisos o realizar tareas asociadas a cuentas de servicio sin tener que cambiar de sesión manualmente.

sudo frente a su y al usuario root

En Linux conviven varios mecanismos para obtener privilegios de administrador: registrarse directamente como root, usar el comando su y usar sudo. Cada uno tiene sus pros y sus contras, y entenderlos te evitará muchos disgustos.

Entrar directamente como root (por ejemplo, con ssh root@servidor) te da acceso completo al sistema desde el primer momento. Esto es muy cómodo, pero también extremadamente peligroso: cualquier comando mal tecleado puede borrar medio sistema, cambiar permisos críticos o dejar la máquina inutilizable. Por eso, en la mayoría de casos no se recomienda trabajar con sesiones de root abiertas de forma permanente.

El comando su (substitute user) permite cambiar a otro usuario dentro de la misma terminal. La sesión original se mantiene en segundo plano y “encapsula” la nueva. Si ejecutas su pedro, se te pedirá la contraseña de pedro y, una vez dentro, si tecleas exit regresarás al usuario anterior. Si no especificas ningún nombre de usuario, su intenta por defecto cambiar a root.

Hay un matiz importante con su: si no le pasas la opción de login (su -, su -l o su --login), cambia de usuario pero no de entorno. Esto significa que seguirás en el directorio de trabajo y con las variables del usuario anterior, lo que puede provocar errores de permisos (por ejemplo, al intentar listar el home del usuario original con las credenciales del nuevo).

En cambio, sudo ofrece un enfoque más seguro y controlable. No necesitas conocer la contraseña de root, sino tu propia contraseña, y el sistema decide, mediante /etc/sudoers, qué usuarios pueden ejecutar qué comandos, como qué usuarios y desde qué máquinas. Además, cada uso de sudo queda registrado en los logs, lo que facilita auditar qué se ha hecho con permisos elevados.

Para sesiones interactivas “como otro usuario” con sudo, existen variantes muy prácticas:

  • sudo -s: abre una shell como el usuario de destino heredando el entorno del usuario actual.
  • sudo -i: inicia una shell de login completa del usuario de destino, con su entorno limpio y su directorio $HOME, cargando archivos como .profile o .bash_profile.

Ambas opciones son útiles para trabajar puntualmente como otro usuario (normalmente root o alguna cuenta de servicio) sin tener que recordar y usar su contraseña, manteniendo al mismo tiempo el control y el registro de las acciones realizadas.

El archivo /etc/sudoers y el directorio /etc/sudoers.d

El corazón de la configuración de sudo está en el archivo /etc/sudoers. Ahí se definen quién puede usar sudo, desde dónde, como qué usuario y qué comandos concretos puede ejecutar. Además, muchas distribuciones incluyen una directiva que carga automáticamente todos los ficheros de configuración adicionales ubicados en /etc/sudoers.d/.

Es crucial entender que /etc/sudoers no se debe editar “a pelo” con un editor de texto cualquiera. Siempre hay que modificarlo mediante el comando visudo, que abre el archivo con un editor (por defecto vi o nano, según configuración), pero añade una capa de seguridad: comprueba la sintaxis antes de guardar y evita que dos personas lo editen a la vez.

El uso típico para editar sudoers es:

> sudo visudo -f /etc/sudoers

También puedes crear archivos específicos en /etc/sudoers.d/ para separar configuraciones por grupos de usuarios, servicios, etc. Por ejemplo, puedes tener un fichero /etc/sudoers.d/networking con reglas específicas para administración de red, sin mezclarlo con el resto de la configuración general.

Al abrir /etc/sudoers en un sistema típico, verás líneas como estas (sin contar los comentarios):

  • root ALL=(ALL:ALL) ALL: el usuario root puede ejecutar cualquier comando en cualquier host, como cualquier usuario y cualquier grupo.
  • %admin ALL=(ALL) ALL: cualquiera dentro del grupo admin tiene permisos totales para usar sudo.
  • %sudo ALL=(ALL:ALL) ALL: lo mismo para el grupo sudo, que en Ubuntu y derivados suele ser el grupo clave.
  • #includedir /etc/sudoers.d: indica que también se lean los archivos de ese directorio (aunque aparezca un #, no es un comentario en este contexto concreto).

Además de reglas de usuarios y grupos, sudoers permite definir alias para simplificar configuraciones complejas: alias de usuarios (User_Alias), de comandos (Cmnd_Alias), de grupos de ejecución (Runas_Alias) o de hosts (Host_Alias).

Gestionar usuarios y grupos con sudoers

Una práctica habitual en servidores es controlar el acceso a sudo mediante grupos. Por ejemplo, en muchos sistemas basta con añadir un usuario al grupo sudo o wheel para que obtenga permisos administrativos completos.

Para comprobar qué usuarios pertenecen a un grupo determinado (por ejemplo, sudo), puedes usar:

> grep ‘sudo’ /etc/group

Si quieres dar permisos de sudo a un usuario, lo habitual es añadirlo al grupo correspondiente. Por ejemplo, para incorporar a bill al grupo sudo:

> sudo adduser bill sudo

En el momento en que necesites retirarle esos privilegios, basta con sacarlo del grupo:

> sudo deluser bill sudo

Otra posibilidad mucho más fina es otorgar permisos solo para ciertos comandos, sin dar carta blanca. Para ello, se suelen crear archivos específicos en /etc/sudoers.d/. Por ejemplo, podrías definir un fichero /etc/sudoers.d/networking con algo como:

Cmnd_Alias CAPTURE = /usr/sbin/tcpdump
Cmnd_Alias SERVERS = /usr/sbin/apache2ctl, /usr/bin/htpasswd
Cmnd_Alias NETALL = CAPTURE, SERVERS
%netadmin ALL = NETALL

Con esta configuración, cualquier usuario del grupo netadmin podrá ejecutar los comandos definidos bajo el alias NETALL (que agrupa los alias CAPTURE y SERVERS) sin tener acceso completo a todo sudo. Solo hace falta añadir a bill al grupo netadmin para que pueda usar tcpdump y las herramientas de servidor definidas.

Comandos habituales que requieren sudo

En el día a día de administración de sistemas, hay varios tipos de tareas que suelen ir casi siempre de la mano de sudo, porque implican modificar el sistema o acceder a información privilegiada.

Gestión de paquetes: en distribuciones basadas en zypper, apt u otros gestores de paquetes, cualquier operación que instale, elimine o actualice software necesita privilegios. Por ejemplo:

> sudo zypper install paquete
> sudo apt-get install docker-ce

Sin embargo, las consultas que solo leen información, como listar repositorios, suelen poder ejecutarse sin sudo. Es cuestión de probar y ver cuándo el propio sistema devuelve un error de permisos.

Gestión de servicios con systemd suele hacerse a través de systemctl. Acciones como iniciar, detener o reiniciar servicios normalmente requieren sudo:

> sudo systemctl restart apache2

En cambio, comandos más inocuos como consultar el estado de un servicio pueden funcionar sin privilegios en muchos sistemas:

> systemctl status NetworkManager

Administrar cuentas de usuario también requiere cuidado. Comandos como usermod, useradd o deluser deben ir casi siempre con sudo, ya que modifican la base de datos de usuarios del sistema:

> sudo usermod -L -f 30 tux

Por último, la gestión de permisos y propiedad de archivos con chown y compañía suele necesitar privilegios cuando afecta a rutas del sistema o a otros usuarios. Por ejemplo, para hacer que todos los archivos y subdirectorios de /home/test/tux-files pasen a pertenecer al usuario tux podrías usar:

> sudo chown -R tux:tux /home/test/tux-files

Ejemplos prácticos de uso de sudo

Veamos algunos casos reales donde sudo marca la diferencia entre un error de permisos y una operación administrativa correcta.

Actualizar índices de paquetes en Debian/Ubuntu sin privilegios dará errores por no poder manipular archivos en /var/lib/apt/lists. El comando:

> apt-get update

Acabará en mensajes de “Permiso denegado”. En cuanto lo repites así, la cosa cambia:

> sudo apt-get update

El sistema pedirá tu contraseña, y si tu usuario está autorizado en sudoers, se ejecutará la actualización sin problemas. Es un patrón que se repite constantemente: error de permisos sin sudo, ejecución correcta con sudo.

Otro ejemplo muy común es la copia de archivos a rutas de sistema, como /usr/local/bin. Si intentas copiar un script allí con un simple:

> cp script.sh /usr/local/bin/

Lo normal es que el terminal se queje de que no tienes permisos para escribir en ese directorio. Si repites la operación anteponiendo sudo:

> sudo cp script.sh /usr/local/bin/

Se te pedirá la contraseña y, tras autenticarte correctamente, la copia se realizará y quedará registrada como ejecutada con privilegios elevados.

También puedes combinar sudo con la opción -u para ejecutar comandos puntuales como otro usuario, sin cambiar de sesión ni usar su. Por ejemplo:

> whoami
> sudo -u pedro whoami

La primera orden mostrará tu usuario real, mientras que la segunda devolverá “pedro”, demostrando que la ejecución se ha realizado como ese usuario de destino.

Dar permisos sin contraseña y otras opciones avanzadas

Una de las cosas más potentes de sudoers es que permite ajustar hasta qué punto se pide contraseña y para qué comandos concretos. En ocasiones, puede interesarte que ciertos usuarios puedan ejecutar determinadas órdenes sin tener que introducir su contraseña cada vez, por ejemplo para scripts automatizados o botones de apagado en un entorno de escritorio.

Esto se consigue con la etiqueta NOPASSWD en las reglas de sudoers. Por ejemplo, si quieres que miusuario pueda ejecutar /bin/cat con sudo sin que se le pida contraseña, podrías añadir una línea:

miusuario ALL = NOPASSWD: /bin/cat

De forma parecida, podrías permitirle gestionar el apagado del equipo sin autenticación repetida, añadiendo algo como:

miusuario ALL = NOPASSWD: /sbin/shutdown, /sbin/halt, /sbin/reboot, /sbin/restart

Para configuraciones más limpias y escalables, conviene usar alias. Un ejemplo típico es definir un grupo de usuarios, otro de comandos y, si hace falta, un alias de usuario de ejecución:

User_Alias GRUPO = pepe, perico, andres
Cmnd_Alias POWER = /sbin/shutdown, /sbin/halt, /sbin/reboot, /sbin/restart
Runas_Alias WEB = www-data, apache

Con estas definiciones podrías luego escribir reglas mucho más legibles, como:

GRUPO ALL = POWER

De este modo, cualquier usuario incluido en el alias GRUPO podrá apagar o reiniciar el equipo con sudo, y puedes ajustar si quieres pedir contraseña o no usando NOPASSWD o PASSWD. También puedes restringir el uso a determinados hosts con Host_Alias para que solo sea válido desde una red específica.

Más allá de NOPASSWD, existen otras etiquetas como NOEXEC (para impedir que un comando lance otros programas con permisos elevados) o pequeñas curiosidades como añadir insults a la línea Defaults, de forma que sudo te suelte una gracieta en inglés cada vez que falles al introducir la contraseña.

Todo esto demuestra que sudoers es mucho más que un simple “interruptor de root”: bien configurado, te permite diseñar un modelo de permisos muy granular, adaptado a tus necesidades y con un nivel de seguridad muy superior al típico “entra como root y haz lo que quieras”.

Contar con una herramienta como sudo, bien entendida y bien configurada, es casi obligatorio en cualquier sistema Linux moderno en el que trabajen varios usuarios o donde quieras minimizar riesgos incluso siendo el único usuario. Aprovechando la combinación de sudo, /etc/sudoers, grupos como sudo o wheel y etiquetas avanzadas como NOPASSWD, puedes conseguir un equilibrio muy razonable entre comodidad, control fino y seguridad, sin tener que vivir pegado a una sesión de root ni fiarlo todo a la buena suerte.

usuario root en linux
Artículo relacionado:
Usuario root en Linux: permisos, riesgos y buenas prácticas