Cómo usar sudo en Linux de forma segura y eficaz

Seguidores Online » Redes Sociales » Cómo usar sudo en Linux de forma segura y eficaz

Si usas Linux a diario, tarde o temprano necesitas hacer cambios que tu usuario normal no puede realizar. Ahí entra en juego el comando sudo, la llave temporal que te deja entrar en la zona “prohibida” del sistema sin tener que trabajar siempre como root. Bien usado, es una herramienta potentísima; mal usado, puede convertirse en un verdadero quebradero de cabeza.

A lo largo de este artículo vas a ver qué es exactamente sudo, cómo funciona por dentro, cómo configurarlo con el archivo sudoers y qué trucos de seguridad conviene aplicar para evitar sustos. La idea es que termines de leer sabiendo no solo poner un “sudo” delante de un comando, sino diseñar una política de privilegios fina, segura y cómoda para tu día a día; si quieres ampliar, consulta tutoriales Linux completos.

Qué es sudo y por qué existe

En Linux hay una separación muy clara entre el usuario normal y el superusuario root, y eso es deliberado: root puede hacer literalmente cualquier cosa en el sistema, mientras que un usuario corriente solo tiene permisos limitados. Sudo nace para salvar esa distancia de forma controlada, sin obligarte a iniciar sesión completa como root.

El nombre viene de “superuser do” o, según otras fuentes, “substitute user and do”: en ambos casos, la idea es que permitas a un usuario ejecutar órdenes como si fuera otro usuario, siendo el caso más habitual ejecutar como root. A diferencia de abrir una sesión completa de root con su, sudo se orienta a autorizar comandos concretos durante un tiempo limitado.

En prácticamente todas las distribuciones modernas —Ubuntu, Debian, openSUSE, Fedora, derivados de Red Hat, etc.— sudo viene instalado por defecto como pieza básica del sistema. Tanto es así que, en muchas instalaciones de escritorio, ni siquiera se configura una contraseña de root: el usuario inicial recibe privilegios de sudo y se administra el sistema con esa cuenta.

Un punto clave del diseño es que sudo no tiene por qué usar la contraseña de root. Lo habitual es que pida la contraseña del propio usuario que intenta elevar privilegios, siempre que esté autorizado en la configuración. Eso hace más cómodo delegar tareas: no tienes que ir repartiendo el secreto de root por la oficina o el equipo.

Cómo funciona sudo a nivel práctico

Cuando ejecutas un comando precedido de sudo, como por ejemplo sudo apt-get update, sudo comprueba en su archivo de configuración (sudoers) si tu usuario puede ejecutar esa orden concreta con los privilegios solicitados (entrar en el sistema con privilegios de administrador). Si encaja en alguna regla permitida, te pedirá que te autentiques.

En configuraciones típicas de escritorio, sudo te pide tu contraseña de usuario una primera vez y, si es correcta, almacena un “ticket” de autorización que dura unos minutos (por defecto unos 5 o 15, según distro). Mientras el ticket siga vigente y uses el mismo terminal, puedes seguir lanzando comandos con sudo sin que vuelva a preguntarte la clave.

Ese comportamiento se controla con opciones internas como timestamp_timeout, que puedes personalizar en sudoers. También se puede forzar que expire el ticket con sudo -k o borrarlo por completo con sudo -K, obligando a que la siguiente orden con sudo vuelva a pedir la contraseña sí o sí.

Si el usuario no está autorizado para la acción concreta, sudo lo registrará en los logs del sistema y devolverá un mensaje del estilo “Sorry, user X is not allowed to execute … as root”. Esa auditoría es uno de los grandes puntos fuertes de sudo frente a trabajar directamente como root.

Internamente, en cuanto se valida la autenticación y la política lo permite, sudo cambia las identidades de usuario (UID) y grupo (GID) reales y efectivas al usuario objetivo —root u otro que especifiques con -u— y lanza el comando con esos privilegios. Todo queda controlado y con rastro de quién hizo qué y cuándo.

Diferencias entre sudo y su

Históricamente, lo habitual en Unix era tirar de su para administrar el sistema: “su” abre una nueva shell como otro usuario, normalmente root, pidiéndote su contraseña. A partir de ahí todo lo que hagas en esa sesión se ejecuta con plenos poderes hasta que salgas con exit.

Con sudo el enfoque es distinto: no entras en una sesión completa de root, sino que elevas privilegios solo para la orden que precedas con sudo. Eso invita a que el administrador trabaje el máximo de tiempo posible como usuario normal y solo suba el nivel cuando realmente lo necesita.

Por ejemplo, podrías hacer:

apt-get update devolverá error de permisos, porque un usuario normal no puede tocar los ficheros de bloqueo de /var/lib/apt; sin embargo, al repetir la orden con sudo apt-get update, el sistema te pedirá la contraseña y ejecutará la actualización como root, registrando la operación.

Sudo también permite cambiar de usuario como su, pero de forma más controlada. Con sudo -u pedro whoami lograrás que el comando whoami se ejecute con la identidad de pedro, siempre que la política sudoers permita a tu usuario adoptar esa identidad. No es necesario conocer la contraseña del usuario de destino, solo estar autorizado.

Muchos administradores recomiendan evitar patrones como sudo su o sudo -i para abrir shells de root permanentes, porque anulan buena parte de las ventajas de control y auditoría que aporta sudo. Funcionan, sí, pero se parecen demasiado a trabajar como root sin red de seguridad.

Opciones y sintaxis básica de sudo

La forma más común de usar sudo es muy simple: sudo comando argumentos. Pero el programa tiene un buen puñado de opciones que conviene conocer para sacarle jugo y entender bien su comportamiento.

Algunas opciones especialmente útiles son:

• -h: muestra la ayuda y la lista de opciones disponibles, ideal para refrescar sintaxis.
• -V: indica la versión de sudo y detalles de compilación, útil para depurar comportamientos.
• -l: enseña qué comandos tiene permitidos y prohibidos el usuario actual; con sudo -l -U nombre puedes revisar los permisos de otro usuario si eres root.
• -u usuario: ejecuta la orden como otro usuario distinto de root, por ejemplo sudo -u www-data ls /var/www.
• -g grupo: permite ejecutar con la pertenencia a un grupo concreto, como sudo -g lp lpadmin -x Impresora.
• -b: lanza el proceso en segundo plano, manteniendo el control del terminal para seguir trabajando.
• -v: renueva el ticket de autenticación sin ejecutar ningún comando adicional, útil para que no caduque mientras preparas algo delicado.
• -k y -K: fuerzan la caducidad del ticket, con el matiz de que -K borra cualquier rastro de autenticación previa.

En sistemas con entornos como SLE Micro o similares endurecidos, la filosofía es aún más estricta: no se recomienda tener una sesión de root abierta de forma permanente, y se apuesta por sudo como única vía de administración. Ante cambios en systemd muchas distribuciones endurecen estas políticas. Ahí verás que la mayor parte de herramientas gráficas administrativas también se lanzan internamente a través de sudo.

Instalación y activación de sudo en distintas distribuciones

Aunque la mayoría de distros modernas ya traen sudo instalado y listo para usar, en algunos entornos minimalistas o servidores antiguos puede que debas instalarlo y habilitarlo a mano. El paquete suele llamarse simplemente sudo en todos los gestores.

En sistemas basados en Red Hat (RHEL, CentOS, Fedora), puedes instalarlo con:

yum -y install sudo o dnf install sudo, según la versión. Tras eso, añades tu usuario al grupo adecuado o ajustas sudoers para autorizarlo.

En openSUSE y SUSE Linux Enterprise, la instalación pasa por:

yast -i sudo o con zypper install sudo. Estas distros además ofrecen un módulo de YaST para gestionar sudo; está bien para configuraciones sencillas, aunque se queda corto en opciones avanzadas como NOEXEC o reglas muy finas.

En Debian y derivados, si no se configuró contraseña de root durante la instalación, lo normal es que el primer usuario creado haya sido añadido al grupo sudo y pueda ejecutar sudo sin contraseña inicialmente. Desde ahí se suele instalar y afinar la configuración a gusto.

El archivo sudoers: el corazón de la configuración

Todo lo que sudo permite o prohíbe se define en su fichero principal de configuración, /etc/sudoers. Es un archivo delicado que no hay que editar nunca con un editor de texto cualquiera sin más, porque un error de sintaxis te puede dejar sin acceso administrativo sencillo.

La forma correcta de modificarlo es mediante la orden visudo, que abre sudoers en modo solo escritura controlada y valida la sintaxis antes de guardar. Si te equivocas, te avisará y no romperá el sistema. Además, sudoers viene marcado como solo lectura incluso para root precisamente para forzar a usar visudo.

La sintaxis del archivo se basa en reglas y alias. De forma simplificada, una regla típica se parece a:

usuario host = (runas) lista_de_comandos

Además, se pueden definir alias de usuarios, alias de comandos, de hosts y de identidades de destino para que las reglas sean legibles y fáciles de mantener. Esos alias se declaran así:

XXXX_Alias NOMBRE = elemento1, elemento2, elemento3, donde XXXX puede ser User_Alias, Cmnd_Alias, Host_Alias o Runas_Alias.

Por defecto, verás líneas como:

• root ALL=(ALL:ALL) ALL: el usuario root puede ejecutar cualquier comando como cualquier usuario y grupo en cualquier máquina.
• %sudo ALL=(ALL:ALL) ALL o %admin ALL=(ALL) ALL: los miembros del grupo sudo o admin tienen poderes equivalentes a root vía sudo.

También es frecuente encontrar directivas como @includedir /etc/sudoers.d, que indican a sudo que cargue configuraciones adicionales desde ficheros sueltos en ese directorio. Esta opción es muy recomendable para meter tus cambios locales ahí, en lugar de tocar directamente el sudoers principal.

Alias de comandos, usuarios, hosts y runas

Para mantener una configuración medianamente compleja sin volverte loco, sudoers permite agrupar elementos con alias. Con Cmnd_Alias se definen colecciones de comandos que luego podrás referenciar por un nombre simbólico.

Por ejemplo, podrías tener algo como:

Cmnd_Alias PROGRAMAS_WEB = /usr/bin/systemctl httpd reload, /usr/bin/vim /etc/httpd/conf.d/variables.conf, /usr/bin/vim /etc/php.ini

Esa línea resume varios comandos necesarios para administrar un servidor web. Después podrías decir:

fulano ALL = PROGRAMAS_WEB

Con esa simple regla, el usuario fulano podrá recargar la configuración de Apache y editar determinados ficheros de configuración, pero no tendrá carta blanca para ejecutar cualquier otra cosa como root.

También es posible mezclar comandos permitidos y prohibidos en la misma regla usando el prefijo !. Por ejemplo, podrías permitir a alguien gestionar cuentas, pero impedirle explícitamente cambiar la contraseña de root con passwd.

Con User_Alias agruparás usuarios y grupos, lo cual viene genial en entornos con muchos administradores. Una línea como User_Alias WEBADMINS = fulano, mengano, zutano deja claro de un vistazo quién tiene perfil de administrador web.

De forma similar, con Host_Alias puedes limitar privilegios a un conjunto de máquinas concretas, y con Runas_Alias decides bajo qué identidades alternativas se puede ejecutar cada conjunto de programas. Todo esto combinado permite políticas de “fulano puede actuar como juan y pedro para estos comandos, pero solo si está conectado en tal servidor”.

Buenas prácticas de seguridad con sudo

Sudo es tan flexible que, si no tienes cuidado, puedes acabar dejándolo casi tan peligroso como trabajar directo como root. Por eso, conviene seguir varias pautas básicas para reducir al máximo la superficie de ataque.

La primera recomendación es obvia pero muchas veces se ignora: evita reglas de tipo usuario ALL=(ALL) ALL salvo que tengas una buena razón. Es la manera rápida de dar poderes totales, pero a costa de renunciar a la granularidad que precisamente te ofrece sudo.

En su lugar, define listas concretas de programas que realmente necesita cada rol. Por ejemplo, quizá un administrador web solo requiere systemctl para reiniciar servicios, algunas herramientas de red, editores como vim sobre ficheros muy concretos y poco más. Con un Cmnd_Alias bien diseñado, puedes autorizar solo ese subconjunto y nada más.

Otra regla de oro es prohibir expresamente comandos que sirvan para escalar de nuevo privilegios o escapar a una shell interactiva. Suele tener sentido negar /bin/su, /bin/bash, /usr/bin/sudo (para evitar “sudo sudo …”), /usr/sbin/visudo y similares, si ya has concedido un abanico amplio de órdenes.

Muchos editores y paginadores, como vim, vi, less o more, permiten lanzar comandos de shell desde dentro (lo que se llama “shell escape”). Para cortar esa vía, sudo ofrece la opción NOEXEC, que impide que esos programas generen subprocesos ejecutables con privilegios. Una regla típica sería algo como:

fulano ALL = (ALL) ALL, NOEXEC:/bin/vi, /usr/bin/vim, /usr/bin/less, /bin/more

Con eso, fulano podrá abrir y editar ficheros con privilegios, pero no podrá salir a una shell con permisos elevados desde el propio editor. Es un pequeño candado más en la escalera de seguridad.

También debes tener en cuenta que sudo no permite, por defecto, redirigir salidas estándar a archivos arbitrarios del sistema aunque el comando base esté permitido. Por ejemplo, sudo echo "Hola" > /etc/prueba.txt no funcionará tal cual, porque la redirección se hace por el shell, que sigue siendo tu usuario normal.

Para lograr algo así, habría que recurrir a trucos como sudo bash -c "echo 'Hola' > /etc/prueba.txt", de ahí que muchos administradores prohíban directamente /bin/bash o expriman al máximo NOEXEC para reducir este tipo de movimientos creativos; si necesitas manipular archivos, consulta cómo copiar un fichero en Linux.

Gestión de grupos y acceso a sudo

La forma más cómoda de gestionar quién puede usar sudo en sistemas Debian, Ubuntu y derivados es a través del grupo sudo. Si un usuario pertenece a ese grupo, y la configuración por defecto se mantiene, podrá ejecutar cualquier orden con sudo tras autenticarse.

Para comprobar si perteneces al grupo, basta con usar groups o id y revisar si aparece “sudo” entre los grupos listados. Si no aparece, significa que todavía no tienes esos privilegios asignados.

Agregar un usuario existente al grupo se hace con algo tipo:

sudo adduser pepe sudo

A veces la gente cae en la trampa de añadirse al grupo, pero se olvida de cerrar sesión y volver a entrar. El sistema solo lee los grupos en el momento de iniciar la sesión, así que hasta que no te desconectes y vuelvas a loguearte, seguirás sin poder usar sudo aunque técnicamente ya estés en el grupo.

En algunos instaladores de Debian, si dejas sin contraseña a root, se crea automáticamente un usuario normal con acceso a sudo y la administración del sistema se guía por esa vía desde el primer arranque. Aun así, es recomendable revisar y ajustar sudoers para adaptarlo a tus políticas de seguridad.

Edición segura de sudoers y uso de /etc/sudoers.d

Antes ya hemos mencionado que la única forma sensata de editar sudoers es usando visudo. Este comando abre el archivo en el editor configurado (frecuentemente vi o nano), bloquea el acceso concurrente y valida la sintaxis al guardar.

Además de tocar la configuración principal, es muy buena práctica aprovechar la inclusión de /etc/sudoers.d. Así, puedes crear ficheros específicos para grupos o servicios concretos sin mezclarlo todo en un único archivo gigante.

Por ejemplo, si quieres dar ciertos privilegios relacionados con red a un grupo llamado netadmin, puedes ejecutar:

sudo visudo -f /etc/sudoers.d/networking

Y dentro definir alias como:

Cmnd_Alias CAPTURE = /usr/sbin/tcpdump
Cmnd_Alias SERVERS = /usr/sbin/apache2ctl, /usr/bin/htpasswd
Cmnd_Alias NETALL = CAPTURE, SERVERS
%netadmin ALL = NETALL

A partir de ese momento, cualquier usuario añadido al grupo netadmin podrá usar esos comandos con sudo, sin tocar el resto de configuración global. Es un enfoque modular y mucho más mantenible, especialmente en servidores con muchos roles.

En la misma línea, hay opciones de Defaults que conviene revisar, como env_reset, secure_path, use_pty, log_input o log_output, que controlan aspectos como qué variables de entorno se conservan, qué PATH se usa para root, si se obliga a usar pseudo-terminales o si se registran entradas y salidas. Un sudo -L te mostrará la lista completa de opciones posibles.

Modos “seguro” y “cómodo” de usar sudo

Un debate recurrente alrededor de sudo es si exigir siempre contraseña o permitir que ciertas órdenes se ejecuten sin pedirla. La herramienta ofrece ambas posibilidades, pero no todas son igual de recomendables.

El modo “seguro” consistiría en una configuración tipo:

usuario ALL=(ALL:ALL) ALL

De esta forma, el usuario puede ejecutar cualquier comando con sudo, pero siempre debe introducir su contraseña cuando la sesión de autenticación haya caducado. Si quieres automatizar un poco la activación, puedes incluso crear scripts que generen una entrada para el usuario en /etc/sudoers.d usando su -c "cp ..." para copiar la configuración con permisos de root.

En el extremo “cómodo”, puedes optar por entradas del tipo:

usuario ALL = (ALL) NOPASSWD: ALL

o, aplicado a un grupo:

%sudo ALL=(ALL) NOPASSWD: ALL

Con esto, cualquier miembro del grupo ejecutará sudo sin que jamás se le solicite contraseña. Es tremendamente cómodo para scripts y tareas automatizadas, pero introduce un riesgo serio: si esa cuenta se ve comprometida, saltar a root es trivial.

Una solución intermedia aceptable suele ser limitar el uso de NOPASSWD a comandos concretos y muy controlados —por ejemplo, herramientas internas de despliegue— y mantener requerimiento de contraseña para el resto de órdenes administrativas generales.

Trucos con aliases de shell para usar sudo más cómodo

Una vez que tienes la política de sudoers bien afinada, llega el momento de hacer tu vida diaria un poco más agradable. Una forma sencilla es crear alias en tu shell (bash, zsh, etc.) para que ciertos comandos siempre se ejecuten con sudo por defecto.

Por ejemplo, en sistemas tipo Red Hat, puedes editar tu ~/.bashrc e incluir líneas como:

alias systemctl="sudo /usr/bin/systemctl"
alias yum="sudo /usr/bin/yum"
alias vi="sudo /usr/bin/vim"

Con eso, cada vez que escribas systemctl restart sshd, en realidad se ejecutará sudo /usr/bin/systemctl restart sshd de forma automática. Es una forma práctica de no olvidarte el “sudo” delante en tareas que siempre requieren privilegios.

En openSUSE y SUSE se suele recurrir a un archivo ~/.aliases, donde puedes definir cosas similares: alias para zypper, yast, chown, chmod, etc., todos invocando sudo bajo el capó. Solo recuerda que, aunque el alias te simplifique la escritura, la política de permisos sigue siendo la definida en sudoers.

Conviene no perder de vista que abusar de alias que ocultan sudo puede hacer que bajes la guardia: está bien para herramientas de administración repetitivas, pero no para todo. La clave está, como casi siempre en seguridad, en el equilibrio.

En definitiva, entender bien cómo funciona sudo, cómo se configura su archivo sudoers y qué opciones de seguridad pone sobre la mesa te permite convertirlo en un aliado esencial en cualquier sistema Linux. Con una política bien pensada, combinarás la flexibilidad del acceso temporal de superusuario con un control milimétrico sobre quién puede hacer qué, dónde y cómo, reduciendo al mínimo los riesgos de accidentes y accesos indebidos.