Lo escribís todo el tiempo. Instalás un paquete, editás un archivo de configuración, reiniciás un servicio: sudo aparece antes de casi cualquier comando que toque algo serio del sistema. Te pide la contraseña, la ponés, y listo. Pero ahí adentro pasan varias cosas que la mayoría de los usuarios nunca se detiene a mirar.

Superuser do, o casi

Durante años se dijo que sudo significaba «superuser do». La explicación más precisa, según el propio proyecto, es «su ‘do'»: ejecutar un comando sustituyendo al usuario que lo pide por otro, que por defecto es root, pero que no tiene por qué serlo. Podés usar sudo para correr algo como otro usuario cualquiera, no solamente como administrador.

La idea nació en la Universidad de Colorado a fines de los 70, cuando varios administradores necesitaban delegar tareas puntuales sin entregar la contraseña de root a todo el mundo. Ese sigue siendo, medio siglo después, el problema real que resuelve.

Qué pasa cuando lo ejecutás

Cuando corrés un comando con sudo, no es tu usuario el que lo ejecuta directamente. sudo es un binario con el bit setuid activado, lo que le permite arrancar con privilegios de root sin importar quién lo llamó. A partir de ahí, antes de hacer nada, se pone a verificar dos cosas: quién sos y qué te está permitido hacer.

Para lo primero, generalmente pide tu contraseña (la tuya, no la de root) y delega esa autenticación en PAM, el sistema de módulos que Linux usa para manejar logins. Para lo segundo, revisa el archivo /etc/sudoers, donde está definido qué usuarios o grupos pueden ejecutar qué comandos, y con qué restricciones.

El archivo sudoers y los grupos

En la mayoría de las distribuciones basadas en Debian, alcanza con pertenecer al grupo sudo para tener acceso completo. En Fedora, Arch y varias otras, ese rol lo cumple el grupo wheel. Esa pertenencia es justamente lo que falta cuando aparece el clásico error «user is not in the sudoers file».

El archivo /etc/sudoers nunca se edita a mano con un editor común: existe un comando específico, visudo, que valida la sintaxis antes de guardar. Un error de tipeo en ese archivo puede dejar al sistema sin nadie capaz de usar sudo, así que la validación no es un capricho.

sudo vs su: no es lo mismo

su te convierte directamente en otro usuario (típicamente root) y te pide la contraseña de ese usuario. Una vez adentro, te quedás operando como root hasta que salís de esa sesión, sin que el sistema registre qué comandos específicos ejecutaste.

sudo, en cambio, ejecuta un comando puntual con privilegios elevados y vuelve a tu usuario normal apenas termina. No necesitás conocer la contraseña de root —de hecho, en muchas distros esa cuenta ni siquiera tiene contraseña habilitada— y cada uso queda registrado con detalle: quién lo ejecutó, cuándo y qué comando corrió exactamente.

Por qué esto importa para la seguridad

Esa diferencia no es un detalle técnico menor. Si diez personas administran un servidor y todas usan su para volverse root, después es imposible saber quién hizo qué. Con sudo, cada acción queda asociada a un usuario real en los logs del sistema, algo fundamental cuando hay que auditar un incidente.

Es la misma lógica detrás del principio de menor privilegio: en vez de entregar acceso total, se le da a cada usuario exactamente lo que necesita. Podés configurar sudoers para que alguien solo pueda reiniciar un servicio puntual, sin darle acceso a nada más del sistema.

Seguramente notaste que si usás sudo varias veces seguidas, solo te pide la contraseña la primera vez. Eso es porque sudo guarda un timestamp por un período corto —cinco minutos por defecto en muchas configuraciones— durante el cual no vuelve a preguntar. Es una comodidad pensada para no interrumpir tareas de administración que requieren varios comandos seguidos, no un agujero de seguridad si la sesión está bien protegida.

Los riesgos de usarlo mal

El problema no es sudo, es cómo se lo configura. Es común encontrar reglas NOPASSWD puestas a las apuradas para evitar tipear la contraseña, que terminan dándole a un usuario acceso total sin ninguna verificación. También es habitual ver gente que antepone sudo a cualquier comando por costumbre, incluso cuando no hace falta, lo que aumenta innecesariamente la superficie de error: un rm mal escrito con privilegios de root pesa mucho más que uno sin ellos.

Conclusión

sudo no es un simple atajo para «que me deje instalar cosas». Es un sistema de delegación de privilegios pensado para que nadie tenga que operar como root todo el tiempo, con registro de auditoría incluido. Entender qué hay detrás de ese comando que usás sin pensar ayuda a configurarlo mejor y, sobre todo, a usarlo con más criterio.

Enlaces recomendados

• Sitio oficial del proyecto sudo
• Página de manual de sudo (man7.org)
• Solución a: «user is not in the sudoers file» en Debian

La entrada ¿Qué hace realmente sudo? se publicó primero en NotiLinux.com.