Cómo crear usuarios y otorgar permisos sudo en Linux

useradd o adduser: qué comando usar

Antes de repartir privilegios hay que crear la cuenta. Esta guía asume que ya sabés qué es un usuario y un grupo en Linux —para eso está la guía de gestión de usuarios y grupos en Linux— y se concentra en crear la cuenta con criterio y en delegar privilegios de forma controlada.

useradd es el comando de bajo nivel del paquete shadow-utils, presente en cualquier distribución: Debian, Ubuntu, RHEL, Fedora, Arch. Es no interactivo: sin -m no crea el directorio personal, sin -s no asigna un intérprete de comandos, y la cuenta queda sin contraseña utilizable hasta correr passwd aparte.

adduser es un script de más alto nivel, interactivo, específico de Debian y Ubuntu —no existe en RHEL ni en Fedora—. Llama a useradd por dentro, pero además crea el directorio personal, copia las plantillas de /etc/skel y pide la contraseña durante el propio proceso.

# Bajo nivel, disponible en cualquier distribución
sudo useradd -m -d /home/laura -s /bin/bash laura
sudo passwd laura

# Alto nivel, interactivo, solo Debian y Ubuntu
sudo adduser laura

Esta parte retoma un aporte real de la comunidad: en el hilo «[SOLUCIONADO] Añadir usuario normal -no root- a Kali» del foro de Underc0de, Kodeinfect mostró la sintaxis de useradd con -g, -d, -m y -s seguida de passwd, y k133 aportó adduser como alternativa. Ese mismo hilo sugería después agregar al usuario en las líneas de /etc/sudoers a mano; en la próxima sección vas a ver por qué esa parte del consejo ya no es la práctica recomendada.

Cómo se concede sudo según la distribución

Crear la cuenta no le da privilegios de administrador. Para eso hace falta sumarla a un grupo administrativo, y el nombre de ese grupo es la fuente número uno de confusión entre distribuciones.

En Debian y Ubuntu ese grupo se llama sudo; en RHEL, Fedora, CentOS y Arch Linux se llama wheel. /etc/sudoers ya trae de fábrica una regla que autoriza a cualquier miembro de ese grupo, con sintaxis del estilo %wheel ALL=(ALL) ALL —el % marca que lo que sigue es un grupo, según sudoers(5)—. Sumar al usuario alcanza: no hace falta escribir una regla nueva.

El comando es usermod -aG grupo usuario. La opción -a («append») es la que casi siempre se olvida: sin ella, usermod -G reemplaza toda la lista de grupos secundarios en vez de sumarle uno, y podés terminar sacando al usuario de otros grupos a los que ya pertenecía.

Por qué /etc/sudoers se edita solo con visudo

/etc/sudoers define quién puede ejecutar qué, como qué usuario y en qué máquina. Nunca se abre con un editor común —ni nano ni vim—: se edita exclusivamente con visudo.

sudo visudo

La razón es concreta: según su propia página de manual, visudo bloquea el archivo contra ediciones simultáneas y, antes de guardar, valida la sintaxis completa. Si hay un error, no guarda los cambios y devuelve al editor con el número de línea del problema. Un editor común no hace nada de eso: guarda lo que sea, error de tipeo incluido, y el próximo sudo de cualquier usuario puede fallar de inmediato porque el archivo quedó roto.

Acá vale la pena señalar el aporte de la comunidad mencionado más arriba: en el hilo de Kodeinfect y k133, la recomendación que circuló fue «añadirlo a las líneas de /etc/sudoers», sin mencionar visudo. Funciona mientras no haya errores de tipeo, pero es justo la práctica que esta guía corrige: cualquier edición de /etc/sudoers pasa por visudo. Si además la cuenta root está bloqueada —el caso por defecto en Ubuntu, como se ve más abajo—, un archivo roto deja la máquina sin ninguna vía normal de escalar privilegios sin arrancar en modo de rescate.

/etc/sudoers.d/: reglas en fragmentos, no en el archivo principal

Más allá de usar visudo, la práctica recomendada es no tocar directamente /etc/sudoers, sino agregar las reglas propias en archivos separados dentro de /etc/sudoers.d/. El archivo principal ya incluye ese directorio con una directiva como @includedir /etc/sudoers.d (o su forma heredada #includedir).

Al llegar a esa línea, sudo procesa cada archivo del directorio en orden alfabético y, según documenta sudoers(5), omite los que terminan en ~ o contienen un punto en el nombre, para no toparse con archivos temporales de un editor o de un gestor de paquetes. Por eso conviene nombrar los fragmentos sin extensión y, si van a ser varios, con un prefijo numérico de ancho fijo (01-, 02-), porque el orden es alfabético y no numérico: 1_algo se procesaría después de 10_otro.

sudo visudo -f /etc/sudoers.d/laura-despliegues

visudo no edita automáticamente los archivos de sudoers.d salvo que detecte un error en ellos, pero se les puede apuntar con -f, que conserva la misma validación. La ventaja: cada regla queda aislada en su propio archivo, fácil de identificar y de revertir, y un error de sintaxis en un fragmento nuevo no pone en riesgo el archivo principal.

Mínimo privilegio: delegar comandos concretos, no ALL

El error de fondo más caro no es de sintaxis: es de diseño. Dar ALL=(ALL:ALL) ALL a alguien que solo necesita reiniciar un servicio significa que esa cuenta puede ejecutar cualquier comando, como cualquier usuario, en cualquier máquina. Es root entero, con un paso extra.

El principio de mínimo privilegio dice lo contrario: dar a cada cuenta solo lo que necesita para su tarea, delegando el comando concreto que requiere.

# Mínimo privilegio: solo puede reiniciar y consultar el estado de nginx
laura ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx

# Evitar salvo que la persona sea, de hecho, administradora total del sistema
laura ALL=(ALL:ALL) ALL

Pero acotar el comando no alcanza si ese comando, a su vez, permite hacer cualquier otra cosa. Delegar un binario que abre un editor de texto, invoca un intérprete o permite escribir un archivo arbitrario equivale, en la práctica, a delegar root completo: quien lo ejecuta puede usar esa función para escapar del comando delegado. El criterio no es solo «¿qué comando delego?», sino «¿ese comando, corriendo como root, puede tocar algo que no debería?».

NOPASSWD es otra palanca del mismo tipo: elimina el pedido de contraseña al ejecutar el comando delegado. Usarla sobre ALL (laura ALL=(ALL) NOPASSWD: ALL) anula el control de quién hizo qué. Si hace falta una excepción sin contraseña, tiene que acotarse al comando puntual, nunca a ALL.

Esto no es un riesgo teórico: en julio de 2025 circuló en el foro de Underc0de una noticia sobre una falla crítica de sudo que permitía tomar el control del sistema. No hace falta conocer su mecanismo exacto para sacar la conclusión general: cuanta menos superficie tenga la configuración de sudoers de cada usuario, menos terreno le queda a cualquier vulnerabilidad futura en la propia herramienta.

su, sudo y sudo -i: qué elegir y por qué

Con la cuenta creada y sudo configurado, queda la pregunta de cómo usarlo en el día a día. Hay tres formas de acceder a privilegios de administrador, y no son intercambiables.

su («substitute user») cambia de usuario en la misma sesión y pide la contraseña del usuario destino —si se ejecuta a secas, la de root—. sudo comando ejecuta un único comando con privilegios elevados, pidiendo tu propia contraseña y volviendo enseguida al usuario normal: es la forma recomendada para la mayoría de las tareas puntuales. sudo -i (equivalente a sudo su -) abre una shell completa como root, con su entorno incluido, hasta que se cierra explícitamente; conviene reservarla para bloques de varias tareas seguidas, no como hábito diario.

En Ubuntu, la cuenta root queda bloqueada tras la instalación —sin contraseña utilizable, justamente para empujar a usar sudo—, así que su a secas no funciona hasta habilitarla con sudo passwd root, algo que la propia documentación de Ubuntu describe como «rara vez necesario». La forma prevista de simular una sesión de root es sudo -i, no reactivar la cuenta.

Errores frecuentes

• Olvidar -m en useradd. La cuenta queda sin directorio personal y da errores raros en el primer login.
• Olvidar -a en usermod -aG. Reemplaza toda la lista de grupos secundarios, y puede sacar al usuario del grupo sudo que ya tenía.
• Editar /etc/sudoers con un editor común. Sin la validación de visudo, un error de tipeo puede dejar el sistema sin sudo funcional.
• Delegar ALL=(ALL:ALL) ALL cuando bastaba un comando puntual. Rompe el mínimo privilegio y equivale a entregar root completo.
• Usar NOPASSWD: ALL sin necesidad real. Elimina el control de confirmación y de trazabilidad de quién ejecutó qué.
• Cerrar la sesión original antes de confirmar el sudo nuevo. Si algo falló, te quedás sin ninguna vía para corregirlo.
• Confundir su, sudo y sudo -i. Cada uno pide una contraseña y tiene un alcance distinto; usarlos sin criterio genera hábitos inseguros.

Preguntas frecuentes

Fuentes

Aportes de la comunidad y documentación oficial consultados para esta guía. Fecha de consulta: 29 de julio de 2026.

Aportes de la comunidad Underc0de

1. Underc0de, foro. [SOLUCIONADO] Añadir usuario normal -no root- a Kali, por aldobelus, con respuestas de Kodeinfect y k133, sección Dudas y pedidos generales. Origen de la sintaxis de useradd y adduser de esta guía; sugería editar /etc/sudoers sin visudo, práctica que se actualiza acá.
2. Underc0de, foro. Ejecutar sin privilegios desde usuario root. Kali Linux, por kilopia, con respuesta de grep, sección Dudas y pedidos generales. Argumento de fondo sobre por qué trabajar como root expone el sistema.
3. Underc0de, foro. Falla crítica de sudo en Linux permite tomar el control del sistema, por AXCESS, sección Noticias informáticas. Contexto de que existen fallas reales en sudo, sin detallar su mecanismo, para argumentar por qué conviene minimizar privilegios.

Documentación oficial

4. man7.org. useradd(8). Sintaxis y opciones del comando de bajo nivel.
5. man7.org. usermod(8). Comportamiento de -aG para sumar a un grupo sin quitar los demás.
6. man7.org. sudoers(5). Sintaxis de reglas por grupo, NOPASSWD y la directiva @includedir.
7. man7.org. visudo(8). Bloqueo del archivo y validación de sintaxis antes de guardar.
8. Ubuntu Community Help Wiki. RootSudo. Por qué root viene bloqueada por defecto y cómo simular una sesión con sudo -i.
9. Fedora Docs. Adding Users and Managing the wheel Group. Referencia oficial del grupo wheel en la familia RHEL/Fedora.
10. Sudo Project. History. Origen y evolución de la herramienta sudo.