- Root otorga control total en Linux y debe usarse solo para tareas concretas y críticas.
- Sudo y su permiten escalar privilegios, siendo sudo la opción más segura y trazable.
- Los mayores riesgos son borrados críticos, malware persistente y pérdida de trazabilidad.
- Buenas prácticas con contraseñas, SSH y sudoers reducen drásticamente el riesgo al usar root.
Si trabajas con Linux, tarde o temprano acabarás topándote con el famoso usuario root y sus peligros si no lo manejas con cabeza. Es el equivalente al administrador total del sistema y, mal usado, puede dejar tu ordenador o servidor hecho un solar en cuestión de segundos.
Al mismo tiempo, necesitas entender cuándo y cómo utilizar root sin convertir tu sistema en una ruleta rusa. En entornos de escritorio parece menos grave, pero cuando hablamos de servidores, nubes, VPS o máquinas de producción la cosa se pone muy seria. En esta guía vamos a ver con detalle qué es root, cómo funcionan sudo y su, qué riesgos reales tiene usarlo, cómo habilitarlo o bloquearlo, cómo cambiar y recuperar contraseñas, y qué buenas prácticas de seguridad conviene seguir para no jugarte tus datos ni la privacidad.
Qué es exactamente el usuario root y cómo encaja en Linux
En cualquier sistema GNU/Linux, el usuario root es la cuenta con UID 0 que tiene control absoluto sobre todos los recursos: puede leer, escribir o borrar cualquier archivo, arrancar o parar servicios, instalar o eliminar paquetes, cambiar permisos y, básicamente, hacer lo que quiera sin pedir permiso a nadie.
Junto al superusuario existen usuarios normales con permisos acotados y usuarios de sistema (daemons) muy restringidos. Los usuarios estándar trabajan en su directorio personal, no pueden instalar software global ni modificar ficheros críticos, y cuando necesitan más privilegios recurren a sudo o su para escalar temporalmente a root.
Esta jerarquía de permisos es la que hace que Linux sea robusto y relativamente seguro “de fábrica”: la idea es que solo unas pocas acciones puntuales requieran privilegios de administración y que el resto del tiempo estés trabajando con permisos limitados, reduciendo el impacto de errores y malware.
En muchas distribuciones modernas, especialmente las basadas en Ubuntu, la cuenta root viene bloqueada para iniciar sesión directa. Sigues teniendo un superusuario interno, pero accedes a sus privilegios usando sudo desde tu usuario habitual, lo que obliga a introducir tu propia contraseña y deja un rastro en los registros del sistema.
Root, sudo y su: diferencias prácticas y cuándo usar cada uno
Para manejar privilegios de administración en Linux tienes tres vías principales: iniciar sesión como root, usar su o usar sudo. Son parecidas en potencia, pero muy distintas en seguridad y en cómo se registran las acciones.
Iniciar sesión directamente como root
En algunos sistemas todavía se permite iniciar sesión como root, ya sea en consola local, por SSH o incluso en el entorno gráfico. Esto supone que absolutamente todo lo que hagas durante esa sesión se ejecuta con privilegios máximos, desde editar configuraciones hasta abrir un navegador.
Este enfoque es muy cómodo, pero extremadamente peligroso por varias razones: cualquier error tipográfico puede destrozar el sistema, cualquier software malicioso que se ejecute tendrá carta blanca, y además en los registros todo aparecerá como ejecutado por “root” sin poder atribuir acciones a personas concretas.
Por eso muchas distros, como Ubuntu, optan por dejar root sin contraseña (bloqueado) y empujarte a usar sudo. En servidores serios suele desaconsejarse por completo el login directo como root, sobre todo por SSH, ya que es el objetivo favorito de ataques de fuerza bruta automatizados.
El comando su: cambiar a otro usuario o a root
El comando su permite cambiar de identidad de usuario dentro de la misma sesión. Sin argumentos, intenta cambiar a root; con un nombre de usuario, cambia a esa cuenta. En ambos casos se pide la contraseña del usuario de destino.
Conviene usar la forma su – o su –login para cargar también el entorno del nuevo usuario (PATH, variables, directorio home, etc.). Si no lo haces, te mantendrás en el entorno del usuario original y puedes acabar con rutas o permisos incoherentes que lleven a errores extraños.
Cuando usas su para saltar a root, obtienes una shell completa como superusuario hasta que ejecutes exit. Es útil si vas a realizar varias tareas administrativas seguidas y no quieres anteponer sudo a cada comando, pero aumenta el riesgo de despistes y dificulta atribuir acciones concretas a personas si varias comparten la contraseña de root.
El comando sudo: ejecutar acciones puntuales como root
El comando sudo está pensado como método controlado y auditable para ejecutar órdenes con privilegios elevados. Por defecto ejecuta el comando solicitado como root, aunque también puede hacerlo como otro usuario (sudo -u nombre comando).
A diferencia de su, sudo te pide la contraseña de tu usuario, no la de root. Además, solo quienes están autorizados en /etc/sudoers (o en grupos como sudo o wheel) pueden usarlo, y cada uso queda registrado en los logs de autenticación con quién, qué y cuándo.
La forma habitual de trabajo en sistemas modernos consiste en mantener root bloqueado para login y usar sudo para todo lo que requiera privilegios. Puedes ejecutar un único comando (sudo apt install paquete), obtener una shell temporal (sudo -i o sudo su -) o delegar órdenes concretas sin pedir contraseña con directivas NOPASSWD en sudoers.
Riesgos reales de usar root sin precaución
Trabajar como root no es solo “tener cuidado con no borrar nada raro”. Hay riesgos muy concretos y habituales que conviene tener interiorizados si no quieres cargarte el sistema o dejar la puerta abierta a un atacante.
Eliminación de archivos críticos y sistemas inarrancables
El ejemplo típico, pero tristemente real, es ejecutar algo como rm -rf / o rm -rf /* con privilegios de root. En cuestión de segundos puedes borrar el sistema de archivos entero y dejar la máquina inutilizable, obligando a reinstalar y, con suerte, recuperar datos desde copias de seguridad. Para evitarlo, consulta recursos sobre prevención de errores de software.
El problema no siempre es tan evidente: un espacio mal puesto, una variable vacía o una ruta equivocada (por ejemplo, rm -rf «$directorio»/* cuando $directorio está vacío) pueden convertir un comando aparentemente inocente en una catástrofe. Como root, el sistema no te pondrá trabas: si la orden es válida, la ejecutará a rajatabla.
Además, los borrados hechos por root no suelen pasar por ninguna papelera ni sistema de recuperación sencillo. Recuperar datos implica técnicas forenses y no siempre es posible. Por eso se insiste tanto en revisar dos veces cada comando antes de lanzarlo con sudo.
Instalación y persistencia de malware con privilegios máximos
Si descargas y ejecutas scripts o binarios de fuentes poco fiables como root, básicamente estás regalando el control total de tu máquina. Un atacante puede instalar rootkits, backdoors, keyloggers, modificar el kernel, alterar configuraciones críticas o unirse a botnets sin que el sistema pueda ponerle límites de permisos.
En cambio, si ese mismo código se ejecuta como un usuario normal sin privilegios, sus posibilidades de dañar el sistema son menores: puede acceder a tus datos personales y a los directorios a los que tenga permiso, pero no debería poder reescribir /etc/passwd, /boot, el gestor de arranque o los binarios del sistema sin algún fallo adicional de seguridad.
Por eso uno de los mandamientos de seguridad en Linux es no ejecutar jamás como root algo que no has revisado o que no provenga de repositorios oficiales o fuentes muy reputadas. En caso de duda, mejor probar primero en una máquina virtual o contenedor aislado que lamentar luego.
Superficie de ataque mayor y cuentas root en el punto de mira
Cuando activas el login directo de root, especialmente por SSH, añades un objetivo clarísimo para los atacantes. Los bots de Internet pasan el día forzando contraseñas de usuarios “root” o “admin” en servidores expuestos con listas interminables de claves débiles.
Si además la contraseña de root es simple o se reutiliza en varios sistemas, las probabilidades de que alguien acabe entrando suben como la espuma. Una vez dentro con UID 0, no hay más barreras: puede cifrar datos, robar información, plantar puertas traseras o pivotar a otras máquinas de la red.
De ahí que sea práctica estándar en seguridad deshabilitar el login de root por SSH (PermitRootLogin no), usar claves en lugar de contraseñas y limitar al máximo qué usuarios pueden escalar con sudo. Cuanto menos visible esté la cuenta root, menos atractivo es tu sistema para escaneos automatizados.
Falta de trazabilidad y problemas de auditoría
Otro aspecto crítico que se suele pasar por alto es que trabajar directamente como root borra la línea entre quién hace qué. En los logs verás comandos ejecutados por root, pero no sabrás qué administrador o qué sesión concreta estuvo detrás.
Con sudo, sin embargo, cada ejecución queda registrada con el usuario real, la fecha, la hora y la orden utilizada (en /var/log/auth.log o en el journal). Esto no solo ayuda a investigar incidentes, sino que en entornos regulados es un requisito para cumplir normas como ISO 27001 o PCI DSS.
Si hay más de un administrador en el sistema, la trazabilidad es fundamental para asignar responsabilidades y entender qué cambio provocó un problema. Por eso muchos equipos prohíben directamente el uso de root en sesión y obligan a pasar siempre por sudo.
Implicaciones de privacidad: root frente a usuario normal
En una máquina personal de un solo usuario puede parecer que, desde el punto de vista de la privacidad, da igual ejecutar un programa como root o como tu usuario, porque en ambos casos puede leer tus documentos, fotos o correos.
Sin embargo, incluso en ese escenario hay matices importantes: un proceso que corre como tu usuario solo debería poder acceder a tus archivos y a lo que tengas montado a tu nombre. Si guardas datos especialmente sensibles en otra cuenta, en discos cifrados o protegidos con MAC (SELinux, AppArmor, etc.), ese programa no debería llegar tan lejos.
En cambio, si le das privilegios de root le estás abriendo la puerta a todo el sistema: otros usuarios, servicios, claves SSH, archivos de sistema, logs con trazas de actividad, etc. Además puede instalar keyloggers a nivel de kernel, modificar módulos, interceptar tráfico y ocultarse en capas donde las herramientas comunes de usuario no miran.
Desde la óptica de descubrir y limpiar infecciones, también es mucho más difícil detectar y erradicar malware que se haya instalado con acceso root. Puede engancharse al proceso de arranque, camuflarse en el propio kernel y sobrevivir a reinstalaciones parciales del sistema, mientras que el malware a nivel de usuario suele limitarse a tu home y desinstalarse al borrar el perfil o reinstalar limpio.
Formas seguras de acceder a privilegios de root
Según la distribución y tu modelo de uso, puedes elegir entre bloquear root y vivir solo con sudo, o habilitar root y limitar los privilegios del resto. Lo importante es que la decisión sea consciente y esté bien configurada.
Habilitar y usar la cuenta root con contraseña
En sistemas como Ubuntu, la cuenta root suele estar bloqueada tras la instalación. Para asignarle una contraseña y poder usar su, basta con ejecutar en una terminal:
sudo passwd root
El sistema te pedirá tu contraseña de usuario (para sudo) y después te solicitará dos veces la nueva contraseña de root. A partir de ahí, podrás hacer su – para iniciar una shell de superusuario o autenticarse como root en prompts gráficos que lo soporten.
Eso sí, mientras no cambies nada más, tu usuario seguirá pudiendo usar sudo como antes. Si lo que quieres es que solo root pueda realizar tareas administrativas, tendrás que ajustar los grupos y el archivo /etc/sudoers para quitar a tu usuario del grupo sudo o wheel.
Bloquear root y delegar todo en sudo
Si prefieres el modelo más habitual hoy en día, puedes bloquear el uso de root para que no sea posible iniciar sesión con esa cuenta y trabajar siempre con tu usuario estándar más sudo. En muchas distros esto ya viene así, pero si no, puedes hacerlo con:
sudo passwd -dl root
Antes de dar este paso, asegúrate de que tu usuario pertenece al grupo sudo (o wheel, según la distro) o aparece en /etc/sudoers, de forma que puedas seguir realizando tareas administrativas con sudo sin quedarte bloqueado.
De este modo, cualquier acción privilegiada pasará necesariamente por sudo o por prompts de PolicyKit, lo que implica pedir tu contraseña de usuario y dejar un registro. A efectos de seguridad y auditoría, es la opción más recomendable para la mayoría.
Configurar /etc/sudoers y delegación fina de privilegios
El archivo /etc/sudoers controla quién puede usar sudo, con qué comandos, como qué usuario y si debe introducir contraseña. Nunca debe editarse con un editor normal; lo correcto es usar visudo, que valida la sintaxis antes de guardar:
sudo visudo
Dentro puedes definir reglas generales como permitir a cualquier miembro del grupo sudo ejecutar cualquier comando como root:
%sudo ALL=(ALL:ALL) ALL
O afinar más la cosa mediante alias de usuarios y comandos, y etiquetas como NOPASSWD para permitir ciertas órdenes sin pedir contraseña. Un ejemplo típico es autorizar a un usuario concreto a apagar o reiniciar sin clave:
miusuario ALL=NOPASSWD: /sbin/shutdown, /sbin/reboot
Bien trabajado, sudoers te permite aplicar de verdad el principio de privilegio mínimo: cada usuario solo puede ejecutar lo que necesita, durante el tiempo estrictamente necesario, y siempre dejando huella en los registros.
Gestión de contraseñas en Linux: usuario y root
La seguridad de la cuenta root depende en gran medida de utilizar contraseñas robustas y gestionarlas correctamente. Linux ofrece varias formas de cambiarlas, tanto para tu usuario como para otras cuentas.
Cambiar tu propia contraseña
Para modificar la contraseña del usuario con el que has iniciado sesión, solo necesitas ejecutar en la terminal:
passwd
El sistema te pedirá primero la contraseña actual y después que introduzcas la nueva dos veces. Aunque no veas caracteres en pantalla mientras escribes, la contraseña se está registrando; es normal que quede “en blanco” por seguridad.
Si te equivocas con la clave antigua o las dos nuevas no coinciden, verás mensajes del estilo Incorrect password o similar, y tendrás que repetir el proceso.
Cambiar la contraseña de otro usuario o de root con sudo
Si tienes permisos administrativos, puedes cambiar la contraseña de cualquier cuenta sin conocer la actual. Desde un usuario con sudo:
sudo passwd nombre_usuario
o, para root específicamente:
sudo passwd root
En entornos multiusuario, esto es muy útil para restablecer el acceso a usuarios que han olvidado la contraseña o han dejado la empresa. También puedes forzar que un usuario cambie su clave en el siguiente inicio de sesión con:
sudo chage -d 0 nombre_usuario
Estas operaciones quedan registradas en /var/log/auth.log o en journalctl, donde también aparecen los cambios de contraseña, accesos SSH y otros eventos de autenticación relevantes.
Recuperar o resetear la contraseña de root si la olvidas
Si pierdes la contraseña de root y no tienes ningún usuario con sudo, aún puedes recuperarla usando el GRUB en modo recuperación o arrancando con un LiveCD, siempre que tengas acceso físico al equipo.
En el modo recuperación del GRUB, eliges la entrada correspondiente, montas el sistema de archivos con permisos de escritura y ejecutas passwd root para asignar una nueva clave. Algo similar puede hacerse arrancando un LiveCD, montando la partición del sistema y usando chroot para operar como si estuvieras dentro de la instalación original.
Este tipo de recuperación ilustra bien por qué el acceso físico es prácticamente acceso total a cualquier máquina si no se usan medidas adicionales como cifrado de disco completo o protección de arranque.
Buenas prácticas para usar root sin jugarte el sistema
Una vez entendido el poder de root, la clave está en reducir al mínimo el tiempo y el alcance de los privilegios elevados. No se trata de demonizar el superusuario, sino de tratarlo como una herramienta quirúrgica, no como el modo normal de trabajo.
Minimizar el tiempo con privilegios elevados
Aplica siempre el principio de mínimo privilegio: solo eleva permisos cuando sea estrictamente necesario, durante el menor tiempo posible. Para la mayoría de tareas basta con anteponer sudo a comandos concretos.
Evita mantener shells persistentes de root abiertas durante horas, sobre todo en escritorios donde puedes acabar abriendo navegadores, clientes de correo o documentos desde esa sesión sin darte cuenta. Termina la shell de root con exit tan pronto acabes la tarea de administración.
Y, por supuesto, nunca navegues por Internet ni abras adjuntos de correo mientras estés logueado como root. Cualquier exploit o script malicioso aprovecharía ese contexto privilegiado para tomar el control completo del sistema.
No ejecutar scripts de procedencia dudosa como root
Pocas cosas son tan peligrosas como hacer un curl URL | sudo bash sin revisar lo que estás ejecutando. Aunque esté de moda en documentación informal, es una receta perfecta para que un tercero haga lo que quiera con tu máquina.
Siempre que descargues un script o binario de Internet, ábrelo primero con un editor de texto y revisa lo que hace. Si no entiendes el código, no lo ejecutes con privilegios elevados. Y en la medida de lo posible, instala software desde los repositorios oficiales de tu distribución o fuentes reputadas como proyectos activos en Git.
Cuando el desarrollador ofrezca sumas de verificación (SHA256, etc.), compruébalas para asegurarte de que el archivo no ha sido manipulado. Y si tienes dudas, prueba el script primero en una máquina virtual o contenedor que puedas destruir sin consecuencias.
Seguridad adicional: SSH, políticas y monitorización
En servidores y equipos expuestos a red, conviene ir un paso más allá y endurecer el acceso a root y a sudo con varias medidas combinadas:
- Deshabilitar el login directo de root por SSH (PermitRootLogin no o como mínimo prohibit-password).
- Usar autenticación por clave SSH en lugar de contraseñas simples, y proteger la clave con passphrase.
- Limitar intentos de login y cambiar el puerto por defecto para reducir ataques automatizados.
- Monitorizar los logs de autenticación (auth.log, journalctl -xe) y configurar alertas ante usos sospechosos de sudo o intentos de fuerza bruta.
Si a esto sumas contraseñas fuertes, políticas de caducidad razonables y, cuando haga falta, controles adicionales como SELinux o AppArmor, tendrás un entorno donde usar root deja de ser una bomba de relojería para convertirse en una herramienta potente pero controlada.
En definitiva, entender bien qué puede y qué no puede hacer el superusuario, apoyarte siempre que puedas en sudo y en la segmentación de permisos, y extremar las precauciones al ejecutar código de terceros, son las claves para aprovechar la flexibilidad de Linux sin convertir la gestión de root en un riesgo constante para tu sistema, tus datos y tu privacidad.
