Cómo usar sudo en Linux: guía completa para elevar privilegios

Guía Hardware » Guías de compra » Cómo usar sudo en Linux: guía completa para elevar privilegios

Si usas Linux a diario, tarde o temprano vas a toparte con sudo y los privilegios de superusuario. Ya sea para instalar programas, tocar la configuración del sistema o gestionar usuarios, este comando se convierte en tu puerta de entrada al lado «sensible» del sistema. Entender cómo funciona no es solo cosa de frikis de la consola: es básico para no cargarte nada sin querer y mantener tu máquina segura.

En lugar de iniciar sesión como root todo el rato (algo bastante peligroso), Linux ofrece herramientas como sudo y su para elevar privilegios de forma controlada. A lo largo de este artículo vas a ver qué es exactamente sudo, en qué se diferencia de su, cómo usarlo bien, qué puede salir mal y cómo se configura a fondo mediante el archivo /etc/sudoers y /etc/sudoers.d. Todo explicado en castellano «de la calle», pero con el nivel de detalle que esperarías de documentación técnica seria.

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

El comando sudo es un programa que permite que un usuario normal ejecute órdenes con los privilegios de otro usuario, normalmente el superusuario root, durante un tiempo limitado y de forma controlada. Su nombre viene de «superuser do» o también se suele explicar como «substitute user and do».

En la práctica, sudo funciona como una capa de seguridad: no te obliga a iniciar sesión como root, sino que te deja seguir con tu usuario de siempre, pero dándote permiso puntual para ejecutar comandos que requieren más privilegios. De esta forma se reduce el riesgo de ejecutar algo peligroso sin querer o de que un programa malicioso tenga vía libre para destrozar el sistema.

En la mayoría de distribuciones modernas como Debian, Ubuntu o muchas basadas en ellas, sudo viene preinstalado y forma parte del flujo normal de administración: instalar paquetes, reiniciar servicios, editar ciertos ficheros de configuración del sistema, etc. En sistemas como SLE Micro o similares, esta separación entre usuario normal y root es aún más estricta por motivos de seguridad.

Un detalle clave es que sudo no convierte mágicamente a cualquiera en root. Solo los usuarios autorizados, definidos en el archivo de configuración /etc/sudoers (y en los ficheros dentro de /etc/sudoers.d), pueden utilizarlo, y además se puede decidir con mucha precisión qué comandos puede lanzar cada uno.

Cómo funciona sudo por dentro

Cuando escribes sudo delante de un comando, lo que haces es decirle al sistema que quieres ejecutar esa orden con privilegios elevados. Lo típico es usarlo para hacer tareas de administrador sin haber iniciado sesión como root.

La sintaxis básica es extremadamente sencilla: basta con anteponer sudo al comando que quieras lanzar. Por ejemplo, para actualizar la lista de paquetes en un sistema basado en apt harías algo como:

sudo apt-get update

Si intentas ejecutar ese mismo comando sin sudo, normalmente el sistema te responderá con un error tipo «Permiso denegado» o problemas al abrir ficheros de bloqueo, porque un usuario normal no puede escribir en rutas críticas como /var/lib/apt/ o modificar paquetes.

Al usar sudo, el sistema te pedirá una contraseña de autenticación. Dependiendo de la distribución y configuración, puede ser la del propio usuario que ejecuta sudo o la del usuario root. En la mayoría de casos, en Debian/Ubuntu y similares se usa la contraseña de tu usuario, mientras que en otros entornos se pide la contraseña de root.

Un detalle que suele desconcertar al principio: cuando escribes la contraseña, no se muestra nada en pantalla, ni siquiera asteriscos. Es totalmente normal; simplemente teclea y pulsa Intro. Tras verificarla, sudo ejecutará el comando con los privilegios solicitados.

Por defecto, sudo guarda esa autenticación durante unos minutos, normalmente 15 minutos de margen, de manera que si vuelves a usar sudo dentro de ese periodo no tendrás que introducir la contraseña de nuevo. Este tiempo se puede ajustar mediante opciones en sudoers (por ejemplo con timestamp_timeout).

Diferencias entre sudo y su

Para entender bien sudo conviene compararlo con su (substitute/switch user), que es el comando clásico en Unix para cambiar de cuenta dentro de la misma terminal.

Cuando ejecutas su usuario, lo que estás haciendo es abrir una nueva shell como ese usuario. La sesión anterior sigue existiendo por debajo; cuando escribes exit vuelves al usuario anterior. Por ejemplo:


manz@SYSTEM $ su pedro
Contraseña: ** *
pedro@SYSTEM $ exit
manz@SYSTEM $


Si ejecutas su sin indicar usuario, el sistema asume que quieres cambiar a root. Eso significa que tendrás que conocer la contraseña de root, algo que, por seguridad, muchas veces se intenta evitar compartir.

El problema práctico de su es que, si necesitas hacer tareas administrativas a menudo, acabas trabajando todo el rato como root, lo que aumenta muchísimo las posibilidades de cargarte algo importante con un error tonto. Además, compartir o usar directamente la contraseña de root es una mala práctica evidente.

Ahí es donde entra sudo como alternativa más fina. En lugar de abrir una sesión nueva como otro usuario, sudo permite ejecutar un único comando con privilegios elevados y volver inmediatamente a tu usuario normal. De esta forma, puedes trabajar el 99 % del tiempo sin privilegios y solo elevar cuando realmente lo necesitas.

Curiosamente, sudo y su se pueden combinar. Por ejemplo, si haces sudo su o sudo -i, sudo utilizará sus privilegios para invocar una shell de otro usuario (normalmente root) sin que tú tengas que conocer su contraseña. Eso sí, este uso cancela buena parte de las ventajas de auditoría y control fino que tiene sudo, por lo que muchas guías actuales desaconsejan abusar de sudo su o sudo -i.

Sintaxis básica y opciones más usadas de sudo

La forma general del comando es:

sudo [opciones] comando [argumentos]

Algunas de las opciones más habituales de sudo son:

• -h: muestra una ayuda con la sintaxis y las opciones disponibles. Muy útil si quieres ver qué puedes hacer con sudo sin meterte de lleno en el manual.
• -V: enseña la versión de sudo y detalles de compilación.
• -k: fuerza el olvido inmediato de las credenciales guardadas; es decir, revoca los privilegios actuales y hará que en el siguiente sudo tengas que introducir de nuevo la contraseña.
• -v: renueva el temporizador de autenticación sin ejecutar ningún comando concreto, alargando ese periodo de gracia en el que no te pide contraseña.
• -l: muestra la lista de privilegios que tiene tu usuario según sudoers: qué comandos puedes ejecutar, en qué máquinas, como qué usuarios, etc.
• -u usuario: permite ejecutar un comando como otro usuario diferente al que está definido por defecto (normalmente root). Por ejemplo, sudo -u pedro whoami ejecutará whoami como si fueras pedro.

Un ejemplo típico para entrar como superusuario usando sudo sería:

sudo su

En este caso, sudo te pedirá tu contraseña (si tienes permiso en sudoers) y luego lanzará su con privilegios de root, abriéndote una shell con el prompt terminado en #, que indica que estás actuando como superusuario. El símbolo $ corresponde a un usuario normal, mientras que # indica root o privilegios de administrador.

Ejemplos prácticos: instalar paquetes, gestionar servicios y más

La utilidad real de sudo se ve al usarlo en tareas de administración del día a día. Casi todo lo que implique tocar el sistema en serio requerirá privilegios adicionales.

Gestión de paquetes con sudo

En distribuciones basadas en Debian y Ubuntu, es muy común usar sudo con apt o apt-get. Por ejemplo, al actualizar la lista de paquetes:


manz@SYSTEM $ apt-get update
Leyendo lista de paquetes... Hecho
E: No se pudo abrir el fichero de bloqueo «/var/lib/apt/lists/lock» - open (13: Permiso denegado)
E: No se pudo bloquear el directorio /var/lib/apt/lists/


Si repites el comando anteponiendo sudo, el escenario cambia:


manz@SYSTEM $ sudo apt-get update
[sudo] password for manz: *
Obj:1 http://deb.debian.org/debian buster InRelease
Des:2 http://security.debian.org/debian-security buster/updates InRelease [65,4 kB] ...


Con sudo, apt-get puede escribir en directorios del sistema, abrir ficheros de bloqueo y realizar la operación administrativa sin errores de permisos.

En sistemas SUSE/SLE, la herramienta de paquetes habitual es zypper. También se usa con sudo para operaciones que modifiquen el sistema, como instalar software:

sudo zypper install docker

Sin embargo, hay comandos de zypper o apt que solo leen información y no necesitan privilegios, como listar repositorios. En esos casos no hace falta usar sudo.

Control de servicios con systemctl y sudo

En sistemas con systemd, la orden systemctl se utiliza para iniciar, detener y reiniciar servicios. Muchas de esas acciones requieren privilegios elevados, por lo que es habitual escribir cosas como:

sudo systemctl restart apache2

Aquí estás reiniciando el servicio del servidor web Apache con permisos de administrador. En cambio, comandos de solo lectura como:

systemctl status NetworkManager

pueden ejecutarse sin sudo, porque solo consultan el estado y no modifican nada crítico.

Gestión de usuarios, permisos y propiedad de archivos

El comando usermod se emplea para modificar cuentas de usuario (por ejemplo, su fecha de caducidad). Estas acciones suelen requerir sudo:

sudo usermod -f 30 tux

Con esa orden se indica que, cuando a tux se le caduque la contraseña, su cuenta se deshabilite de forma permanente pasados 30 días.

Para cambiar la propiedad de archivos y directorios se usa chown, normalmente también con sudo:

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

Después puedes comprobar el cambio con:

ls -l /home/test/tux-files

Estas operaciones solo son posibles si el usuario que lanza sudo está autorizado a hacerlo según la configuración de sudoers.

Ejecutar comandos como otro usuario: sudo -s y sudo -i

Además de ejecutar un comando puntual, sudo permite abrir shells con otro usuario de varias maneras, con diferentes implicaciones sobre el entorno.

Con sudo -s se abre una shell que hereda el entorno del usuario actual, pero con los privilegios de otro usuario (por defecto root). Por ejemplo:

sudo -s

Esto te dejará en una shell privilegiada, pero manteniendo variables de entorno del usuario original, incluyendo el directorio de trabajo. Es útil cuando quieres elevar privilegios sin cambiar demasiado tu contexto. Además, los comandos ejecutados se registran en el historial.

Si quieres un entorno limpio, similar a iniciar sesión directamente como ese usuario, se usa sudo -i. Este abre una shell de login interactiva, ejecutando scripts como .profile o .bash_profile, empezando en el directorio $HOME del usuario de destino. Por ejemplo:

sudo -i -u tux

Con esta orden entrarás como tux, con su entorno y su directorio personal. Igual que con sudo -s, las acciones se registran y siguen controladas por las reglas de sudoers.

La diferencia clave es que sudo -s hereda el entorno del usuario anterior, mientras que sudo -i recrea el entorno propio del usuario objetivo. Según el caso, te interesará uno u otro para evitar arrastrar variables inapropiadas o para mantener tu configuración actual.

El archivo sudoers y /etc/sudoers.d: el corazón de la configuración

Todo el comportamiento de sudo se define a través de un archivo principal llamado /etc/sudoers, al que se pueden añadir fragmentos adicionales en el directorio /etc/sudoers.d. Este conjunto de ficheros controla quién puede usar sudo, cómo, en qué máquinas y con qué parámetros.

Al abrir /etc/sudoers con un editor (usando siempre visudo, como veremos enseguida), encontrarás líneas como:


root ALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL


La primera línea indica que root puede ejecutar cualquier comando en cualquier host como cualquier usuario o grupo. La segunda significa que cualquier usuario que pertenezca al grupo sudo tiene también permiso total para usar sudo.

Otra línea típica es:

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Con esta configuración se define una ruta segura para el PATH de root cuando se usa sudo, evitando problemas donde comandos críticos no se encuentran porque el PATH es demasiado limitado. Versiones antiguas de sudoers podían carecer de esta línea, provocando avisos como «ldconfig not found in PATH» o similares al instalar paquetes.

Además, verás directivas como:

@includedir /etc/sudoers.d

Esto indica que se leerán configuraciones adicionales desde /etc/sudoers.d, lo que permite guardar allí reglas locales sin modificar directamente el archivo principal. Es una práctica recomendada, porque protege tus ajustes ante actualizaciones del paquete sudo que puedan sobrescribir /etc/sudoers.

Cómo editar sudoers de forma segura con visudo

El archivo /etc/sudoers está marcado explícitamente como solo lectura, incluso para root, para forzar a los administradores a usar la herramienta adecuada: visudo. Esta orden abre sudoers en el editor configurado (vi, nano, etc.), pero además:

• Comprueba que solo haya una persona editando el archivo a la vez para evitar conflictos.
• Realiza una comprobación de sintaxis antes de guardar. Si hay un error, te avisa y no deja grabar un archivo roto que te deje sin sudo.

Para editar el fichero principal usarías:

sudo visudo -f /etc/sudoers

Y para crear o modificar un archivo específico en /etc/sudoers.d, algo como:

sudo visudo -f /etc/sudoers.d/mi-config

Ignorar visudo y editar sudoers con otro editor directamente puede dejarte sin acceso a sudo si cometes un fallo de sintaxis, así que no es buena idea.

Ejemplos de reglas avanzadas en sudoers

El archivo sudoers permite definir alias de usuarios, máquinas y comandos, así como reglas muy finas. Por ejemplo:


User_Alias MYADMINS = jdoe
Cmnd_Alias SHUTDOWN = /sbin/reboot, /sbin/poweroff
Cmnd_Alias PKGMGMT = /usr/bin/dpkg, /usr/bin/apt-get, /usr/bin/aptitude
MYADMINS ALL = PKGMGMT, SHUTDOWN


Con esto, el usuario jdoe (incluido en el alias MYADMINS) puede reiniciar la máquina y gestionar paquetes, pero no tiene vía libre para ejecutar cualquier comando como root.

También se pueden ajustar detalles como:

• Defaults rootpw: obliga a que sudo pida la contraseña de root en lugar de la del usuario actual.
• %sudo ALL=(ALL) NOPASSWD: ALL: permite que los miembros del grupo sudo ejecuten cualquier comando vía sudo sin que se les pida la contraseña. Es cómodo, pero bastante peligroso si se compromete la cuenta.
• Defaults:usuario timestamp_timeout=30: cambia el tiempo de validez de las credenciales para un usuario concreto a 30 minutos.

Gracias a estas reglas, puedes dar a un usuario o grupo el acceso mínimo necesario (principio de mínimo privilegio), revocarlo sin cambiar contraseñas y registrar quién hizo qué.

Gestionar quién puede usar sudo: grupos y usuarios

En muchas distribuciones (como Debian y Ubuntu) la configuración por defecto establece que cualquier usuario del grupo sudo puede ejecutar órdenes con sudo. Para comprobar si perteneces a ese grupo puedes usar:

groups o id

Si en la salida aparece «sudo», estás dentro. Por ejemplo:

pepe sudo

Si no sale, puedes añadir un usuario al grupo con:

sudo adduser pepe sudo

Después de agregarlo, es importante que el usuario salga de la sesión y vuelva a entrar para que el sistema recoja la nueva membresía. Muchos problemas con el mensaje «Sorry, user no está permitido para ejecutar…» vienen precisamente de que se ha modificado el grupo pero no se ha iniciado sesión de nuevo.

Para crear un usuario nuevo con acceso directo a sudo, un usuario privilegiado puede hacer algo como:

sudo adduser otrousuario sudo

En Debian, si durante la instalación dejas la contraseña de root vacía, el sistema suele configurar automáticamente sudo y añadir el primer usuario creado al grupo sudo, de modo que pueda administrarlo todo sin necesidad de usar directamente la cuenta root.

Configurar sudo «seguro» y «cómodo»

En algunos entornos es útil distinguir dos estilos de configuración para un usuario: uno donde sudo pide contraseña siempre (más seguro) y otro donde nunca pide contraseña (más cómodo, pero con riesgos).

Para el modo «seguro», se puede crear un archivo en /etc/sudoers.d con una línea del tipo:

usuario ALL=(ALL:ALL) ALL

Esto permite al usuario ejecutar cualquier comando con sudo, pero siempre solicitando su contraseña. Automatizarlo con un pequeño script que escriba esa línea en un fichero temporal y lo copie a /etc/sudoers.d mediante su -c es una técnica común, aunque requiere introducir la contraseña de root para realizar la copia.

Para el modo «cómodo», la entrada sería algo como:

usuario ALL = (ALL) NOPASSWD: ALL

Así, el usuario puede usar sudo sin que se le pregunte nunca la contraseña. Es muy práctico en entornos controlados o en máquinas de laboratorio, pero supone un riesgo serio si esa cuenta es comprometida, porque da acceso inmediato a todo el sistema.

En ambos casos, los scripts que generan estas reglas suelen escribir primero en /tmp y luego copiar a /etc/sudoers.d, exigiendo la clave de root para que el cambio sea legítimo y controlado.

Mensajes de error y problemas habituales con sudo

Trabajando con sudo es fácil toparse con algunos errores típicos que conviene saber interpretar para no volverse loco.

Uno de ellos es el ya mencionado aviso de PATH al instalar paquetes como root vía sudo, indicando que ciertos binarios del sistema no se encuentran. Normalmente la causa es que falta la línea secure_path en sudoers o que se ha mantenido una versión antigua del fichero sin fusionar los cambios del paquete. La solución pasa por actualizar /etc/sudoers correctamente o mover las personalizaciones a /etc/sudoers.d.

Otro clásico es el mensaje:

Sorry, user jdoe is not allowed to execute '/usr/bin/test' as root on localhost.

Este texto es literal: significa que tu usuario no tiene permisos definidos en sudoers para esa orden concreta en esa máquina. Muchas veces esto ocurre justo después de añadir el usuario a un grupo privilegiado, pero seguir usando una sesión antigua sin reingresar al sistema. Cerrar sesión, volver a entrar o usar newgrp sudo (para recargar los grupos) suele resolverlo.

También es frecuente ver que /etc/sudoers está protegido contra escritura incluso para root. No es un fallo, es una medida intencionada para recordarte que debes editarlo por medio de visudo y así evitar dejarlo corrupto por un error de sintaxis o un salvado a medias.

A la hora de decidir entre usar sudo o su, hay administradores que siguen prefiriendo su e iniciar sesión como root directamente cuando lo necesitan, sobre todo en entornos tradicionales de Unix. Otros, en cambio, usan sudo para todo, precisamente por su sistema de auditoría, control fino de privilegios y porque evita tener que compartir la contraseña de root. La elección depende del contexto, pero en muchas distribuciones modernas, especialmente orientadas a escritorio, sudo se considera ya la opción estándar.

Dominar el comando sudo, entender sus opciones y conocer el archivo sudoers te permite administrar tu sistema Linux con mucha más seguridad y precisión, evitando abusar de la cuenta root, delegando tareas concretas en otros usuarios sin regalarles todo el poder y manteniendo un registro claro de qué se ha hecho con privilegios elevados.

Puntos clave

• sudo permite ejecutar comandos con privilegios elevados sin necesidad de iniciar sesión como root, controlando qué usuarios pueden hacerlo y qué órdenes pueden lanzar.
• El archivo /etc/sudoers y los ficheros en /etc/sudoers.d definen la política de sudo: permisos, alias, tiempos de validez, contraseñas requeridas y rutas seguras.
• Usar visudo es imprescindible para editar sudoers de forma segura, evitando errores de sintaxis que puedan dejar el sistema sin acceso a sudo.
• La pertenencia al grupo sudo u otros grupos definidos determina en muchas distribuciones quién puede usar sudo, cuánto poder tiene y si debe introducir contraseña o no.