Cuando instalas Debian y creas tu usuario, ese usuario no puede hacer nada que afecte al sistema: no puede instalar paquetes, no puede modificar archivos en /etc, no puede reiniciar servicios. Eso es intencional. sudo (substitute user do) es el mecanismo que permite cruzar esa frontera de forma controlada y auditable, sin convertirte en root de manera permanente.
La idea es simple: en lugar de autenticarte como root directamente, el sistema comprueba si tu usuario tiene permiso para elevar privilegios. Ese permiso se gestiona mediante pertenencia a un grupo. En Debian, el grupo se llama sudo. Si tu usuario está en ese grupo, puedes usar sudo; si no está, el comando falla con un aviso y el intento queda registrado en los logs. Es una puerta con lista de invitados, no una puerta abierta.
[Ubuntu] En Ubuntu el grupo también se llama sudo, y además root está deshabilitado por defecto: no tiene contraseña asignada y no puedes autenticarte directamente como root. En Debian la cuenta root sí existe y tiene contraseña; sudo es una capa adicional que puedes o no configurar.
Cuando ejecutas sudo algún-comando, pasan tres cosas en orden: sudo comprueba que tu usuario está en el grupo sudo, te pide tu propia contraseña (no la de root), y ejecuta el comando con UID 0. Fíjate en ese segundo punto: autentificas con tu contraseña, no con la de root. Eso significa que root puede tener una contraseña robusta que nadie conoce, y cada persona que necesita privilegios usa la suya.
Después de que te autentificas, sudo guarda un timestamp durante 15 minutos en Debian (los tutoriales más viejos dicen 5 minutos; el valor real por defecto en Debian Bookworm es timestamp_timeout = 15). Durante ese tiempo, sudo no vuelve a pedir contraseña. Esto evita que tengas que teclearla en cada comando cuando estás en mitad de una sesión de administración. Cuando terminas, lo correcto es invalidar ese timestamp con sudo -k.
Si algo sale mal, el primer lugar donde buscar es el log del sistema. Cada vez que alguien ejecuta un comando con sudo, queda registrado en /var/log/auth.log con el usuario real, el comando completo, el directorio de trabajo y si tuvo éxito. Eso es algo que no obtienes cuando alguien se loguea directamente como root: no sabes quién hizo qué.
# Comprueba si tu usuario está en el grupo sudo. # Si el grupo aparece en la salida, tienes acceso. groups # Instalar un paquete como root — el uso más habitual sudo apt install htop # Editar un archivo de configuración del sistema sudo nano /etc/hosts # Ejecutar un comando como un usuario específico (no root). # Útil cuando un servicio corre como www-data y necesitas reproducir # exactamente sus permisos de lectura/escritura. sudo -u www-data ls /var/www/html # Obtener una shell interactiva de root con su entorno completo # (variables de entorno, directorio home, PATH de root). # Úsalo solo cuando necesites ejecutar varios comandos administrativos # seguidos; no lo dejes abierto. sudo -i # Alternativamente, usar su dentro de sudo — equivalente en la práctica # pero menos idiomático en sistemas modernos sudo su - # Invalidar el timestamp inmediatamente cuando terminas. # Buena costumbre al alejarte del teclado o terminar una tarea administrativa. sudo -k # Ver los últimos intentos de sudo (éxitos y fallos) para tu usuario. # Un fallo aparece como "NOT in sudoers" o "incorrect password". grep sudo /var/log/auth.log | tail -20
Cuando ejecutas sudo apt install htop, el comando que ve el sistema tiene UID 0, pero el log en auth.log dice exactamente usuario TTY=pts/1 PWD=/home/usuario COMMAND=/usr/bin/apt install htop. Si mañana alguien pregunta quién instaló ese paquete y cuándo, la respuesta está ahí. Con acceso directo a root ese rastro no existe de forma confiable.
La línea sudo -u www-data ls /var/www/html muestra algo que mucha gente no usa pero que vale mucho en debugging: sudo no sirve solo para root. Cuando un proceso web falla leyendo un archivo, ejecutar el mismo comando como ese usuario te dice exactamente qué ve el proceso, sin adivinar qué permisos aplican.
sudo -i abre una shell de root con el entorno completo de root: el $HOME es /root, el $PATH incluye /sbin y /usr/sbin, y los archivos que crees pertenecen a root. Eso es diferente a simplemente ejecutar sudo bash, que hereda el entorno de tu usuario y puede producir comportamientos distintos cuando los scripts dependen de variables de entorno. Si vas a trabajar varios minutos como root, -i da un entorno predecible.
El sudo -k al final no es opcional si te preocupa la seguridad. El timestamp existe para comodidad durante una sesión de trabajo, no para quedarse activo mientras te vas a comer. Invalidarlo es un hábito barato que elimina la ventana de oportunidad si alguien se sienta en tu terminal.
N° 37