Qué es el comando sudo en Linux y cómo usarlo sin romper el sistema

¿Qué es el comando sudo en Linux y cómo se usa correctamente?

La respuesta corta: qué es sudo y cómo conviene usarlo según tu perfil

Si vienes de Windows o macOS y acabas de instalar tu primera distribución Linux, esta es la elección directa.

Principiante en escritorio (Ubuntu, Linux Mint, Zorin OS, Fedora Workstation, Debian): usa sudo delante de cada comando que lo requiera, por ejemplo sudo apt update. Es el modo más seguro porque pide tu contraseña, registra lo que haces y limita el tiempo con privilegios. No entres como root y no actives NOPASSWD.

Administrador de servidor: sigue con sudo comando a comando para tareas puntuales, y reserva sudo -i solo para una secuencia corta de administración donde repetir sudo sea propenso a error. Cada sesión como root aumenta el riesgo de borrar o sobrescribir archivos del sistema sin confirmación. Configura en /etc/sudoers con visudo qué usuarios y qué comandos pueden ejecutar, con el principio de mínimo privilegio.

Entorno compartido o equipo con varios usuarios: no compartas la contraseña de root. Crea un usuario por persona, añádelo al grupo sudo o wheel según la distribución y define reglas específicas en /etc/sudoers.d/. Así cada acción queda asociada a un usuario en los registros y puedes revocar permisos sin cambiar la clave de todos. Datos comprobados en septiembre de 2026.

Qué significa realmente sudo y en qué se diferencia de ser root

sudo significa "superuser do" o "substitute user do". Permite ejecutar un comando concreto con privilegios de otro usuario, por defecto root, tras autenticarte con tu propia contraseña. No inicias sesión como root, solo elevas ese comando.

root es la cuenta con UID 0. Puede leer, escribir y ejecutar cualquier archivo y modificar cualquier configuración. Trabajar todo el tiempo como root elimina las barreras de seguridad: un error tipográfico como rm -rf / se ejecuta sin freno.

su (substitute user) cambia de usuario. su - o su -l piden la contraseña del usuario destino, normalmente la de root, y abren una sesión completa como ese usuario hasta que escribes exit. No registra qué comando ejecutaste ni limita por tiempo a un solo comando.

sudoers es la política que define quién puede usar sudo, en qué máquinas y qué comandos puede ejecutar. Se guarda en /etc/sudoers y en archivos dentro de /etc/sudoers.d/. Solo debe editarse con visudo, que comprueba la sintaxis antes de guardar. Si la sintaxis es incorrecta, puedes quedarte sin acceso a sudo.

Usar sudo en lugar de su aporta trazabilidad: cada uso queda en el registro del sistema y pide la contraseña del usuario que ejecuta, no la de root, lo que permite auditoría y revocación por usuario.

Qué necesitas antes de tocar nada: permisos, usuario y archivo sudoers

Antes de ejecutar cualquier comando con privilegios, verifica estos puntos. Si alguno falla, sudo no funcionará aunque escribas bien el comando.

Usuario perteneciente al grupo correcto. En Ubuntu, Linux Mint, Debian y Zorin OS el grupo es sudo. En Fedora Workstation y otras derivadas de Red Hat es wheel. Compruébalo con groups o id. Si no apareces en ese grupo, verás user is not in the sudoers file. Solo un administrador existente puede añadirte con sudo usermod -aG sudo tu_usuario o sudo usermod -aG wheel tu_usuario. El cambio aplica tras cerrar sesión y volver a entrar.

Archivo de políticas en su sitio y sin edición directa. La configuración principal está en /etc/sudoers con permisos 0440 y propietario root:root. No lo abras con un editor normal. Usa siempre sudo visudo, que bloquea el archivo contra ediciones simultáneas y valida la sintaxis al guardar. Los fragmentos adicionales van en /etc/sudoers.d/ con permisos 0440. Un archivo en ese directorio con permisos 0644 será ignorado por sudo.

Paquete sudo instalado y versión conocida. Comprueba si está instalado con which sudo y la versión con sudo --version. En 2026 la rama estable es 1.9.x. La versión importa para saber si te afectan vulnerabilidades como CVE-2026-35535 y CVE-2026-82474 y para conocer opciones como sudo -V o sudo -l. Si no está instalado, instálalo desde la cuenta root con el gestor de la distribución: apt install sudo en Debian/Ubuntu/Mint o dnf install sudo en Fedora.

Contraseña de tu usuario establecida. sudo pide tu contraseña, no la de root. Si tu usuario no tiene contraseña, la autenticación fallará. Define una con passwd.

Acceso a registro para depurar. Verifica que puedes leer los intentos de sudo con sudo journalctl -t sudo o sudo grep sudo /var/log/auth.log según la distribución.

Métodos comparados para ejecutar tareas con privilegios

No todos los métodos para obtener privilegios funcionan igual. La diferencia está en qué contraseña piden, cuánto dura la elevación y qué rastro dejan.

Método	Comando base	Pide contraseña de quién	Timeout por defecto	Registro en logs	Riesgo de error si te equivocas de comando	Cuándo usar
sudo comando a comando	`sudo apt update`	tu usuario	15 minutos	sí, en journalctl / auth.log	bajo, solo ese comando se ejecuta como root	uso diario recomendado en escritorio y servidor
sudo -i (shell de root vía sudo)	`sudo -i`	tu usuario	15 minutos, renueva al entrar	sí, inicio de sesión registrado	alto, toda la sesión es root	secuencia corta de administración, salir con `exit` en cuanto termines
su –	`su -`	root	sin timeout, hasta `exit`	no registra comando a comando	alto, toda la sesión es root sin rastro por usuario	recuperación cuando sudo está roto y conoces clave de root
pkexec / doas	`pkexec apt update` / `doas apt update`	tu usuario o root según PolicyKit/doas.conf	sin dato	sí, vía PolicyKit / syslog	medio	entornos con PolicyKit o sistemas minimalistas tipo OpenBSD/Alpine

La tabla muestra por qué sudo comando a comando es la opción por defecto: limita el tiempo con privilegios a 15 minutos desde la última autenticación, deja registro por usuario y reduce el alcance del error a un solo comando. sudo -i y su - mantienen una shell completa como root, por lo que un comando mal escrito afecta a todo el sistema. pkexec depende de PolicyKit y no está disponible en todas las instalaciones, y doas requiere configuración previa en /etc/doas.conf.

Método 1: sudo comando a comando, el uso correcto para el día a día

Este es el flujo que debes usar el 95% de las veces en Ubuntu, Linux Mint, Zorin OS, Fedora Workstation y Debian. Cada paso está aislado y reverts al usuario normal al terminar.

Abre una terminal y ejecuta el comando con sudo delante. Sintaxis: sudo comando [opciones]. Ejemplo: sudo apt update para actualizar índices de paquetes en Debian/Ubuntu/Mint/Zorin OS, o sudo dnf update en Fedora Workstation. El sistema te pedirá tu contraseña la primera vez. No se muestra al escribir.

Comprueba qué puedes ejecutar si tienes dudas. sudo -l lista los comandos permitidos para tu usuario según sudoers. sudo -v renueva el ticket de 15 minutos sin ejecutar nada, y sudo -k lo invalida inmediatamente. Usa sudo -k si te levantas del equipo y no quieres dejar la ventana abierta.

Reejecuta el último comando con privilegios si lo olvidaste. Si escribiste apt update y recibiste Permission denied, ejecuta sudo !!. !! repite el comando anterior, ahora con sudo. Es más seguro que reescribirlo y equivocarte.

Ejecuta como otro usuario si es necesario. sudo -u nombre_usuario comando corre el comando como ese usuario, no como root. Ejemplo: sudo -u www-data ls /var/www. Útil para probar permisos sin cambiar de sesión.

Encadena solo lo necesario. sudo apt update && sudo apt upgrade pide contraseña una vez si estás dentro del timeout de 15 minutos, pero cada sudo se registra por separado. Evita sudo sh -c "comando1; comando2" salvo que sea imprescindible, porque oculta qué se ejecutó.

Sal del privilegio. No hay que salir, porque nunca entraste en una shell de root. Si usaste sudo -i por error, escribe exit para volver. Verifica con whoami que has vuelto a tu usuario.

Limitación honesta: este método no sirve para sesiones largas con decenas de comandos interdependientes, como migrar un servidor, porque repetir sudo y volver a autenticarte interrumpe el flujo y tienta a usar sudo -i sin control. Para esos casos, limita sudo -i a una ventana concreta, con registro y cierre inmediato.

Método 2: configurar y gestionar sudoers con visudo sin romper el sistema

Tocar /etc/sudoers sin visudo es la causa más común de quedarse sin sudo. Un error de sintaxis bloquea todo uso posterior hasta que lo repares desde root. Este método es para añadir o limitar permisos de forma controlada.

Abre siempre con visudo. Ejecuta sudo visudo. Por defecto abre vi; si prefieres nano, define el editor antes: sudo EDITOR=nano visudo. visudo bloquea el archivo y comprueba la sintaxis al guardar. Si detecta error, muestra parse error y ofrece e)dit again, no guarda el archivo roto.

Añade al usuario al grupo antes de tocar reglas finas. Si el usuario aún no tiene sudo, sudo usermod -aG sudo nombre_usuario en Ubuntu/Mint/Debian/Zorin OS o sudo usermod -aG wheel nombre_usuario en Fedora Workstation. Cierra sesión y vuelve a entrar para que el grupo aplique. Comprueba con id nombre_usuario.

Crea una regla específica en lugar de editar el archivo principal. En vez de modificar /etc/sudoers, crea un archivo en /etc/sudoers.d/: sudo visudo -f /etc/sudoers.d/usuario. Añade una línea con formato usuario host = (runas) comandos. Ejemplo limitado y seguro: ana ALL=(ALL) /usr/bin/apt update, /usr/bin/apt upgrade permite solo esos dos comandos. Para aplicar sin contraseña solo a ese comando: ana ALL=(ALL) NOPASSWD: /usr/bin/apt update . Nunca uses ana ALL=(ALL) NOPASSWD: ALL, porque elimina la protección por contraseña para todo.

Ajusta permisos del fragmento. sudo chmod 0440 /etc/sudoers.d/usuario y sudo chown root:root /etc/sudoers.d/usuario. Si el archivo queda con 0644, sudo lo ignorará y mostrará advertencia.

Verifica sin cerrar la terminal. En otra terminal, prueba sudo -l -U ana y sudo -k && sudo -n true para comprobar timeout y sintaxis. Mantén una sesión de root o sudo -i abierta hasta confirmar que el nuevo usuario puede usar sudo. Si cierras todo y la regla está mal, tendrás que ir a modo recuperación.

Editar /etc/sudoers directamente con nano o echo >> evita la validación de visudo. Un solo carácter mal puesto deja sudo inutilizable y obliga a reparar desde root o modo recuperación.

Cómo mantener sudo seguro y actualizado

No uses NOPASSWD: ALL nunca. Limita NOPASSWD a un binario concreto y sin comodines. NOPASSWD: /usr/bin/systemctl restart nginx es auditable; NOPASSWD: ALL permite a cualquier proceso que comprometa tu usuario ejecutar sudo sin freno.

Reduce el tiempo de caché si compartes equipo. Añade Defaults timestamp_timeout=5 en sudoers para que el ticket dure 5 minutos en lugar de 15. En equipo personal, mantén 15. Invalida siempre con sudo -k al ausentarte.

Revisa quién usa sudo y cuándo. Ejecuta sudo journalctl -t sudo --since today o sudo grep sudo /var/log/auth.log cada semana. Busca USER=, COMMAND= y incorrect password attempt. Tres intentos fallidos seguidos pueden indicar prueba de contraseña.

Actualiza el paquete sudo ante CVE. Revisa sudo --version y actualiza con sudo apt update && sudo apt upgrade sudo o sudo dnf update sudo. En 2026 se publicaron CVE-2026-35535 y CVE-2026-82474 que afectan a versiones anteriores a 1.9.15p5 en ciertas configuraciones de sudoers; si tu versión es anterior, actualiza antes de tocar reglas.

Mantén una copia de seguridad de sudoers. sudo cp /etc/sudoers /etc/sudoers.bak.$(date +%F) antes de cada cambio y guarda los fragmentos de /etc/sudoers.d/ en tu gestor de configuración.

Principio de mínimo privilegio. Otorga solo el binario exacto con su ruta absoluta /usr/bin/apt no apt, y solo al usuario que lo necesita. Revoca con sudo gpasswd -d usuario sudo cuando ya no lo requiera.

Qué hacer si sudo falla: errores frecuentes y cómo salir del bloqueo

"user is not in the sudoers file. This incident will be reported." Causa: tu usuario no está en sudo o wheel ni tiene regla en sudoers. Solución: entra como administrador existente y ejecuta sudo usermod -aG sudo tu_usuario y cierra sesión. Si no hay otro administrador y conoces la clave de root, usa su -, introduce la clave de root y ejecuta usermod -aG sudo tu_usuario. Si no conoces la clave de root, reinicia en modo recuperación: en el menú GRUB elige Advanced options > Recovery mode > root shell, monta el sistema en escritura con mount -o remount,rw / y ejecuta usermod -aG sudo tu_usuario.

"Sorry, try again." / "incorrect password attempt" tras 3 intentos. Causa: escribiste mal tu contraseña, no la de root, o el teclado está en otro layout, o el timeout timestamp_timeout expiró. Solución: verifica passwd y layout con setxkbmap -query. Espera unos segundos, sudo bloquea brevemente tras 3 fallos. Revisa el registro con sudo journalctl -t sudo | grep "incorrect password" si tienes otro administrador. No intentes fuerza bruta, aumentarás el bloqueo.

"sudo: parse error in /etc/sudoers near line X" o "syntax error". Causa: editaste /etc/sudoers o un archivo en /etc/sudoers.d/ sin visudo y dejaste una coma, un = o un alias mal escrito. sudo se niega a funcionar por seguridad. Solución inmediata si tienes shell de root abierta: visudo o visudo -f /etc/sudoers.d/archivo y corrige la línea. Si no tienes shell, usa su - para pasar a root y luego visudo. Si su tampoco funciona, entra en modo recuperación como en el punto anterior y ejecuta visudo desde la shell de root. Comprueba permisos: chmod 0440 /etc/sudoers y chmod 0440 /etc/sudoers.d/*.

"sudo: unable to resolve host" Causa: el hostname en /etc/hostname no coincide con /etc/hosts. No bloquea sudo, pero retrasa cada ejecución 10 a 20 segundos. Solución: sudo nano /etc/hosts y añade 127.0.1.1 tu_hostname.

Ejemplo concreto de recuperación: usuario maria en Ubuntu 24.04 edita con sudo nano /etc/sudoers y añade maria ALL=(ALL) NOPASSWD ALL sin visudo, dejando una línea incompleta. Al guardar, sudo deja de funcionar con parse error near line 28. Con el equipo bloqueado, reinicia, entra en Recovery mode, elige root, ejecuta mount -o remount,rw /, luego visudo y elimina la línea rota, guarda con Ctrl+O si usa nano como editor de visudo, hace chmod 0440 /etc/sudoers y reinicia con reboot. Al volver, añade el permiso correcto con sudo visudo -f /etc/sudoers.d/maria.

Fuentes

SudoSudoconsultado el 24/09/2026
SudoSudo Showconsultado el 24/09/2026
FosslinuxSaying Goodbye to Sudo: Mastering Systemd run0 in 2026consultado el 24/09/2026
BeyondtrustWhat is Sudo? Su vs Sudo and Linux Privilege Managementconsultado el 24/09/2026
SpiceworksThe Origin of sudo: How Unix Learned to Share Power Safely – 2026 …consultado el 24/09/2026