Cuándo evitar sudo en Linux y cuándo usarlo bien

En el mundo GNU/Linux se repite mucho que tener acceso root permanente es peligroso, tanto en un servidor Linux como en otros entornos como AWS. Sin embargo, a menudo no se explica con calma cuándo conviene usar sudo, cuándo es mejor su, y en qué situaciones es mejor evitar sudo o limitarlo al máximo. Todo esto se cruza con el famoso principio de mínimo privilegio, que en la práctica no siempre es fácil de aplicar sin volverse loco metiendo contraseñas cada dos por tres.

Si trabajas administrando servidores o simplemente tienes tu equipo de escritorio con Linux, es normal que te preguntes cosas como: ¿es tan malo iniciar sesión como root?, ¿por qué algunas distros deshabilitan root y obligan a usar sudo?, ¿es inseguro que sudo recuerde la contraseña unos minutos?, ¿puedo configurar sudo para que sea menos “permisivo”? En las siguientes líneas vamos a ver cómo funciona sudo, en qué se diferencia de su y de iniciar sesión directamente como root, qué riesgos conlleva cada enfoque y qué configuraciones recomendadas puedes aplicar para endurecer la seguridad de tu sistema sin perder usabilidad.

Root, usuarios normales y principio de mínimo privilegio

Antes de meternos con sudo y su, merece la pena recordar qué significa realmente trabajar como usuario root frente a hacerlo como usuario normal. Root es la cuenta todopoderosa: puede borrar cualquier archivo, cambiar permisos a lo que quiera, montar o desmontar sistemas de archivos, crear o eliminar usuarios, instalar o quitar software e incluso cambiar el nivel de ejecución del sistema.

En un entorno Unix clásico, el administrador se conectaba directamente como root en un terminal físico o teletipo y hacía todas las tareas de gestión con esa cuenta. Muchas veces ese mismo admin tenía otra cuenta “no root” para cosas más mundanas como leer correo o escribir documentos, pero la administración pura iba siempre con root, sin filtros ni limitaciones temporales.

Con el tiempo, y sobre todo con la expansión de Linux a escenarios multiusuario y de servidores expuestos a Internet, se impuso el principio de mínimo privilegio: cada usuario solo debería tener los permisos necesarios para realizar su trabajo, ni más ni menos. Si un usuario únicamente sube imágenes por SFTP a una carpeta, no tiene ningún sentido que pueda loguearse como root y toquetear servicios críticos. Eso reduce la superficie de ataque si esa cuenta se ve comprometida.

Aplicado a la práctica, esto implica que lo normal es trabajar el 99 % del tiempo con un usuario “limitado”, y solo elevar privilegios puntualmente cuando hay que instalar paquetes, reiniciar servicios o modificar configuraciones del sistema. Ahí es donde entran en juego sudo y su, con enfoques bastante distintos.

Sudo y su: diferencias clave y casos de uso

Para entender cuándo tiene sentido evitar sudo o, como mínimo, limitarlo, primero hay que tener muy claro qué hace exactamente sudo y qué hace su, porque muchas veces se usan como si fueran equivalentes… y no lo son.

Qué es sudo y para qué se diseñó

El comando sudo viene de “superuser do”. Permite a un usuario ejecutar un programa con los privilegios de otro usuario, por defecto root, pero no se limita a ser “un su de otra forma”: está pensado para que el administrador pueda delegar uno o varios comandos concretos a uno o varios usuarios sin darles el acceso root total.

Entre sus características más importantes está que pide la contraseña del propio usuario, no la de root; y que todo lo que se ejecute con sudo queda registrado en los logs del sistema, habitualmente en ficheros como /var/log/auth.log u otros equivalentes según la distro. Esto permite ver quién ha hecho qué y cuándo, algo fundamental en entornos de producción o con varios administradores.

Además, sudo permite una configuración muy granular en el archivo /etc/sudoers: puedes indicar qué usuarios o grupos pueden ejecutar qué comandos, desde qué máquinas, con o sin contraseña, o incluso negar comandos concretos como el cambio de contraseña de root. Y, por si fuera poco, se puede ajustar su comportamiento con directivas como el timestamp_timeout, que controla cuánto tiempo recuerda la autenticación antes de volver a pedir la contraseña.

Qué es su y en qué se diferencia

El comando su viene de “switch user” (cambiar de usuario). Su cometido principal es modificar la identidad bajo la que estamos operando, normalmente cambiando al usuario root, aunque puede servir para cambiar a cualquier otro usuario del sistema. A diferencia de sudo, aquí lo habitual es que se pida la contraseña del usuario de destino, es decir, la de root si hacemos su a secas.

Cuando usas su para pasar a root, tu shell adopta la identidad de root y puedes ejecutar tantos comandos como quieras con esos privilegios hasta que hagas exit o cierres la sesión. No hay límite de tiempo ni caducidad de la escalada: el cambio de usuario permanece activo mientras dure la sesión. Además, el rastro de auditoría es peor: una vez que estás dentro como root, es más difícil saber qué hizo cada persona si varias comparten la contraseña.

Hay matices importantes según cómo se invoque su. Por ejemplo, su – carga el entorno de root como si este hubiera hecho login directamente (incluidos PATH, variables de entorno, etc.), mientras que su sin guion suele heredar parte del entorno del usuario original. También existe la opción su -c «comando», que ejecuta un comando concreto como otro usuario y después vuelve al original.

El híbrido: sudo su y sudo -su

En muchas distribuciones modernas la cuenta root viene deshabilitada o sin contraseña por defecto (caso típico de Ubuntu), de forma que se fuerza el uso de sudo. Aun así, sigue siendo posible abrir una shell de root con algo como sudo su o sudo su – (equivalente a sudo -su), lo que combina lo peor y lo mejor de ambos mundos si no se usa con cuidado.

Lo que ocurre ahí es que sudo usa tu contraseña de usuario para ejecutar su como root, sin que tengas que conocer una contraseña de root. Desde el punto de vista de seguridad, sigue quedando rastro de que tú has ejecutado su (se registra el sudo), pero a partir de ese momento ya trabajas como root “pleno” hasta que cierres la shell, con todos los riesgos que eso implica.

Ventajas e inconvenientes de usar directamente root

Hay administradores que siguen prefiriendo trabajar directamente como root “de toda la vida”, sin sudo de por medio, especialmente en entornos que controlan al milímetro. Otros en cambio abominan de esta práctica y la consideran un riesgo innecesario. La realidad es que tiene luces y sombras.

En el lado positivo, operar como root tiene una gran simplicidad operativa: te conectas vía SSH con root (si está permitido), haces lo que tengas que hacer y listo. No hay que escribir sudo delante de cada comando, ni lidiar con configuraciones de sudoers, ni pelearse con restricciones de comandos. Para tareas masivas o sesiones largas de mantenimiento, esto puede resultar muy cómodo.

Sin embargo, esa misma comodidad es lo que convierte al uso directo de root en un potencial desastre. Un error tonto como equivocarse en una ruta con rm -rf puede acabar borrando medio sistema, y no habrá ningún cuadro de diálogo de confirmación como en otros sistemas operativos. Además, si la contraseña de root se filtra o es robada, el atacante tiene el control absoluto sin necesidad de saltarse más capas.

Otra pega gorda es que, si varios admins comparten la contraseña de root, no hay forma limpia de revocar el acceso a uno solo: habría que cambiar la clave de root y comunicársela a los demás, con el lío que eso supone. Y el registro de acciones queda mucho más difuso: en los logs verás que “root” ha ejecutado tal comando, pero no qué persona concreta había detrás.

Algunas distribuciones han tomado nota de todo esto y, por defecto, deshabilitan el login directo de root por SSH (como Debian con PermitRootLogin no), o incluso ni siquiera te piden una contraseña de root en la instalación (Ubuntu) y fuerzan el uso de sudo para cualquier tarea administrativa.

El papel de sudo en el principio de mínimo privilegio

Si hablamos de aplicar el principio de mínimo privilegio en serio, sudo es la herramienta estrella porque permite afinar exactamente qué puede hacer cada usuario con privilegios elevados. No se trata solo de “poner sudo delante y ya”, sino de diseñar una política sensata en /etc/sudoers.

Por ejemplo, podrías configurar que un usuario determinado solo pueda reiniciar nginx mediante sudo, pero no pararlo, ni tocar otros servicios ni instalar paquetes. Algo así como permitir “sudo systemctl restart nginx” pero negar explícitamente “sudo systemctl stop nginx”. Otro caso típico es habilitar a un usuario para crear directorios y borrarlos con /bin/mkdir y /bin/rm, pero nada más.

Además, sudo facilita la revocación selectiva de privilegios: si alguien ya no debe poder actuar como superusuario, basta con sacarlo del grupo sudo o eliminar su entrada en sudoers. No hace falta cambiar la contraseña de root ni tocar las cuentas de los demás. Desde el punto de vista operativo y de seguridad, esto es un salto de calidad importante.

El hecho de que cada uso de sudo quede registrado con el usuario, la hora, el comando ejecutado y el contexto (TTY, directorio actual, etc.) añade otra capa de control. En auditorías o investigaciones de incidentes, es una mina de oro para saber qué ocurrió exactamente y quién estaba al teclado.

Por todo esto, en entornos con varios administradores o con usuarios que necesitan algún privilegio puntual, suele considerarse que es desaconsejable usar directamente root y que, entre sudo y su, la opción razonable casi siempre es sudo bien configurado.

Riesgos de una mala configuración de sudo

Aunque sudo sea una herramienta muy potente, dejarla tal y como viene por defecto puede ser un problema serio. Muchas distribuciones la instalan y activan sin apenas ajustes, otorgando al usuario principal poderes casi equivalentes a root completo y con un periodo de gracia de varios minutos sin volver a pedir la contraseña.

Ese “periodo de gracia” (timestamp_timeout), que suele ser de 5 minutos (a veces 15 según la distro), es cómodo porque evita introducir la contraseña una y otra vez cuando estás encadenando comandos. Pero desde el punto de vista de seguridad es delicado: si dejas tu equipo desbloqueado en la oficina o en un lugar donde otra persona pueda sentarse un momento delante, mientras dura ese margen de tiempo cualquiera podría ejecutar comandos con sudo sin necesidad de tu contraseña.

Más grave todavía es cuando se configura, o se deja por defecto, el uso de sudo sin contraseña (NOPASSWD) para ciertos usuarios o grupos en comandos muy amplios (por ejemplo ALL). En ese punto, si un atacante logra ejecutar algo como ese usuario, podrá hacer prácticamente lo que quiera como root sin barreras adicionales.

A esto se suma que sudo ha tenido a lo largo de los años vulnerabilidades explotables que han permitido saltarse restricciones o ganar privilegios de root. Muchas de esas brechas solo se podían aprovechar si la herramienta estaba presente y mal configurada, mientras que quienes trabajaban sin sudo o con políticas muy estrictas a veces ni se veían afectados.

Por todo esto hay administradores que, pese a reconocer que sudo es útil, prefieren instalarlo solo cuando lo necesitan o incluso vivir sin él en servidores concretos, gestionando siempre como root con mucho cuidado. Otros, en distribuciones que lo traen activado por defecto, optan por poner contraseña a root, revocar a su usuario los permisos sudo en /etc/sudoers y dejar sudo instalado pero “capado”.

Cómo endurecer sudo: eliminación del periodo de gracia y más

Si quieres seguir usando sudo pero reduciendo al máximo sus riesgos, hay varias medidas de endurecimiento que conviene aplicar. La primera, muy recomendada, es eliminar o reducir el periodo de gracia de la contraseña.

Para ello debes editar el archivo /etc/sudoers usando siempre visudo (nada de abrirlo a pelo con nano o vim sin más). Visudo se encarga de comprobar la sintaxis antes de guardar; si hay un error, no rompe sudo, que es algo muy importante.

Dentro de sudoers puedes añadir una línea como Defaults timestamp_timeout=0 para que sudo pida la contraseña SIEMPRE, sin conservarla ni un minuto. Es la opción más segura: cada vez que quieras elevar privilegios, tendrás que autenticarte otra vez.

Si quieres un equilibrio entre seguridad y comodidad, puedes dejar un margen muy corto, por ejemplo: Defaults timestamp_timeout=1. Eso hace que la autenticación caduque en un minuto y disminuye el riesgo de que alguien se aproveche de tu sesión abierta y sin vigilancia.

Otra medida interesante es restringir acciones especialmente sensibles como cambiar la contraseña de root desde cuentas con sudo. Para ello, en sistemas tipo Debian puedes añadir una línea como: %sudo ALL=(ALL) ALL, !/usr/bin/passwd root, y en sistemas RHEL/CentOS/Fedora algo análogo con el grupo wheel: %wheel ALL=(ALL) ALL, !/usr/bin/passwd root. Así, aunque alguien tenga sudo, no podrá modificar directamente la contraseña de root.

También es posible obligar a que ciertos usos de sudo solo funcionen desde una pseudo-terminal interactiva, registrar cada comando en un fichero adicional o limitar la ruta PATH para reducir posibilidades de que se cuelen binarios maliciosos. Todo eso se controla con directivas de sudoers y opciones como requiretty, log_output, secure_path y compañía.

Cuándo evitar sudo y optar por root o su

Llega la pregunta delicada: ¿hay situaciones en las que tenga sentido evitar sudo? La respuesta, siendo sinceros, es que sí, aunque depende mucho del contexto, del nivel de confianza en el equipo y del tipo de sistema del que hablemos.

En algunos servidores muy controlados, gestionados por un único administrador experimentado, puede preferirse trabajar siempre con root directo o con su, sin sudo en medio, precisamente para evitar depender de una herramienta adicional que pueda tener sus propias vulnerabilidades o malas configuraciones. En estos casos, se asume que quien opera sabe lo que hace y que no hay usuarios “semiprivilegiados” a los que delegar solo ciertos comandos.

Otro escenario típico es el de admins que no quieren ni oír hablar del periodo de gracia ni de la posibilidad de que su usuario habitual se convierta en un root encubierto. Prefieren tener bien diferenciadas la cuenta root para tareas de root y su cuenta normal para todo lo demás, sin mezclar. De esta manera, si una vulnerabilidad afecta a sudo o si su usuario sin privilegios se ve comprometido, el daño se limita mucho más.

Eso sí, este enfoque tiene sus pegas: si varias personas administran la misma máquina, volveríamos al problema de compartir la contraseña de root y no poder revocar permisos de manera individual. Además, si se hace login remoto como root por SSH, se abre una puerta más apetecible a los atacantes, que solo tendrían que acertar una contraseña para entrar con el máximo poder.

En el lado opuesto, están quienes afirman que lo realmente peligroso no es sudo, sino no configurarlo bien. Es decir, que el uso de root directo sería incluso más arriesgado que un sudo correctamente endurecido y bien auditado. Muchos incidentes reales dan la razón a esta postura: ataques que aprovechan credenciales compartidas de root, comandos fatales ejecutados sin querer o imposibilidad de reconstruir qué ha pasado porque no había logs por usuario.

En resumen, evitar sudo por completo tiene sentido solo en escenarios muy concretos y controlados. En la mayoría de sistemas de producción, lo más razonable es mantener sudo, configurarlo de forma estricta (sin periodos de gracia largos, sin NOPASSWD globales, con restricciones claras) y reservar root directo para tareas muy puntuales o de emergencia.

Instalación, concesión y verificación de privilegios sudo

En la mayoría de distribuciones modernas, sudo viene instalado por defecto. Si al intentar usarlo el sistema te dice “command not found”, tendrás que instalarlo con el gestor de paquetes correspondiente: apt en Debian/Ubuntu, yum o dnf en CentOS/RHEL/Fedora, zypper en SLES/openSUSE, etc.

El comando típico de instalación tendría una forma similar a apt|yum|dnf|zypper install sudo (sustituyendo por la herramienta real de tu sistema). Una vez instalado, el siguiente paso es conceder privilegios sudo a los usuarios que deban tenerlos.

Hay dos caminos habituales: añadir una regla específica en /etc/sudoers o incluir al usuario en un grupo privilegiado como sudo (en Debian/Ubuntu) o wheel (en Red Hat, CentOS, Fedora). Para editar sudoers, recuerda siempre usar visudo; por ejemplo, podrías añadir una línea como invitado ALL=(ALL) NOPASSWD:ALL para que el usuario “invitado” pueda usar sudo sin contraseña en cualquier comando, aunque esto, como ya se ha dicho, es algo delicado en términos de seguridad.

Si quieres ser más fino, puedes limitar el alcance a unos cuantos comandos, por ejemplo: invitado ALL=(ALL) NOPASSWD:/bin/mkdir,/bin/rm. Así, ese usuario solo podrá crear y borrar directorios con sudo, sin necesidad de introducir contraseña, pero no podrá hacer otras cosas como instalar paquetes o reiniciar servicios.

La otra opción es añadir al usuario al grupo sudo con un comando como sudo usermod -aG sudo invitado o al grupo wheel en sistemas tipo RHEL. De esta forma, heredará la política general que el sistema tenga definida para ese grupo en sudoers, que por lo general permite ejecutar casi cualquier comando como root tras autenticarse.

Si alguna vez necesitas comprobar los privilegios sudo que tiene un usuario, puedes usar sudo -l para ti mismo o sudo -l -U nombreusuario para otro, siempre que tu cuenta tenga permiso para consultar. La salida te mostrará qué comandos puede ejecutar, qué restricciones se aplican y qué valores por defecto (Defaults) se usan en su contexto.

Sudo vs su: contraseña, comportamiento y trazabilidad

La comparación entre sudo y su no se limita a la sintaxis; hay diferencias fundamentales en cómo se autentican, cómo se comportan por defecto y qué rastro dejan. Esto tiene mucho que ver con decidir cuál usar y cuándo.

En el apartado de contraseñas, sudo usa la del usuario actual, mientras que su requiere la del usuario destino (root, normalmente). Esto significa que, para que varios admins puedan usar su, hay que compartir la contraseña de root, algo considerado mala práctica porque se hace difícil controlar y revocar accesos.

En cuanto al comportamiento por defecto, sudo está pensado para ejecutar un único comando con privilegios elevados y luego “volver” al estado normal (salvo por el periodo de gracia). Su, en cambio, cambia completamente de identidad y abre una nueva shell como el usuario de destino, permitiendo ejecutar comandos sin límite hasta que decidas salir. Eso lo convierte en algo más peligroso si olvidamos que seguimos siendo root y lanzamos comandos a la ligera.

En el aspecto de logging y auditoría, con sudo cada comando queda asociado a la identidad real del usuario que lo ejecutó, aunque se haya corrido como root. Con su, una vez dentro como root, lo que hagas ya será simplemente “root ha ejecutado tal cosa”, y resulta mucho más difícil rastrear qué persona concreta hizo el cambio si compartís la clave.

Finalmente está la cuestión de la flexibilidad: sudo ofrece mucha granularidad a la hora de limitar comandos y contextos, mientras que con su la escalada suele ser total y sin matices: quien conoce la contraseña de root puede hacerlo prácticamente todo, y no hay un mecanismo estándar integrado para limitar su uso a unos pocos comandos.

Con todo esto sobre la mesa, la mayoría de buenas prácticas actuales recomiendan usar sudo como herramienta principal de elevación de privilegios y reservar su para casos muy puntuales (como su -c para ejecutar algo concreto como otro usuario, o su para depurar un entorno de usuario sin cambiar a root).

Mirando todo el panorama, queda bastante claro que la clave no está solo en elegir entre sudo, su o root directo, sino en cómo se configuran y en qué contexto se emplean. Un sudo bien endurecido, sin periodos de gracia excesivos, con comandos limitados y buena auditoría, ofrece un equilibrio muy razonable entre seguridad y comodidad en la mayoría de sistemas. Apostar por root directo tiene sentido en escenarios muy controlados y con admins expertos, a costa de perder trazabilidad y flexibilidad; mientras que usar sudo “tal cual viene” en muchas distros puede acabar siendo casi tan peligroso como ir siempre de root. Ajustar esas piezas, y tener claro cuándo conviene evitar sudo, es lo que marca la diferencia entre un sistema robusto y uno que solo lo parece.