Cuándo evitar usar sudo en Linux y cómo hacerlo bien

Guía Hardware » Guías de compra » Cuándo evitar usar sudo en Linux y cómo hacerlo bien

Si acabas de aterrizar en GNU/Linux y vienes de seguir una guía de YouTube para instalar Arch, es totalmente normal que te preguntes cuándo usar sudo y cuándo no hacerlo. A primera vista parece muy cómodo: pones sudo delante de un comando, te pide la contraseña y listo, ya eres “admin” durante un rato. Pero detrás de esa comodidad hay bastantes matices de seguridad que, si los pasas por alto, pueden dejar tu sistema vendido.

Muchos usuarios (incluidos administradores de sistemas con experiencia) no son del todo conscientes de que dejar sudo tal y como viene por defecto puede ser un agujero de seguridad importante. Algunas distribuciones lo preinstalan, lo activan para el usuario principal con privilegios casi totales y, para rematar, permiten un periodo de gracia en el que no tienes que volver a poner la contraseña. Si a eso le sumas vulnerabilidades recientes en sudo, o un atacante que consiga acceso a tu sesión, el cóctel puede ser bastante peligroso si no lo tienes bien controlado.

Root, usuarios normales y el principio de mínimo privilegio

Para entender bien cuándo evitar sudo, conviene recordar qué significa trabajar como usuario root frente a usar una cuenta normal. Root es la cuenta todopoderosa del sistema: puede borrar cualquier archivo, cambiar permisos, crear o eliminar usuarios, montar y desmontar sistemas de archivos, instalar y desinstalar paquetes, modificar el nivel de ejecución del sistema… en resumen, no tiene límites técnicos.

En los sistemas Unix clásicos, el administrador se conectaba directamente como root en un terminal físico o teletipo y hacía toda la administración con esa cuenta. Muchas veces tenía otra cuenta “normal” para leer correo o escribir documentos, pero la gestión seria se hacía siempre como root. Aquello funcionaba, pero era peligroso: un simple despiste podía acabar en desastre, y no quedaba apenas rastro de quién había hecho qué si varios admins compartían la misma contraseña.

Con la expansión de GNU/Linux a entornos multiusuario y servidores expuestos a Internet, se asentó el llamado principio de mínimo privilegio: cada cuenta solo debería tener los permisos estrictamente necesarios para hacer su trabajo, ni uno más. Si un usuario solo necesita subir ficheros por SFTP a una carpeta concreta, no tiene ninguna lógica que pueda tomar el control completo del sistema como root.

Aplicar este principio en el día a día implica que trabajes casi siempre con un usuario “limitado” y que solo eleves privilegios cuando realmente hace falta: instalar o actualizar software, cambiar configuraciones de sistema, gestionar servicios, crear usuarios, etc. Justo ahí entran en juego sudo y su, que resuelven el mismo problema desde enfoques bastante distintos.

Qué es sudo y qué es su: diferencias clave

Antes de hablar de cuándo evitar sudo, es fundamental entender qué hace exactamente sudo, qué hace su y qué implica iniciar sesión directamente como root. Se suelen usar como si fueran equivalentes, pero a nivel de seguridad y de trazabilidad no tienen nada que ver.

El comando sudo viene de “superuser do” (ver nuestra guía completa sobre sudo). Permite que un usuario ejecute un programa con los privilegios de otro (por defecto, root) sin tener que iniciar sesión como ese usuario. Su filosofía original es que el administrador pueda delegar uno o varios comandos concretos en usuarios o grupos determinados, sin darles un acceso root completo y permanente.

Una de sus características más importantes es que pide la contraseña del propio usuario que lanza el comando, no la de root. Además, todo lo que se ejecuta con sudo queda registrado en los logs del sistema (por ejemplo en /var/log/auth.log en muchas distros). Eso permite saber quién ha hecho qué y cuándo, lo que en servidores de producción es oro puro.

En el archivo /etc/sudoers puedes definir de forma muy granular qué usuarios o grupos pueden ejecutar qué comandos, desde dónde, si deben introducir contraseña o no, e incluso denegar explícitamente algunas órdenes como el cambio de contraseña de root. También se pueden ajustar directivas como timestamp_timeout, que controla cuántos minutos recuerda sudo la autenticación antes de volver a pedir la contraseña.

su, por su parte, viene de “switch user” (cambiar de usuario). Su cometido principal es cambiar la identidad con la que trabajas en esa terminal, normalmente para convertirte en root, aunque también sirve para pasar a cualquier otra cuenta del sistema. Lo habitual es que pida la contraseña del usuario de destino: si haces su a secas, te pedirá la clave de root.

Cuando usas su para pasar a root, tu shell pasa a ser la de root y puedes ejecutar todos los comandos que quieras con esos privilegios hasta que escribas exit o cierres la terminal. No hay límite de tiempo ni “periodo de gracia”: la escalada de privilegios dura lo que dure la sesión. Y en los logs verás acciones de root, pero ya no tan fácilmente qué usuario humano había detrás si varios comparten la misma contraseña.

Además hay matices según cómo llames a su: con su - se carga el entorno de login de root (su .bashrc, su PATH, variables de entorno, etc.), como si hubiera iniciado sesión desde cero. En cambio su sin guion suele heredar parte del entorno del usuario original. Y con su -c "comando" usuario puedes ejecutar un único comando como otro usuario y volver enseguida a tu cuenta normal.

Sudo vs su y root directo: ventajas, riesgos y casos de uso

En la práctica, la gran duda que se plantean muchos administradores es si es aceptable conectarse a un servidor directamente como root (por ejemplo, vía SSH) y trabajar siempre bajo esa cuenta, o si es mejor entrar con un usuario limitado y tirar de sudo cuando necesites privilegios elevados. Cada vez más distribuciones empujan a la segunda opción.

Por ejemplo, en Debian el acceso SSH directo como root viene desactivado por defecto con PermitRootLogin no, así que, si quieres trabajar como root, tienes que habilitarlo a mano o configurar sudo. En Ubuntu, durante la instalación ni siquiera te preguntan por la contraseña de root, de forma que esa cuenta queda sin clave y no puedes iniciar sesión con ella de manera normal. De nuevo, la idea es que uses sudo.

La razón de fondo es el principio de mínimo privilegio: si un usuario no necesita tocar servicios, instalar paquetes o cambiar configuraciones críticas, no necesita trabajar como root ni tener un “pase VIP” a todo el sistema. Si solo tiene que reiniciar nginx cuando se cae, por ejemplo, se le puede permitir exclusivamente ese comando mediante sudo y nada más.

Trabajar siempre como root es extremadamente cómodo, sí, pero cualquier error tipográfico puede ser devastador. Imagina que, queriendo hacer un rm -rf /tmp/*, metes un espacio raro o escribes mal la ruta; como root, puedes cargarte medio sistema de un plumazo. Si ejecutas ese mismo comando como usuario normal, lo más probable es que el sistema simplemente te diga que no tienes permisos y te salves del desastre.

Entre sudo y su también hay diferencias claras en cuanto a contraseñas y control. Con sudo usas siempre la contraseña de tu propio usuario, mientras que con su deberías conocer la contraseña de la cuenta a la que quieres cambiar (root normalmente). Eso significa que, si varios admins necesitan usar su, hay que compartir la clave de root con todos, lo cual es una pésima práctica: pierdes trazabilidad y revocar el acceso a una sola persona se vuelve un lío.

En cambio, usando sudo no hace falta que nadie conozca la contraseña de root. Cada administrador usa la suya, y si en algún momento quieres revocarle los privilegios, basta con sacarlo del grupo sudo (o wheel) o quitar su entrada del sudoers. No hay que cambiar ninguna clave global. Además, cada uso de sudo se registra asociándolo al usuario que lo lanzó, lo que facilita mucho las auditorías y la investigación de problemas.

Ventajas y peligros de usar directamente la cuenta root

A pesar de todo lo anterior, hay admins que siguen defendiendo el uso de root “de toda la vida”, especialmente en servidores muy controlados y manejados por una sola persona experta. Su argumento es que así se evitan capas adicionales, herramientas intermedias y posibles vulnerabilidades de terceros como las que de vez en cuando aparecen en sudo.

Trabajar como root directo tiene una virtud evidente: es extremadamente sencillo desde el punto de vista operativo. Te conectas vía SSH como root, haces lo que tengas que hacer y ya está. No pones sudo delante de cada comando, no dependes de la configuración de sudoers y no chocas con restricciones que, en algunos entornos, pueden ser demasiado estrictas o estar mal definidas.

Sin embargo, esa simplicidad tiene un precio alto. Una cuenta root accesible remotamente es un objetivo muy jugoso para cualquier atacante: si consigue adivinar o robar la contraseña, ya tiene el control total del servidor. Y si, además, varios administradores comparten esa clave, no tendrás forma de saber cuál de ellos ha realizado una acción concreta ni podrás quitarle el acceso a uno solo sin molestar a los demás.

Por eso muchas distribuciones deshabilitan o limitan el acceso directo de root, especialmente por SSH. Es bastante común ver configuraciones donde solo se permite conectarse con usuarios normales y luego elevar privilegios mediante sudo, dejando root solo para usos locales muy puntuales o emergencias.

Al final, usar root directo puede tener sentido en escenarios muy concretos y controlados, pero desde el punto de vista de buenas prácticas generales, sudo bien configurado suele ofrecer un equilibrio mucho más sano: mantiene el principio de mínimo privilegio, deja trazas claras y permite revocar o ajustar accesos sin reventar nada.

Cómo encaja sudo en el principio de mínimo privilegio

Si te tomas mínimamente en serio el principio de mínimo privilegio, sudo es la herramienta que mejor lo materializa en el día a día. No se trata solo de poner sudo delante de todo, sino de diseñar una política de sudoers coherente con lo que cada usuario necesita hacer.

Por ejemplo, puedes configurar que un usuario concreto solo tenga permiso para ejecutar systemctl restart nginx pero no systemctl stop nginx ni cualquier otra operación de systemd. O conceder a un grupo de usuarios la posibilidad de crear y borrar directorios mediante /bin/mkdir y /bin/rm, pero nada de instalar software ni tocar servicios.

Esta granularidad te permite dar justo el nivel de acceso que cada persona necesita, sin abrir la puerta de par en par. Y si un día alguien deja de necesitar esos privilegios, bastará con editar sudoers o sacarlo del grupo correspondiente. No hay que cambiar contraseñas maestras ni hacer malabarismos.

Otra ventaja fuerte de sudo es el registro detallado de acciones. Cada vez que se usa, se genera una entrada de log con el usuario, el comando, la hora y el contexto. En auditorías y en el análisis de incidentes, esa información es vital para reconstruir qué ha pasado y dónde se metió la pata.

Por todo esto, en la mayoría de entornos profesionales con varios administradores o usuarios con responsabilidades parciales, se considera mala idea depender de root directo y se recomienda usar sudo como herramienta central de elevación de privilegios, siempre debidamente endurecido.

Riesgos de dejar sudo “como viene”

Que sudo sea una herramienta potente no significa que usarla sin tocar nada sea buena idea. De hecho, dejar la configuración por defecto puede resultar casi tan arriesgado como ir siempre de root, sobre todo en equipos compartidos o expuestos.

El primer problema es el famoso periodo de gracia. Por defecto, muchas distribuciones configuran sudo para que, tras introducir la contraseña una vez, no te la pida de nuevo durante unos minutos (normalmente 5, aunque algunas llegan a 15). Es cómodo, porque te evita teclear la clave cada dos por tres si estás encadenando comandos administrativos.

El lado oscuro de ese mecanismo es evidente: si dejas tu sesión abierta en la oficina, en casa compartida o en cualquier entorno donde alguien pueda sentarse un momento delante de tu equipo, mientras dure ese periodo de gracia cualquiera podrá ejecutar sudo sin que el sistema vuelva a pedir la contraseña. En un servidor multiusuario, el riesgo se multiplica.

El segundo punto delicado es el uso de entradas con NOPASSWD demasiado amplias. Es decir, reglas en /etc/sudoers que permiten a uno o varios usuarios ejecutar comandos como root sin introducir contraseña, y, encima, con un ámbito del tipo ALL. Si un atacante logra ejecutar algo como ese usuario, se encontrará con un pase total a root sin barreras adicionales.

A esto hay que sumar que sudo, como cualquier software complejo y muy desplegado, ha tenido y seguirá teniendo vulnerabilidades de seguridad. En los últimos tiempos se han publicado fallos críticos (como los identificados con CVEs recientes) que permiten a un atacante local escalar privilegios a root incluso con configuraciones aparentemente sensatas. Cuantos más sistemas dependen de sudo y peor esté configurado, más atractivo es para los atacantes.

Por este motivo hay administradores que, aunque reconocen que sudo es útil, prefieren no instalarlo en ciertos servidores muy sensibles o deshabilitarlo casi por completo, usando root directo o su solo en contextos muy controlados. Otros, en distros que traen sudo activado de serie, optan por asignar una contraseña a root, quitar a su usuario del grupo sudo y dejar sudo instalado pero sin acceso práctico a privilegios elevados.

Endurecer sudo: configurar la seguridad sin perder usabilidad

Si quieres seguir usando sudo (lo más razonable en la mayoría de casos) pero reduciendo sus riesgos al mínimo, hay varias medidas de hardening bastante sencillas que conviene aplicar cuanto antes.

Lo primero es revisar el periodo de gracia. Para editar la configuración de sudo debes usar siempre visudo, que abre /etc/sudoers con un editor pero, sobre todo, comprueba la sintaxis antes de guardar. Si te equivocas en una coma o una línea, visudo no permitirá dejar el archivo corrupto y así evitas quedarte sin sudo por un simple fallo tipográfico.

Dentro de sudoers puedes añadir una línea como Defaults timestamp_timeout=0 para que sudo pida la contraseña cada vez que se use, sin guardar ningún estado de autenticación. Es la opción más estricta: no hay margen de minutos en los que alguien pueda aprovechar tu sesión.

Si te parece demasiado incómodo, puedes optar por un valor muy corto, como Defaults timestamp_timeout=1, que reduce el periodo de gracia a un minuto. A nivel práctico, sigues ganando algo de comodidad cuando estás encadenando comandos, pero el riesgo de dejar sudo “abierto” disminuye bastante.

Otro ajuste interesante es impedir que los usuarios con acceso sudo puedan cambiar la contraseña de root. En sistemas basados en Debian se puede hacer con una línea del estilo %sudo ALL=(ALL) ALL, !/usr/bin/passwd root, y en sistemas tipo RHEL/CentOS/Fedora se suele usar el grupo wheel, con algo como %wheel ALL=(ALL) ALL, !/usr/bin/passwd root. De esta forma, aunque alguien tenga sudo, no podrá tocar la clave del superusuario.

A partir de ahí se pueden aplicar más capas: obligar a que ciertos usos de sudo solo funcionen desde una pseudo-terminal interactiva, registrar todos los comandos en ficheros adicionales, restringir el PATH de las sesiones elevadas con secure_path para evitar que se cuelen binarios maliciosos, etc. Sudoers tiene muchas directivas que permiten afinar este comportamiento.

Cuándo evitar sudo y usar root o su en su lugar

Llega la pregunta del millón: ¿hay situaciones en las que tenga sentido evitar sudo y tirar de root o su? Aunque suene a sacrilegio en algunos círculos, la respuesta es que sí, pero son escenarios bastante concretos.

En algunos servidores muy aislados, administrados por una única persona con experiencia y sin más usuarios, puede preferirse desinstalar sudo o deshabilitarlo por completo y trabajar siempre con root directo o mediante su. La idea aquí es minimizar componentes potencialmente vulnerables: si no hay sudo, un exploit contra sudo simplemente no puede usarse.

En otros casos, hay admins que no quieren ni oír hablar de periodos de gracia, sudo sin contraseña ni la posibilidad de que su cuenta normal se convierta fácilmente en root. Prefieren compartimentar de forma muy estricta: una cuenta para el uso diario y otra (root) para tareas de administración, sin mezclar. De este modo, si se compromete el usuario normal, el atacante no tiene un camino tan directo hacia privilegios elevados.

Eso sí, este enfoque complica mucho las cosas si hay varios administradores: compartir la contraseña de root vuelve a ser un problema y pierdes las ventajas de trazabilidad y revocación selectiva que te daba sudo. Además, si permites login remoto como root, das a los atacantes un objetivo muy claro para sus ataques de fuerza bruta.

Mirándolo en conjunto, evitar sudo del todo solo suele justificarse en entornos extremadamente controlados. En la gran mayoría de sistemas, la jugada más sensata es mantener sudo instalado, endurecer su configuración, evitar NOPASSWD amplios, acortar o eliminar el periodo de gracia y reservar el uso de root directo para tareas puntuales o de emergencia.

Instalar, conceder y comprobar privilegios sudo

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

El comando de instalación suele ser algo tan simple como ejecutar la orden de tu gestor seguida de install sudo. Por ejemplo, en un Debian típico sería apt install sudo. Obviamente, para hacer eso necesitas estar ya autenticado como root o tener algún otro método de elevación de privilegios.

Una vez instalado, toca otorgar privilegios sudo a los usuarios que deban tenerlos. Tienes dos caminos principales: añadir reglas específicas en /etc/sudoers o incluir al usuario en un grupo privilegiado (como sudo en Debian/Ubuntu o wheel en RHEL/CentOS/Fedora) que ya tenga permisos definidos en sudoers.

Si decides editar sudoers, recuerda otra vez usar visudo. En ese archivo podrías añadir líneas como usuario ALL=(ALL) NOPASSWD:ALL para permitir que ese usuario ejecute cualquier comando como root sin contraseña (algo peligroso salvo en entornos muy concretos) o ser más fino y limitarlo a unos cuantos comandos. Por ejemplo, usuario ALL=(ALL) NOPASSWD:/bin/mkdir,/bin/rm daría acceso sin contraseña solo a crear y borrar directorios.

La otra opción es meter al usuario en el grupo adecuado, con algo como sudo usermod -aG sudo usuario en sistemas tipo Debian o usermod -aG wheel usuario en RHEL/CentOS/Fedora. A partir de ahí, heredará la política definida para ese grupo en sudoers, que en muchas distros equivale a casi root completo previa contraseña.

Si en algún momento quieres comprobar qué privilegios sudo tiene un usuario, puedes usar sudo -l para ver los tuyos propios o sudo -l -U nombreusuario para inspeccionar a otro (siempre que tengas permiso para hacerlo). La salida mostrará qué comandos está autorizado a ejecutar, las restricciones aplicables y los valores por defecto relevantes para ese contexto.

Por contraste, el comando su se limita a cambiar de usuario pidiendo la contraseña de destino. No hay un archivo análogo a sudoers que permita limitar comandos: si conoces la clave de root y el sistema no restrige su, puedes hacerlo casi todo. Por eso, si se opta por usar su, es buena idea restringirlo a usuarios de confianza mediante PAM, por ejemplo exigiendo pertenecer al grupo wheel para poder usarlo.

Todo este conjunto de piezas —root, usuarios normales, sudo, su, grupos y políticas— es lo que determina, en la práctica, hasta qué punto tu sistema sigue el principio de mínimo privilegio o, por el contrario, se fía demasiado de la buena intención de quien tenga un teclado delante. Entender bien cuándo usar sudo, cuándo tirarte a su o root, y sobre todo cuándo conviene limitar o incluso evitar sudo, marca la diferencia entre un entorno robusto y otro que parece seguro solo de puertas afuera.