Valencia, 16/08/2026, G.B.
Si administras un sistema Linux, tarde o temprano necesitas ejecutar algo con privilegios de administrador. Para eso existen dos comandos clásicos: su y sudo. Se confunden a menudo porque hacen «cosas parecidas», pero funcionan de forma bastante distinta y esa diferencia importa, sobre todo en seguridad.
Qué hace su
su (substitute user) cambia de usuario dentro de la misma sesión de terminal, sin cerrar la sesión actual. Si lo ejecutas sin argumentos, intenta convertirte en root:
suTe pedirá la contraseña de root. El problema en distribuciones como Ubuntu es que, por defecto, la cuenta root no tiene contraseña establecida (está bloqueada), así que su a secas no funciona salvo que la actives manualmente con sudo passwd root.
Un matiz importante que mucha gente pasa por alto: su sin el guión no carga el entorno completo del usuario destino (variables de entorno, PATH, etc.), lo que puede provocar errores de «orden no encontrada». La forma correcta es:
su -Esto sí simula un login completo como root, con su propio entorno.
También puedes cambiar a otro usuario que no sea root:
su - nombreusuarioY ejecutar un único comando como ese usuario sin abrir una sesión interactiva completa:
su nombreusuario -c 'whoami'Qué hace sudo
sudo (superuser do) no cambia de usuario: ejecuta un comando puntual con privilegios elevados, pidiendo tu propia contraseña, no la de root.
sudo apt update
sudo systemctl restart nginxEsto es justo lo que hace que Ubuntu y macOS desactiven la contraseña de root por defecto: en vez de compartir una contraseña maestra entre varios administradores, cada uno usa la suya y sudo decide, según el fichero /etc/sudoers, qué puede hacer cada cual.
Si necesitas una sesión completa como root en lugar de un comando suelto, existe el equivalente moderno:
sudo -iEs prácticamente lo mismo que su -, pero pasando por el mecanismo de autenticación de sudo.
Diferencias clave (resumen práctico)
| su | sudo | |
|---|---|---|
| Contraseña que pide | La del usuario destino (root) | La tuya propia |
| Uso típico | Abrir una sesión completa | Ejecutar un comando puntual |
| Registro de auditoría | Limitado | Registra en /var/log/auth.log quién ejecutó qué y cuándo |
| Granularidad de permisos | Todo o nada | Se puede limitar por comando, usuario o grupo |
| Estado en Ubuntu | Root bloqueado por defecto | Habilitado y recomendado |
Este último punto es la razón real por la que sudo se ha impuesto: permite dar acceso administrativo limitado (por ejemplo, solo a systemctl restart nginx, no a todo el sistema), mientras que su es binario: o tienes la contraseña de root, o no tienes nada.
Configurar quién puede usar sudo
Los permisos se definen en /etc/sudoers, pero nunca se edita directamente con un editor de texto normal: un error de sintaxis ahí puede dejarte sin forma de recuperar privilegios de administrador. Se usa siempre:
sudo visudovisudo bloquea el archivo, valida la sintaxis antes de guardar y evita dejar el sistema en un estado roto.
Hoy en día se recomienda no tocar /etc/sudoers en sí, sino añadir ficheros propios en /etc/sudoers.d/, por ejemplo:
sudo visudo -f /etc/sudoers.d/miusuarioCon una línea como esta le das a un usuario acceso completo:
miusuario ALL=(ALL:ALL) ALLO, de forma mucho más segura, acceso solo a un comando concreto sin pedir contraseña (útil para scripts automatizados o tareas programadas):
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginxAñadir a un usuario al grupo sudo (en Ubuntu/Debian) tiene el mismo efecto que la primera línea, y suele ser más práctico que editar ficheros a mano:
sudo usermod -aG sudo nombreusuarioComandos de sudo que conviene conocer
sudo -l— lista qué comandos puede ejecutar tu usuario con sudo.sudo -k— invalida la caché de autenticación, así el próximosudote vuelve a pedir contraseña.sudo -v— refresca el «ticket» de sudo sin ejecutar ningún comando.sudo !!— repite el último comando pero con sudo delante (muy útil cuando olvidas anteponerlo).
Sobre este último: por defecto, tras autenticarte con sudo, el sistema no vuelve a pedir contraseña durante 15 minutos. Es cómodo, pero también un riesgo si dejas la terminal desatendida. Se puede ajustar (o eliminar) ese margen con Defaults timestamp_timeout=0 en /etc/sudoers.d/.
sudo su: el atajo que todo el mundo usa
Es habitual ver esta combinación:
sudo suAquí pides tu propia contraseña (vía sudo) para lanzar una sesión de root (vía su), sin necesidad de activar nunca la contraseña de root. Es el método recomendado si de verdad necesitas una shell interactiva como root en un sistema Ubuntu moderno, en lugar de activar la cuenta root manualmente.
Alternativa más moderna: doas
En distribuciones más minimalistas (OpenBSD, y disponible también en Debian/Ubuntu vía paquete) existe doas, pensado como una alternativa ligera a sudo, con una configuración mucho más simple en /etc/doas.conf. No ha desplazado a sudo en el mundo Ubuntu/Debian, pero es una opción a tener en cuenta en entornos donde se prioriza minimizar la superficie de ataque.
Buenas prácticas
- Evita trabajar como root de forma continua; usa sudo comando a comando.
- Nunca edites /etc/sudoers sin visudo.
- Da permisos específicos por comando (NOPASSWD con ruta exacta) en vez de acceso total cuando sea posible, especialmente para cuentas de automatización.
- Revisa /var/log/auth.log periódicamente si gestionas un servidor con varios administradores; ahí queda constancia de cada uso de sudo.
- Ten en cuenta que
sudo -sabre un shell que no registra los comandos que escribas dentro de él, a diferencia de invocaciones individuales desudo comando. Si te importa la auditoría, evita ese patrón.
En resumen
su cambia de identidad; sudo presta privilegios para una acción concreta sin dejar de ser tú mismo. En cualquier sistema Ubuntu o Debian actual, la recomendación sigue siendo la misma que hace más de una década: usa sudo para el día a día, reserva sudo -i o sudo su para cuando de verdad necesites una shell completa como root, y controla los permisos finos vía visudo y /etc/sudoers.d/.
