# Cómo crear usuarios y otorgar permisos sudo en Linux

**Categoría:** Linux y sistemas · **Nivel:** Inicial · **Lectura:** 14 min
**Publicada:** 2026-07-29 · **Actualizada:** 2026-07-29 · **Autoría:** Underc0de, con aporte original de Kodeinfect y k133
**Versión HTML (canónica):** https://underc0de.org/guias/linux/crear-usuarios-y-otorgar-permisos-sudo-en-linux/

La diferencia entre useradd y adduser, cómo se concede sudo según la distribución, por qué sudoers se edita con visudo y nunca a mano, y cómo delegar solo lo necesario.

## Respuesta rápida

> Crear la cuenta y darle privilegios de administrador son dos pasos distintos. Para crear la cuenta, `useradd` es el comando de bajo nivel presente en cualquier distribución, pero no crea el directorio personal ni pide datos por defecto; `adduser` es un script interactivo, específico de Debian y Ubuntu, que sí lo hace y que no existe en RHEL ni en Fedora. Para delegar privilegios se suma la cuenta al grupo administrativo —`sudo` en Debian/Ubuntu, `wheel` en RHEL/Fedora/Arch— y las reglas se definen en `/etc/sudoers`, un archivo que se edita **solo** con `visudo` porque valida la sintaxis antes de guardar. La regla de oro: delegar lo mínimo necesario, nunca `ALL=(ALL:ALL) ALL` sin pensarlo dos veces.

## 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](../gestion-de-usuarios-y-grupos-en-linux/index.md)— 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.

```bash
# 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
```

| Aspecto | `useradd` | `adduser` |
|---|---|---|
| Nivel | Bajo nivel, paquete shadow-utils | Alto nivel, script que llama a useradd |
| Disponibilidad | Cualquier distribución | Debian y Ubuntu (no existe en RHEL/Fedora) |
| Interacción | No interactivo: hay que pasar todas las opciones | Interactivo: pregunta paso a paso |
| Directorio personal | Requiere `-m` explícito | Lo crea automáticamente, con `/etc/skel` |
| Contraseña | Hay que correr `passwd` aparte | La pide durante el propio proceso |
| Uso típico | Scripts y automatización | Uso manual cotidiano |

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

![Diagrama de cuatro bloques a la izquierda que compara root, el riesgo de trabajar como root, el usuario normal y sudo, y un panel a la derecha con el principio de mínimo privilegio. El primer bloque, root, indica que es el administrador con poder total: lee y modifica todo, instala software y gestiona usuarios. El segundo bloque advierte que trabajar todo el tiempo como root es peligroso porque cualquier error o programa malicioso se ejecuta sin ninguna red de seguridad. El tercer bloque, usuario normal, indica permisos acotados: trabaja libre dentro de su propio directorio personal pero no toca el sistema. El cuarto bloque, sudo, lo describe como el puente: eleva privilegios solo para un comando puntual, pide la contraseña propia del usuario y deja registro de la acción. A la derecha, el panel de mínimo privilegio resume tres ideas: trabajar como usuario normal en el día a día, usar sudo solo puntualmente para lo que de verdad lo requiere, y que el permiso de usar sudo se otorga por pertenencia a un grupo administrativo, llamado sudo o wheel según la distribución. Al pie, una línea remarca que la forma correcta de administrar no es iniciar sesión como root sino usar sudo cuando hace falta.](../../assets/img/guias/usuarios-root-sudo.svg)

*root tiene poder total y el usuario normal, permisos acotados; sudo es el puente controlado entre ambos, y el acceso se concede sumando la cuenta al grupo administrativo —sudo o wheel, 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.

| Familia de distribución | Grupo administrativo | Comando para sumar al usuario |
|---|---|---|
| Debian, Ubuntu | `sudo` | `usermod -aG sudo usuario` |
| RHEL, Fedora, CentOS | `wheel` | `usermod -aG wheel usuario` |
| Arch Linux | `wheel` | `usermod -aG wheel usuario` |

> **Probá el acceso en una segunda sesión, sin cerrar la actual.** La pertenencia a un grupo nuevo **no tiene efecto hasta el próximo inicio de sesión**: si laura ya tenía una terminal abierta, esa sesión no lo va a ver. Abrí una **segunda sesión** con esa cuenta y confirmá que `sudo -l` funciona, **sin cerrar** la sesión original con la que hiciste el cambio. Si algo salió mal, seguís teniendo una vía con privilegios para corregirlo.

## 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`.

```bash
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`.

```bash
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.

```bash
# 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.

| Comando | Qué hace | Contraseña que pide | Cuándo usarlo |
|---|---|---|---|
| `su` | Cambia de usuario en la sesión actual | La del usuario destino | Solo si esa cuenta tiene contraseña habilitada |
| `sudo comando` | Ejecuta un comando puntual como root | La propia del usuario | La mayoría de las tareas administrativas |
| `sudo -i` / `sudo su -` | Abre una shell de login completa como root | La propia del usuario | Bloques largos de tareas seguidas |

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

**¿Cuál es la diferencia real entre useradd y adduser y cuál uso según mi distribución?**
useradd es el comando de bajo nivel del paquete shadow-utils, presente en cualquier distribución. Es no interactivo: si no se le indica -m no crea el directorio personal, y hay que correr passwd aparte. adduser es un script de más alto nivel, interactivo, específico de Debian y Ubuntu, que llama a useradd por dentro pero además crea el directorio personal, copia /etc/skel y pide la contraseña durante el proceso; no existe en RHEL ni en Fedora. En Debian o Ubuntu, trabajando a mano, adduser es más cómodo; en RHEL/Fedora o en un script portable, la opción es useradd.

**¿Cómo le doy sudo a un usuario nuevo en Debian/Ubuntu y en RHEL/Fedora?**
El permiso para usar sudo se concede sumando la cuenta a un grupo administrativo: sudo en Debian y Ubuntu, wheel en RHEL, Fedora, CentOS y Arch Linux. /etc/sudoers ya trae de fábrica una regla que autoriza a ese grupo, con sintaxis del estilo %wheel ALL=(ALL) ALL, documentada en sudoers(5). El comando es usermod -aG grupo usuario, por ejemplo usermod -aG sudo laura o usermod -aG wheel laura. La opción -a es imprescindible: sin ella, usermod reemplaza toda la lista de grupos secundarios en vez de sumarle uno, y puede sacar al usuario de otros grupos a los que ya pertenecía. El cambio no tiene efecto hasta el próximo inicio de sesión, así que conviene probarlo en una sesión nueva antes de dar el trámite por terminado.

**¿Por qué nunca hay que editar /etc/sudoers con un editor común?**
/etc/sudoers define quién puede ejecutar qué comandos, como qué usuario y en qué máquina, y su sintaxis es estricta. visudo es la única herramienta pensada para editarlo: bloquea el archivo contra ediciones simultáneas y valida la sintaxis antes de guardar, según su propia página de manual. Si detecta un error, no guarda nada y devuelve al editor con el número de línea. Un editor común, como nano o vim, salta ese control: un error de tipeo puede dejar el archivo roto, y nadie puede volver a usar sudo. Si además la cuenta root está bloqueada, como en Ubuntu por defecto, ese error deja la máquina sin ninguna vía normal de recuperar privilegios sin un modo de rescate.

**¿Qué es /etc/sudoers.d/ y cuándo conviene usarlo?**
/etc/sudoers.d/ es un directorio que /etc/sudoers incluye con una directiva como @includedir /etc/sudoers.d, documentada en sudoers(5). Sudo procesa cada archivo en orden alfabético y omite los que terminan en ~ o contienen un punto, para no toparse con archivos temporales de un editor o gestor de paquetes. La práctica recomendada es no tocar el archivo principal para una regla puntual, sino crear un archivo nuevo dentro de sudoers.d, sin extensión, y editarlo con visudo -f. La ventaja: cada regla queda aislada y fácil de revertir, y un error en un fragmento nuevo no pone en riesgo el archivo principal.

**¿Por qué NOPASSWD: ALL es una mala práctica?**
NOPASSWD es una etiqueta de sudoers que elimina el pedido de contraseña al ejecutar el comando delegado. Usarla junto con ALL, en una línea como usuario ALL=(ALL) NOPASSWD: ALL, anula el control de confirmación y la trazabilidad de quién decidió cada acción, porque cualquier proceso que corra bajo esa sesión puede invocar sudo sin que nadie escriba nada. Combinada con ALL, además abre la puerta a que una sesión comprometida escale a privilegios de administrador sin obstáculo. No hay que evitarla siempre —hay usos legítimos, como un script automatizado nocturno—, pero acotada a un comando puntual y nunca combinada con ALL.

**¿Cómo le quito sudo a un usuario sin borrarlo?**
Quitarle sudo a alguien no requiere borrar la cuenta ni tocar /etc/sudoers si el privilegio se concedió por grupo, el caso más habitual: alcanza con sacarlo del grupo correspondiente. El comando estándar es gpasswd -d usuario grupo, por ejemplo gpasswd -d laura sudo; en Debian y Ubuntu también existe deluser usuario sudo, análoga a adduser. El cambio no afecta las sesiones ya abiertas: solo se aplica en el próximo inicio de sesión, así que para revocar el acceso de inmediato conviene además cerrar sus sesiones activas. Si el privilegio venía de una regla en /etc/sudoers.d/, alcanza con borrarla con visudo -f.

## 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](https://underc0de.org/foro/dudas-generales-121/solucionado-anadir-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](https://underc0de.org/foro/dudas-generales-121/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](https://underc0de.org/foro/noticias-informaticas-120/falla-critica-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)](https://man7.org/linux/man-pages/man8/useradd.8.html). Sintaxis y opciones del comando de bajo nivel.
5. **man7.org.** [usermod(8)](https://man7.org/linux/man-pages/man8/usermod.8.html). Comportamiento de `-aG` para sumar a un grupo sin quitar los demás.
6. **man7.org.** [sudoers(5)](https://man7.org/linux/man-pages/man5/sudoers.5.html). Sintaxis de reglas por grupo, `NOPASSWD` y la directiva `@includedir`.
7. **man7.org.** [visudo(8)](https://man7.org/linux/man-pages/man8/visudo.8.html). Bloqueo del archivo y validación de sintaxis antes de guardar.
8. **Ubuntu Community Help Wiki.** [RootSudo](https://help.ubuntu.com/community/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](https://docs.fedoraproject.org/en-US/quick-docs/adding-users-managing-wheel-group/). Referencia oficial del grupo `wheel` en la familia RHEL/Fedora.
10. **Sudo Project.** [History](https://www.sudo.ws/about/history/). Origen y evolución de la herramienta sudo.

## Origen comunitario

La base de `useradd`/`adduser` retoma y actualiza el aporte de **Kodeinfect** y **k133** en el foro: su sintaxis sigue vigente, pero la sugerencia de tocar `/etc/sudoers` sin `visudo` se corrige en la sección correspondiente. El resto —grupos por distribución, `sudoers.d`, mínimo privilegio y `su` frente a `sudo`— es contenido nuevo, revisado contra la documentación oficial citada arriba.

## Guías relacionadas

- [Gestión de usuarios y grupos en Linux](../gestion-de-usuarios-y-grupos-en-linux/index.md) — qué es un usuario y un grupo, y por qué root y sudo existen.
- [Permisos y propietarios de archivos en Linux](../permisos-y-propietarios-de-archivos-en-linux/index.md) — el modelo de permisos rwx que complementa la gestión de cuentas.
- [Comandos útiles de Linux para el día a día](../comandos-utiles-de-linux/index.md) — el resto de los comandos de uso diario en la terminal.
- [Conexión remota segura con SSH y claves](../conexion-remota-segura-con-ssh-y-claves/index.md) — administrar cuentas también implica asegurar el acceso remoto.
- [Administración de servidores Linux desde cero](../administracion-de-servidores-linux-desde-cero/index.md) — crear cuentas de servicio y repartir privilegios es parte de administrar un servidor real.
- [Índice de guías de Underc0de](../../index.md)

---

Esta guía forma parte de un proyecto de la comunidad Underc0de para organizar conocimiento técnico en español. Fuente canónica: https://underc0de.org/guias/linux/crear-usuarios-y-otorgar-permisos-sudo-en-linux/