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

Inicio » Windows » Cuándo evitar usar sudo en Linux y cómo gestionarlo bien

Si llevas un tiempo usando GNU/Linux, seguro que has oído mil veces que tener acceso root permanente es peligroso, tanto en un servidor local como en un entorno en la nube tipo AWS. También es bastante habitual escuchar consejos del estilo “usa siempre sudo” o “nunca trabajes como root”, pero rara vez se explica con calma cuándo conviene usar sudo, cuándo es mejor su y, sobre todo, en qué situaciones interesa evitar o limitar al máximo sudo para cumplir de verdad el principio de mínimo privilegio.

Además, está el factor comodidad: escribir sudo delante de cada comando y meter la contraseña una y otra vez acaba siendo un rollo. Eso lleva a algunos usuarios a ideas peligrosas como «hago un chown a medio sistema y así no necesito sudo», o a configurar sudo para que no pida contraseña nunca. Son atajos tentadores pero que pueden dejar tu máquina vendida. En las siguientes líneas vamos a ver, con bastante detalle, cómo funciona sudo, en qué se diferencia de su y del login directo como root, qué riesgos concretos tiene cada enfoque y cómo puedes configurarlo de forma sensata para no ir con la escopeta de root cargada todo el rato.

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

En cualquier sistema tipo Unix, la cuenta root es la llave maestra del sistema: puede borrar cualquier archivo, cambiar permisos de todo, montar y desmontar sistemas de ficheros, modificar cuentas de usuario, instalar o desinstalar paquetes, ajustar el nivel de ejecución… vamos, que si te equivocas como root no hay “ventanita” de confirmación que te salve.

Históricamente, en los primeros sistemas Unix el administrador se conectaba directamente como root en un terminal físico o teletipo y hacía toda la administración con esa cuenta. A veces tenía otra cuenta “normal” para tareas de usuario (correo, documentos…), pero la parte seria se hacía siempre como superusuario, sin medias tintas ni limitaciones temporales.

Con la popularización de GNU/Linux en equipos personales, servidores conectados a Internet y entornos multiusuario, empezó a imponerse el famoso principio de mínimo privilegio: cada cuenta solo debería tener los permisos estrictamente necesarios para hacer su trabajo. Si alguien únicamente tiene que subir imágenes por SFTP a una carpeta, no hay ninguna razón para que pueda conectarse como root y tocar /etc o /usr/local.

Aterrizado a la práctica, esto significa que lo razonable es utilizar un usuario “limitado” para el 99 % de las tareas diarias y elevar privilegios solo cuando hay que hacer cosas de sistema: instalar paquetes, reiniciar servicios, editar ficheros bajo /etc, gestionar usuarios, etc. Ahí entran en juego sudo y su, dos herramientas que a menudo se confunden pero que fueron diseñadas con objetivos muy distintos.

Desde esta óptica, la pregunta ya no es solo si root “es malo”, sino si tu forma de usar sudo o su respeta de verdad el mínimo privilegio o, por el contrario, te has montado un pseudo-root encubierto que deja al sistema vendido ante cualquier fallo de seguridad o despiste humano.

Sudo y su: qué hace cada uno y por qué no son lo mismo

Para tener claro cuándo interesa evitar o limitar sudo, lo primero es distinguir bien qué hace sudo y qué hace su. En muchas guías se usan casi como sinónimos, pero a nivel de seguridad y auditoría se comportan de forma muy diferente.

Sudo viene de “superuser do”. Su razón de ser es permitir que un usuario ejecute un programa concreto con los privilegios de otro usuario (normalmente root), sin cambiar por completo de identidad. Lo potente de sudo no es solo la elevación en sí, sino que esa delegación se puede afinar al milímetro desde el fichero de configuración /etc/sudoers.

Entre las características clave de sudo están que pide la contraseña del propio usuario (no la de root) y que registra todo lo que ejecuta en los logs del sistema, en ficheros como /var/log/auth.log u otros equivalentes según la distribución. Gracias a eso se puede saber quién ejecutó qué comando, a qué hora y desde qué terminal, algo crucial cuando hay varios administradores o se requiere trazabilidad.

Además, sudo permite definir políticas muy granularmente: qué usuarios o grupos pueden usarlo, desde qué máquinas, con qué comandos exactos, si deben introducir contraseña o no, cuánto tiempo se mantiene válida la autenticación (parámetro timestamp_timeout), qué ruta PATH se aplica en sesiones sudo, si se registra toda la salida de los comandos, etc. Bien usado, sudo es una navaja suiza de control de privilegios.

Su, por su parte, viene de “switch user”. Su finalidad principal es cambiar de identidad de usuario durante una sesión: se puede usar para pasar a root, pero también para adoptar cualquier otra cuenta del sistema. Lo normal es que pida la contraseña del usuario de destino; es decir, para hacer su a secas y convertirse en root hace falta conocer la contraseña de root.

Cuando se usa su para pasar a root, la shell que obtienes ya es una sesión completa de root: puedes ejecutar tantos comandos como quieras con plenos poderes hasta que cierres la sesión con exit. No hay límite de tiempo ni caducidad de la escalada, salvo que tú mismo termines la sesión, y a partir de ese momento los logs mostrarán simplemente que “root” hizo tal cosa, sin asociarlo directamente a la persona que estaba detrás si la contraseña se compartía.

Hay matices importantes: su – carga el entorno de root como si hubiera iniciado sesión desde cero (incluyendo PATH y variables de entorno propias), mientras que su sin guion suele heredar parte del entorno del usuario original. También existe su -c «comando», que ejecuta un comando concreto como otro usuario y después vuelve a la cuenta inicial, útil para tareas puntuales sin abrir una shell interactiva completa.

El híbrido peligroso: sudo su y shells de root “camufladas”

En muchas distribuciones modernas, la cuenta root viene deshabilitada o sin contraseña por defecto. Es el caso típico de Ubuntu: durante la instalación no se pide clave de root y se anima a hacerlo todo con sudo. Aun así, se suele poder abrir una shell de root escribiendo sudo su o sudo su – (o equivalentes como sudo -s o sudo -i según la configuración).

Lo que pasa ahí es que sudo ejecuta su como root utilizando tu propia contraseña de usuario, sin que exista (o sin que conozcas) una contraseña de root independiente. En los logs quedará constancia de que ese sudo lo has lanzado tú, pero desde el momento en que la shell se convierte en root, empiezas a trabajar como superusuario a tiempo completo.

Este patrón “sudo su” se usa mucho por comodidad, porque evita tener que escribir sudo delante de cada comando, pero pierde gran parte de las ventajas de sudo: pasas de un modelo de privilegios temporales y acotados a una sesión root plena que puede durar horas, con más margen para errores gordos y menos control sobre qué se hizo exactamente con privilegios elevados.

En sistemas donde varias personas administran la misma máquina, este híbrido puede ser especialmente delicado: en teoría hay trazabilidad de quién ha usado sudo, pero, una vez dentro de la shell root, la actividad queda diluida bajo esa identidad única. Además, si esa sesión se queda abierta en una terminal sin bloquear, cualquiera que pase por delante tiene root en bandeja.

Esto no significa que “sudo su” esté prohibido, pero sí que conviene reservarlo para casos muy concretos, como tareas de mantenimiento prolongadas en las que realmente te compensa trabajar como root puro, y nunca dejar esas sesiones abiertas alegremente ni usarlas como tu entorno de trabajo habitual.

Ventajas e inconvenientes de trabajar directamente como root

Hay administradores que siguen prefiriendo “el root de toda la vida” y prácticamente no usan sudo en absoluto, sobre todo en máquinas que solo controlan ellos. Otros se ponen de los nervios solo de oír hablar de login directo de root por SSH. La realidad es que ambas posturas se apoyan en argumentos razonables.

Operar como root tiene una gran ventaja: simplicidad operativa absoluta. Te conectas por SSH a root@servidor (si está permitido), o haces su desde una consola local, y a partir de ahí nada de escribir sudo delante de cada comando ni pelearte con reglas de sudoers. Para tareas masivas, scripts de mantenimiento, restauraciones o configuraciones iniciales puede resultar muy cómodo.

El problema es que esa comodidad facilita también los desastres. Un simple despiste con un rm -rf mal escrito, un chown recursivo en el directorio equivocado o un script mal testeado pueden tumbar el sistema entero sin que haya una barrera intermedia. Y, a diferencia de otros sistemas operativos más “amigables”, en Linux no verás cajas de confirmación preguntando si estás seguro.

A nivel de seguridad, la principal desventaja de root es que, si su contraseña se filtra o alguien consigue averiguarla, el atacante obtiene control total inmediato sin más pasos. Si además varias personas comparten la misma clave de root (algo desgraciadamente muy habitual), revocar el acceso a una sola persona implica cambiarla para todos y redistribuirla, con el lío organizativo que conlleva.

Por si fuera poco, trabajar siempre como root empobrece mucho la trazabilidad: en los registros quedará que el usuario root hizo tal cosa, pero no quién estaba sentado al teclado en ese momento. Para auditorías, forenses y cumplimiento normativo esto es un dolor, y cada vez más empresas lo consideran inaceptable.

Por todo esto, muchas distribuciones han optado por deshabilitar el login directo de root por SSH (como hace Debian con la opción PermitRootLogin no) o incluso por no permitir definir contraseña de root durante la instalación (como Ubuntu) y obligar al uso de sudo para tareas administrativas.

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

Si nos tomamos en serio eso de que cada usuario solo debe tener los permisos estrictamente necesarios, sudo se convierte en la herramienta estrella. El truco no está en “poner sudo delante de todo”, sino en diseñar una política de /etc/sudoers razonable y adaptada a tus necesidades reales.

Por ejemplo, un usuario que solo necesita poder reiniciar nginx cuando el servicio se cae no tiene por qué poder instalar paquetes ni modificar otros servicios. Puedes crear reglas que permitan exclusivamente sudo systemctl restart nginx y nieguen comandos como systemctl stop nginx o apt install. Del mismo modo, se puede autorizar a ciertos usuarios a crear y borrar directorios (mediante /bin/mkdir y /bin/rm) pero no a tocar nada más delicado.

Una ventaja enorme de sudo es que la concesión y retirada de permisos es muy granular y reversible. Si alguien ya no debe tener privilegios elevados, basta con sacarlo del grupo de sudoers o borrar/ajustar su entrada en sudoers; no hay que cambiar contraseñas globales ni coordinarse con otros admins para redistribuir claves de root.

El registro que deja sudo también es oro puro: cada ejecución queda asociada a un usuario concreto, con hora, TTY, comando exacto y, en configuraciones avanzadas, incluso con la salida estándar y de error capturada en un log específico. En entornos profesionales, esto simplifica muchísimo la auditoría de cambios y la investigación de incidentes.

Por todo lo anterior, en máquinas con varios administradores o en servidores accesibles desde Internet, usar sudo bien configurado suele ser la opción más sensata. Trabajar siempre como root directo o delegar privilegios a través de su sin control fino suele ir en contra del mínimo privilegio, además de complicar la seguridad y la trazabilidad.

Los riesgos de dejar sudo “como viene”

Ahora viene la parte menos simpática: aunque sudo sea una gran herramienta, dejarlo tal cual viene por defecto puede ser un agujero de seguridad. Muchas distribuciones lo instalan y activan automáticamente, dando al usuario principal poderes casi equivalentes a root completo.

Un ejemplo típico es el famoso periodo de gracia de la contraseña. Por defecto, después de meter tu clave una vez, sudo no vuelve a pedirla durante varios minutos (suele ser 5 o 15, según la distro). Es muy cómodo cuando estás encadenando comandos administrativos, pero también abre la puerta a que alguien se aproveche de una sesión desbloqueada y obtenga acceso root sin saber la contraseña.

Otro punto delicado son las configuraciones que usan NOPASSWD de forma alegre, permitiendo que un usuario o grupo ejecute cualquier comando con sudo sin necesidad de autenticarse. Esta configuración puede tener sentido en scripts muy concretos o entornos automatizados, pero aplicada a una cuenta de usuario normal multiplica el impacto de cualquier explotación de vulnerabilidades o robo de sesión.

No hay que olvidar que sudo en sí mismo ha tenido vulnerabilidades de seguridad a lo largo de los años. Muchas de ellas solo se podían explotar si sudo estaba presente y, sobre todo, si estaba configurado de forma laxa. En algunos casos, las configuraciones conservadoras o el uso nulo de sudo dejaban fuera del alcance esos fallos a determinados sistemas.

Por cosas como estas, hay administradores que, aun reconociendo la utilidad de sudo, prefieren que su usuario habitual no tenga acceso total y optan por trabajar con root clásico para las tareas de administración. En distros que traen sudo activado de fábrica, es bastante frecuente ver a admins que establecen una contraseña a root, revocan el acceso sudo al usuario diario en /etc/sudoers y dejan el binario instalado pero sin privilegios efectivos.

En el extremo opuesto están quienes sostienen que el problema no es sudo, sino no configurarlo bien. Es decir, que una política estricta de sudo (sin NOPASSWD generalizados, sin periodos de gracia largos, con comandos acotados) ofrece más seguridad que el uso predominante de root directo. La experiencia práctica en muchas organizaciones respalda bastante esta visión.

Cómo endurecer sudo sin volverte loco con la contraseña

Si quieres seguir aprovechando sudo pero recortar al máximo sus riesgos, hay varias medidas bastante efectivas que puedes aplicar tocando el fichero /etc/sudoers (siempre con visudo, nada de abrirlo a pelo con un editor cualquiera).

La primera es controlar el timestamp_timeout, que define cuántos minutos dura el periodo de gracia. Establecer Defaults timestamp_timeout=0 hace que sudo pida la contraseña en cada ejecución, sin recordar nada. Es la opción más paranoica, pero también la más segura, porque elimina el riesgo de que otro se aproveche de tu sesión abierta.

Si eso te parece demasiado incómodo, puedes optar por un término medio razonable, como Defaults timestamp_timeout=1, que mantiene la autenticación válida solo durante un minuto. A efectos prácticos sigues evitando meter la contraseña veinte veces seguidas cuando estás ajustando algo rápido, pero reduces mucho la ventana de ataque en caso de despiste.

Otra medida muy recomendable es limitar comandos especialmente sensibles. En sistemas tipo Debian, por ejemplo, podrías prohibir que los miembros del grupo sudo cambien la contraseña de root añadiendo algo del estilo: %sudo ALL=(ALL) ALL, !/usr/bin/passwd root. En entornos RHEL/Fedora podrías usar el grupo wheel de forma parecida.

También es posible definir opciones específicas por usuario, host, comando o grupo usando la directiva Defaults en distintos niveles. Puedes forzar que ciertos comandos solo se ejecuten desde un pseudo-terminal interactivo, definir un fichero de log propio para las acciones de sudo, ajustar la máscara de creación de ficheros (umask) cuando se ejecutan comandos privilegiados o cambiar el mensaje de error cuando alguien falla al introducir la contraseña.

Si quieres rizar el rizo, sudo permite incluso registrar la salida de los comandos (log_output), afinar el PATH que se usa al ejecutar cosas como root (secure_path) o impedir que desde un programa lanzado con sudo se abra otra shell con los mismos privilegios (NOEXEC). Bien usado, todo esto te ayuda a reducir el riesgo tanto de errores humanos como de abusos de privilegios.

Cuándo evitar sudo y apostar por root o su

Con todo lo anterior, es razonable preguntarse si hay escenarios donde tenga sentido evitar o prescindir casi por completo de sudo. La respuesta honesta es que sí, aunque no son los más habituales.

En servidores muy concretos, gestionados por un único administrador experimentado y sin usuarios “intermedios”, puede ser aceptable trabajar siempre como root o mediante su, con sudo desactivado o incluso sin instalar. La lógica es que se reduce la superficie de ataque derivada de posibles vulnerabilidades de sudo y se evita la tentación de dar pseudo-root a cuentas que no lo necesitan.

También hay administradores que prefieren separar radicalmente sus identidades: usan su cuenta habitual para todo lo cotidiano y solo entran como root para tareas de root, sin posibilidad de usar sudo desde la cuenta normal. De esta manera, si su usuario sin privilegios se ve comprometido o alguna aplicación suya tiene un fallo de seguridad, el atacante no puede saltar a root con un sudo mal controlado.

Eso sí, este enfoque tiene pegas importantes. En sistemas donde colaboran varias personas, volveríamos al problema de compartir la contraseña de root y no poder revocar de forma selectiva. Y si se permite el login remoto de root por SSH, se abre un objetivo muy suculento para ataques de fuerza bruta y robo de credenciales.

En el otro extremo, hay quienes consideran que lo realmente inseguro es prescindir de sudo, porque eso fomenta usar root más de la cuenta y hace imposible limitar acciones concretas o tener logs detallados por usuario. Muchas brechas reales han tenido más que ver con contraseñas de root compartidas y comandos peligrosos ejecutados sin cuidado que con un uso correcto de sudo.

Al final, la conveniencia de evitar sudo dependerá mucho del contexto: en máquinas personales o servidores monousuario, un enfoque “root clásico” puede tener sentido si sabes lo que haces y mantienes buenas prácticas (contraseñas robustas, SSH bien configurado, sin login gráfico como root…). En entornos multiusuario o empresariales, renunciar a sudo suele ser una mala idea porque pierdes herramientas clave de control y auditoría.

Instalar, configurar y verificar privilegios sudo

En la mayoría de distribuciones modernas, sudo viene preinstalado y operativo. Si al intentar usarlo ves un “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 patrón suele ser algo como apt install sudo o dnf install sudo con los permisos apropiados.

Una vez instalado, toca decidir quién puede usar sudo y cómo. Hay dos enfoques principales: editar directamente /etc/sudoers con visudo para añadir reglas específicas o jugar con grupos especiales como sudo (en Debian/Ubuntu) o wheel (en el mundo Red Hat) y definir políticas por grupo en sudoers.

Visudo es importante porque bloquea el fichero mientras lo editas y comprueba la sintaxis al guardar. Si te equivocas y rompes la sintaxis, no aplica los cambios y así evitas dejar sudo inservible. Recuerda que /etc/sudoers suele ser solo legible por root y que esos permisos deben respetarse para que otros usuarios no puedan cotillear o intentar modificarlos.

En el fichero sudoers puedes definir alias de usuarios, hosts, comandos y grupos de ejecución (Runas_Alias) para simplificar las reglas, establecer opciones globales o específicas (Defaults) y luego crear las reglas de acceso en sí: líneas del estilo usuario host = (usuarios:grupos) comando1, comando2, etc. Las etiquetas PASSWD y NOPASSWD controlan si se solicita contraseña, mientras que EXEC y NOEXEC sirven para restringir que un comando abra shells subordinadas con los mismos privilegios.

Otra forma de conceder privilegios es añadir un usuario al grupo sudo o wheel con un comando tipo sudo usermod -aG sudo nombreusuario. A partir de ahí, heredará la política definida en sudoers para ese grupo, que por defecto suele permitir ejecutar cualquier comando como root tras autenticarse, aunque conviene revisarlo y ajustarlo según tus necesidades.

Para comprobar qué puede hacer exactamente una cuenta con sudo, dispones de la opción -l (list). Ejecutando sudo -l verás qué comandos te están permitidos, qué defaults específicos se aplican a tu usuario y si tienes restricciones especiales. Con sudo -l -U otro_usuario, un administrador con privilegios puede ver la configuración efectiva del resto de cuentas.

En distribuciones que no traen sudo activado de serie o donde se prefiere dejarlo muy limitado, es buena idea revisar también el uso de -u y -g, que permiten ejecutar comandos como otro usuario o grupo siempre que sudoers lo autorice, así como la opción -e, útil para editar ficheros con un editor determinado bajo contexto privilegiado.

A la hora de usar sudo en el día a día, conviene recordar opciones como -v (para refrescar el contador y extender el periodo de gracia) o -k (para invalidar inmediatamente la autenticación y forzar que el próximo sudo pida contraseña). Usadas con cabeza, estas opciones ayudan a encontrar el equilibro entre no estar metiendo la contraseña cada cinco segundos y no dejar sesiones peligrosamente “calientes”.

Mirando todo el conjunto —root directo, su, sudo bien o mal configurado, alias, periodos de gracia, trazabilidad— queda claro que la seguridad real no depende de una única herramienta, sino de cómo encajan todas. Apostar por un usuario normal como cuenta principal, usar sudo con políticas estrictas y sin excesos de confianza, reservar su y root para casos puntuales y revisar con cierta frecuencia tus sudoers y logs es una forma bastante sólida de mantener tus sistemas bajo control sin que administrar Linux se convierta en un suplicio continuo de contraseñas ni en una ruleta rusa a golpe de rm -rf.