En cualquier sistema GNU/Linux, el usuario root es esa figura a la que todo el mundo respeta (y a la que conviene tenerle un poco de miedo). Es el equivalente al “administrador” de otros sistemas, con la diferencia de que aquí los permisos son tan amplios que un comando mal escrito puede dejar el sistema hecho polvo en segundos. Entender bien qué es root, qué son los privilegios de root y cómo gestionarlos marca la diferencia entre un sistema estable y uno que se rompe a la mínima.
Además, cada distribución tiene una forma particular de manejar estos privilegios. Ubuntu, Debian, Void, openSUSE y otras distros no se comportan exactamente igual con la cuenta root, con grupos como wheel o con el archivo sudoers. Si administras servidores (VPS, cloud o dedicados) o simplemente quieres manejar tu equipo Linux con cierta tranquilidad, te interesa dominar cómo funciona el usuario root, el comando sudo, el uso de su y la gestión de permisos de administración.
Qué es exactamente el usuario root en Linux
En Linux y otros sistemas tipo UNIX, el usuario root es la cuenta con UID 0, el identificador especial que otorga control total sobre el sistema. Esa cuenta suele estar asociada también al GID 0 (grupo principal root), lo que le permite leer, modificar o borrar cualquier archivo, gestionar procesos, cambiar permisos y tocar cualquier sección del sistema de ficheros, sin restricciones.
Cuando se habla de “ser root” se hace referencia a iniciar sesión o obtener una shell que se ejecuta con UID 0. No es simplemente “tener más permisos”: es usar la cuenta que tiene poder absoluto sobre el sistema. Todo lo que hagas bajo esa identidad se ejecuta sin barreras.
Otra cosa distinta es tener privilegios de root. Esto significa que tu usuario normal (por ejemplo, con UID 1000) puede, a través de herramientas como sudo, ejecutar ciertos comandos “como si fuera root”, sin que tu sesión cambie de identidad de forma permanente. En la práctica, puedes hacer las mismas tareas de administración, pero en ventanas de tiempo más controladas y con mejor trazabilidad.
Diferencia entre ser root y tener privilegios de root
Conviene separar bien los conceptos, porque no es lo mismo entrar como root que ejecutar algo con permisos de root. Aquí entran en juego tanto la cuenta UID 0 como los mecanismos de elevación de privilegios (sudo, su, grupos como wheel, etc.).
Cuando eres el usuario root (UID 0, GID 0) y haces un id, verás algo parecido a:
uid=0(root) gid=0(root) groups=0(root)
Eso indica que la sesión actual pertenece a root y que todo lo que ejecutes tendrá esos permisos. No hace falta escribir sudo delante de nada: cualquier comando tiene vía libre. Por eso es tan peligroso permanecer mucho tiempo en una shell de root.
En cambio, cuando usas sudo, lo normal es que sigas siendo tu usuario “normal” (por ejemplo UID 1000), pero el comando se ejecuta momentáneamente como UID 0. Si haces:
sudo apt update
tu sesión sigue siendo la de tu usuario, pero solo ese comando concreto se ejecuta con permisos de administrador. Lo mismo si lanzas:
sudo systemctl restart apache2
En ambos casos, la identidad que figura en los registros de autenticación indica qué usuario ha usado sudo, lo que aporta trazabilidad y responsabilidad individual.
El caso de wheel, sudoers y grupos de administración
En algunas distribuciones (como Void Linux, o muchas derivadas de BSD) existe el grupo wheel, que se usa para controlar quién puede usar su o sudo. En otras (como Ubuntu y Debian en su configuración típica) se recurre al grupo sudo para otorgar esa capacidad. Cada distro lo organiza a su manera, pero la idea es la misma: solo los usuarios que pertenezcan a ciertos grupos pueden escalar privilegios.
Si en Void Linux se te indica que debes añadir tu usuario a wheel, lo normal sería ejecutar algo como:
sudo usermod -aG wheel tu_usuario
Después, al hacer id, deberías ver el grupo wheel listado entre los grupos secundarios. Si no aparece, puede que el cambio no se haya aplicado hasta que cierres sesión, o que el sistema gestione el acceso de forma algo distinta (por ejemplo apoyándose en PAM o en una configuración específica de sudo o su que no exija incluir wheel en todos los casos).
En sistemas como Ubuntu o Debian, lo habitual es que el grupo clave sea sudo. Para agregar un usuario:
sudo adduser nombre_de_usuario sudo
El nivel más fino de control se hace editando el archivo /etc/sudoers (o ficheros en /etc/sudoers.d/) usando siempre visudo, de forma que puedas definir qué comandos exactos puede ejecutar cada usuario o grupo con privilegios de root, en lugar de dar una barra libre total.
Root en Ubuntu: política de seguridad y uso de sudo
Ubuntu sigue una filosofía bastante clara: la cuenta root existe, pero no se usa para iniciar sesión directamente. Nada más instalar el sistema, root tiene UID 0 como en cualquier UNIX, pero no se le asigna una contraseña utilizable para loguearse. En lugar de eso, se potencia el uso intensivo de sudo.
Esto significa que, por defecto, no puedes entrar en la TTY o en la interfaz gráfica como root con contraseña, porque no hay contraseña configurada para ese usuario. Esta decisión reduce la superficie de ataque frente a intentos de fuerza bruta y evita que la gente se pase el día entero trabajando como root sin necesidad.
El flujo “normal” en Ubuntu es: inicias sesión con tu usuario, ese usuario pertenece al grupo sudo, y cuando necesitas hacer algo de administración, ejecutas el comando con sudo y escribes tu propia contraseña, no la de root. De esta manera, el sistema registra quién ha hecho qué, cuándo y con qué comando.
Si en algún momento quieres una shell completa como root (por ejemplo para hacer una serie de tareas seguidas), puedes usar:
sudo -i
sudo su -
Ambos te darán una shell interactiva de root, cargando generalmente el entorno de login de ese usuario. Para abandonar ese modo, basta con ejecutar exit o pulsar Ctrl+D.
¿Está siempre disponible el usuario root?
Da igual la distribución: la cuenta root siempre existe internamente porque es la que tiene UID 0. Lo que cambia dependiendo de la distro es si esa cuenta tiene o no una contraseña válida, si se permite o no el inicio de sesión directo y en qué condiciones se puede llegar a usar.
En el caso de openSUSE (por ejemplo Tumbleweed), durante la instalación puedes dejar técnicamente la contraseña de root en blanco o configurar el sistema para que el usuario normal tenga permisos de administración mediante sudo. Eso puede hacer que no tengas claro si root está “activo” o no. Pero la cuenta root como tal siempre está ahí; otra cosa es que no puedas autenticarte con ella porque no se ha establecido una contraseña o porque el sistema lo bloquea mediante PAM o las políticas de inicio de sesión.
Cuando usas su para cambiar a root y escribes la contraseña de tu usuario en lugar de la de root, lo normal es que no funcione, salvo que la distro tenga configurado su para aceptar la contraseña del usuario sudoer en lugar de la de root (algo menos habitual). Lo más común es que su pida la contraseña del usuario de destino, es decir, la de root si haces un simple su.
Además, si observas que al hacer su para pasar a root tu shell sigue leyendo funciones o alias de tu usuario normal, es posible que estés usando una variante tipo su sin guion (su frente a su -), lo que hace que no se cargue plenamente el entorno de login de root. Por eso puede seguir usando tu .bashrc o tu configuración de zsh, generando errores en funciones que no existen para la cuenta de root.
Acceso remoto como root vía SSH
En muchos servidores, cuando contratas un VPS o un dedicado, el proveedor te da acceso SSH directamente como root, con una contraseña o, mejor todavía, con una clave SSH. Desde un sistema Linux, la conexión es tan sencilla como:
ssh root@IP-del-servidor
En Windows, lo habitual es recurrir a un cliente como PuTTY. Tan solo tienes que indicar la IP del servidor en el campo Host Name, pulsar en Open y, cuando aparezca la ventana de terminal, iniciar sesión como root con la contraseña proporcionada o con la clave configurada.
También puedes conectarte con cualquier otro usuario que exista en el servidor y, una vez dentro, escalar a root con sudo o su si ese usuario pertenece a los grupos adecuados o tiene la configuración correspondiente en /etc/sudoers. En ese caso, trabajas con permisos limitados hasta que necesitas hacer una tarea de administración concreta.
Riesgos de usar root sin cuidado
Los privilegios de root son tremendamente útiles, pero también un arma de doble filo. Cualquier error tipográfico o comando mal entendido puede suponer pérdida total de datos, inestabilidad del sistema o agujeros de seguridad que dejan tu máquina vendida.
Uno de los peligros más claros es borrar o modificar archivos del sistema por accidente. Como root, no hay “¿estás seguro?” ni papelera de reciclaje. Un comando como:
sudo rm -rf /
o una variante mal escrita (con una ruta equivocada, un espacio de más, un comodín mal colocado…) puede eliminar medio sistema de ficheros sin pedirte confirmación. Y la recuperación, si es que es posible, suele ser complicada y muy parcial.
También está la cuestión de ejecutar scripts descargados de Internet con permisos de root. Si un script es malicioso o está mal programado, puede borrar archivos sensibles, cambiar configuraciones críticas, instalar malware, desactivar defensas o añadir puertas traseras sin que te enteres. Y si lo has lanzado con sudo, le has regalado permisos ilimitados.
En entornos con varios servidores (producción, pruebas, desarrollo), trabajar como root en varias terminales al mismo tiempo aumenta el riesgo de ejecutar un comando en la máquina equivocada. Un simple reinicio o borrado ejecutado en producción por error puede dejar un servicio fuera de combate y provocar un buen lío.
Para colmo, cuando te acostumbras a trabajar siempre como root, es fácil relajarse demasiado y no revisar dos veces lo que escribes. Reducir el tiempo que pasas con privilegios elevados y revisar cuidadosamente los comandos antes de pulsar Enter es fundamental para no liarla.
Root y seguridad: ataques, logs y auditoría
Desde el punto de vista de la seguridad, root es un punto único de fallo. Si un atacante consigue privilegios de root (ya sea robando credenciales, explotando una vulnerabilidad o engañándote para que ejecutes algo malicioso), pasa a tener control total sobre la máquina.
En servidores expuestos a Internet, habilitar el acceso directo a root por SSH usando solo contraseña es abrir la puerta a ataques de fuerza bruta continuos. Los bots automatizados intentan loguearse como root constantemente, probando combinaciones de contraseñas. Si la contraseña es débil o se reutiliza en otros servicios, estás vendido.
Además, si trabajas siempre como root, cualquier aplicación con vulnerabilidades que se ejecute bajo esa identidad (un navegador, un servidor web mal configurado, etc.) puede servir de puerta de entrada. En cuanto esa aplicación cae, el atacante hereda todos los permisos.
Otro problema importante es la falta de trazabilidad. Cuando se usa sudo, las acciones administrativas quedan registradas en /var/log/auth.log o en el journal (journalctl): qué usuario lanzó qué comando y cuándo. Si, por el contrario, todo el mundo entra directamente como root, los registros solo indican “root hizo esto”, sin poder determinar qué persona estaba realmente detrás.
En entornos donde se exigen normas de seguridad (ISO 27001, PCI DSS y similares), esa trazabilidad y responsabilidad individual es clave. Trabajar siempre como root sin usar sudo dificulta las auditorías, complica la resolución de problemas y suele ir en contra de las buenas prácticas que exigen muchos marcos de cumplimiento. Además, el uso de hardware seguro como dev-tpm0 y TPM puede reforzar la integridad y auditoría del sistema.
Formas de obtener privilegios de root
En la práctica, en la mayoría de distros modernas se usan tres mecanismos principales para acceder a los privilegios de administrador: sudo, su y el inicio de sesión directo (local o remoto). Cada uno tiene su contexto y sus riesgos.
Para ejecutar un solo comando con privilegios de root, lo más habitual es usar:
sudo comando argumentos
Por ejemplo:
sudo apt update
sudo apt install firefox
sudo systemctl restart apache2
sudo nano /etc/ssh/sshd_config
Con esto, no cambias de usuario de forma permanente. Solo ese comando se ejecuta con UID 0, y queda registrado quién lo ha lanzado. Para la mayoría de tareas diarias de administración, esta es la opción más segura.
Si necesitas una sesión de root más persistente porque vas a ejecutar varios comandos seguidos, puedes recurrir a:
sudo -i
sudo su -
Estos comandos te dan una shell de root, cargando normalmente el entorno de login de root (variables, PATH, etc.). Es muy cómodo para ciertas tareas largas, pero conviene abandonar ese modo en cuanto acabes con exit. Cuanto menos tiempo pases como root, menos posibilidades hay de meter la pata.
Habilitar y gestionar la contraseña de root
En Ubuntu y otras distros, aunque se desaconseja, puedes asignar una contraseña a la cuenta root para permitir que se use de forma directa. El comando típico es:
sudo passwd root
El sistema te pedirá primero la contraseña de tu usuario (para validar el uso de sudo) y después te solicitará dos veces la nueva contraseña que quieras asignar a root. A partir de ese momento, root tendrá una contraseña definida y, si las políticas de autenticación lo permiten, podrías iniciar sesión localmente o usar su introduciendo esa clave. En dispositivos como Raspberry Pi, por ejemplo, conviene cambiar la contraseña predeterminada.
Si en algún momento quieres bloquear el inicio de sesión de root sin borrar la cuenta, puedes hacer:
sudo passwd -l root
Eso deshabilita la contraseña (sin eliminarla por completo), impidiendo el acceso directo. Para revertirlo:
sudo passwd -u root
En cualquier caso, especialmente en Ubuntu, la recomendación general es no usar root con contraseña para el día a día. Es mucho más sensato seguir trabajando con tu usuario normal y recurrir a sudo cuando haga falta.
Configuración de SSH para permitir o denegar root
Por motivos de seguridad, muchas instalaciones de servidor traen deshabilitado el login de root por SSH. Para cambiar este comportamiento (aunque no sea lo ideal), hay que tocar el archivo de configuración de OpenSSH: /etc/ssh/sshd_config.
El procedimiento típico es:
- Asegurarte de que root tiene contraseña si piensas usar ese método de autenticación:
sudo passwd root. - Editar la configuración de SSH con privilegios de root:
sudo nano /etc/ssh/sshd_config - Localizar (o añadir) la directiva
PermitRootLoginy establecerla enyessi quieres permitir el acceso directo de root con contraseña. - Reiniciar el servicio SSH para aplicar los cambios:
sudo systemctl restart ssh(osshdsegún la distro).
Lo más sensato, si necesitas algo de flexibilidad sin abrir demasiado la puerta, es usar PermitRootLogin prohibit-password para que solo se acepte autenticación por clave y no por contraseña. Aun así, la opción preferida suele ser conectar como usuario normal y luego utilizar sudo.
Si quieres reforzar la seguridad, basta con revertir estos pasos: en sshd_config pones PermitRootLogin no, reinicias el servicio y, si quieres, bloqueas la cuenta de root con sudo passwd -l root. Así obligas a que toda administración remota pase por usuarios concretos con sudo. Como medida complementaria, considera emplear dm-verity en Linux para proteger la integridad del sistema.
Editar sudoers y dar permisos de root a otros usuarios
Hay veces en que necesitas que un usuario recién creado pueda ejecutar comandos como root. Por ejemplo, imagina que has creado un usuario testftp con useradd o adduser, pero cuando intentas usar sudo te aparece el mensaje: testftp is not in the sudoers file.
La forma “rápida” en muchas distros basadas en Debian/Ubuntu es añadir el usuario al grupo sudo:
sudo adduser testftp sudo
En otros entornos, o si quieres un control más fino, puedes editar el archivo /etc/sudoers (o añadir un fichero específico en /etc/sudoers.d/) usando siempre:
sudo visudo
Dentro, puedes añadir una línea copiando el modelo de root pero para ese usuario:
testftp ALL=(ALL:ALL) ALL
Con esto, testftp podrá ejecutar cualquier comando como root usando sudo, igual que root (pero con trazabilidad). Si necesitas restricciones más duras, puedes limitar los comandos permitidos, exigir TTY, forzar la introducción de contraseña, etc.
En servidores más delicados, lo habitual es no dar “poderes totales” a cualquier usuario del grupo sudo, sino definir en sudoers exactamente qué se puede hacer y qué no. Por ejemplo, permitir solo la gestión de un servicio concreto o de ciertos scripts de administración.
Una vez editado y guardado con visudo, el usuario afectado ya no debería ver el error de “not in the sudoers file” y podrá escalar privilegios de forma controlada.
Buenas prácticas al usar root y sudo
Trabajar con permisos de root no es solo saber qué comandos usar, sino también adoptar hábitos de seguridad sensatos. Algunas recomendaciones básicas que conviene interiorizar:
Lo primero, intenta usar sudo solo para comandos concretos siempre que puedas. Cuanto menos tiempo estés en una shell de root, menos posibilidades hay de cometer un error gordo. Una serie corta de comandos con sudo suele ser más segura que abrir una sesión de root y olvidarte de salir.
Si necesitas usar sudo -i o sudo su -, hazlo cuando tengas claro que vas a ejecutar un grupo de tareas de administración seguidas. En cuanto acabes, sal de root con exit. Dejando una sesión de root abierta en segundo plano, especialmente en una máquina compartida o en un escritorio accesible, aumentas mucho el riesgo.
Jamás abras un navegador, un cliente de correo o documentos sospechosos desde una sesión de root. Cualquier exploit que afecte a esas aplicaciones heredará los permisos de la cuenta que las ejecuta. Siempre que interactúes con contenido no confiable, hazlo como usuario normal.
Otro punto clave es no ejecutar scripts desconocidos con sudo sin leerlos antes. Si alguien te dice “pega este curl | sh con sudo” y tú lo haces sin mirar, le estás dando las llaves de tu sistema. Abre el script en un editor de texto, revisa qué hace, de dónde viene, y si no lo entiendes o no te fías, no lo ejecutes.
Siempre que puedas, descarga software y scripts de fuentes oficiales o muy reputadas, verifica sumas de comprobación cuando estén disponibles y, ante la duda, prueba primero en una máquina virtual o contenedor que puedas descartar si algo sale mal.
Por último, aprovecha el archivo /etc/sudoers para aplicar el principio de mínimo privilegio: da a cada usuario solo los permisos que necesita, ni uno más, y registra todas las acciones con sudo para poder revisar qué ha hecho cada quien en caso de problema.
Entendiendo bien qué es el usuario root, cómo se diferencian los privilegios de root de la cuenta UID 0, y usando con cabeza herramientas como sudo, su, grupos de administración y la configuración de SSH, es posible administrar cualquier sistema Linux con mucha más seguridad y tranquilidad, evitando sustos innecesarios y teniendo siempre claro quién hizo qué y con qué permisos.
