Gestionar usuarios y grupos

1. Las piezas de una cuenta

Una cuenta de usuario no es un objeto único. Es un conjunto de anotaciones y de archivos repartidos por el sistema, que conocimos uno por uno en el tema 16. Dar de alta un usuario es crear todas esas piezas de manera coherente:

Nada impediría editar esos archivos a mano, y así se hacía en los primeros Unix. No se hace por dos motivos. Un error de formato en /etc/passwd puede dejar a todos los usuarios sin poder entrar. Y dos administradores editando a la vez se pisarían los cambios; las herramientas bloquean los archivos mientras trabajan.

2. Dos familias de herramientas

Hay dos juegos de comandos para lo mismo, y conviene distinguirlos porque sus nombres se parecen hasta la confusión:

Los segundos son, en realidad, programas que llaman a los primeros con las opciones convenientes. Veremos los dos: adduser porque es lo cómodo en nuestro sistema, y useradd porque es lo que hay en todos y lo que aparece en la documentación.

3. adduser: el alta guiada

Creamos la primera cuenta de prueba. adduser pide una contraseña para el usuario nuevo y algunos datos opcionales, que se pueden dejar vacíos pulsando Enter:

$ sudo adduser luis
info: Adding user `luis' ...
info: Selecting UID/GID from range 1000 to 59999 ...
info: Adding new group `luis' (1001) ...
info: Adding new user `luis' (1001) with group `luis (1001)' ...
info: Creating home directory `/home/luis' ...
info: Copying files from `/etc/skel' ...
New password:
Retype new password:
passwd: password updated successfully
Changing the user information for luis
Enter the new value, or press ENTER for the default
        Full Name []: Luis Pérez
        Room Number []:
        Work Phone []:
        Home Phone []:
        Other []:
Is the information correct? [Y/n] y
info: Adding new user `luis' to supplemental / extra groups `users' ...
info: Adding user `luis' to group `users' ...

La salida es una lista ordenada de todo lo que estudiamos. Eligió el primer UID libre a partir del 1000, que es el 1001, porque el 1000 es de ana. Creó un grupo privado con el mismo nombre y el mismo número. Creó el directorio personal y lo llenó a partir de /etc/skel. Pidió la contraseña, dos veces y sin mostrarla. Y recogió los datos del quinto campo de /etc/passwd.

Lo que no hizo también importa: no lo agregó al grupo sudo. Una cuenta nueva es siempre un usuario sin privilegios.

4. Qué se creó

Comprobamos cada pieza con los comandos del tema 16:

$ getent passwd luis
luis:x:1001:1001:Luis Pérez,,,:/home/luis:/bin/bash
$ id luis
uid=1001(luis) gid=1001(luis) groups=1001(luis),100(users)
$ sudo ls -la /home/luis
total 20
drwxr-x--- 2 luis luis 4096 oct 12 17:40 .
drwxr-xr-x 4 root root 4096 oct 12 17:40 ..
-rw-r--r-- 1 luis luis  220 oct 12 17:40 .bash_logout
-rw-r--r-- 1 luis luis 3771 oct 12 17:40 .bashrc
-rw-r--r-- 1 luis luis  807 oct 12 17:40 .profile

Hizo falta sudo para listar el directorio: sus permisos son rwxr-x---, y ana es «otros» frente a él. La separación entre usuarios funciona desde el primer momento, y en las dos direcciones.

Los tres archivos ocultos no los escribió nadie. Son copias del contenido de un directorio modelo:

/etc/skel, de skeleton, es el directorio cuyo contenido se copia al directorio personal de cada usuario nuevo. Es el «esqueleto» de una cuenta recién creada.

$ ls -A /etc/skel
.bash_logout  .bashrc  .profile

Es el origen del .bashrc de cada usuario, incluido el tuyo, con los alias que vimos en el tema 5. Lo que un administrador coloque en /etc/skel —un archivo de bienvenida, una configuración de la empresa— aparecerá en todas las cuentas que se creen después. Las existentes no cambian: es una copia en el momento del alta, no un vínculo.

5. useradd: el alta explícita

Creamos la segunda cuenta con la herramienta universal, que no pregunta nada y no supone casi nada:

$ sudo useradd -m -s /bin/bash -c "Marta Ruiz" marta
$ id marta
uid=1002(marta) gid=1002(marta) groups=1002(marta)

useradd -m -s /bin/bash -c "Marta Ruiz" marta
        │  │            │               │
        │  │            │               └─ el nombre de la cuenta
        │  │            └─ el comentario: su nombre completo
        │  └─ su shell de inicio
        └─ crear el directorio personal

Sin mensajes: silencio es éxito. Cada opción suple algo que adduser hacía solo, y omitirlas tiene consecuencias que conviene conocer antes de encontrarlas:

Y hay algo que useradd no hace con ninguna opción cómoda: asignar la contraseña. La cuenta nace bloqueada, sin forma de iniciar sesión, hasta que se le pone una.

6. passwd: las contraseñas

El comando passwd cambia contraseñas. Tiene dos usos, según quién lo ejecute:

Con el segundo le damos una contraseña a marta. La opción -S, de status, muestra el estado antes y después:

$ sudo passwd -S marta
marta L 2026-10-12 0 99999 7 -1
$ sudo passwd marta
New password:
Retype new password:
passwd: password updated successfully
$ sudo passwd -S marta
marta P 2026-10-12 0 99999 7 -1

La segunda columna es el estado: L, de locked, bloqueada; P, con contraseña utilizable. Las demás son los valores de vigencia que veremos en la sección siguiente.

La cuarta fila resuelve un problema práctico. Al crear la cuenta de otra persona, el administrador elige una contraseña provisoria, y por un momento la conoce. Con passwd -e, el sistema obliga a reemplazarla en el primer inicio de sesión, y a partir de entonces solo su dueño la sabe.

Un usuario común que cambia su contraseña está sujeto a reglas mínimas de calidad: el sistema rechaza las muy cortas o demasiado parecidas a la anterior. Al administrador solo se le advierte.

7. Los campos de /etc/shadow

En el tema 16 dijimos que las contraseñas viven en /etc/shadow, y dejamos su formato para este tema. Cada línea tiene nueve campos; los seis primeros son los que se usan:

$ sudo getent shadow luis
luis:$y$j9T$…:20738:0:99999:7:::

luis:$y$j9T$…:20738:0:99999:7:::
│    │        │     │ │     │
│    │        │     │ │     └─ días de aviso antes del vencimiento
│    │        │     │ └─ días máximos de validez; 99999: no vence
│    │        │     └─ días mínimos entre un cambio y el siguiente
│    │        └─ fecha del último cambio, en días desde 1970
│    └─ el hash de la contraseña, abreviado aquí
└─ el usuario

El segundo campo no es la contraseña, sino su hash, del que no se puede volver a ella. Su comienzo indica con qué algoritmo se calculó, y hay valores especiales que conviene reconocer:

Las fechas se cuentan en días desde el 1 de enero de 1970; el 20738 corresponde al 12 de octubre de 2026. Para no hacer cuentas, el comando chage, de change age, muestra y modifica la vigencia en forma legible:

$ sudo chage -l luis
Last password change                                    : oct 12, 2026
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

8. Crear grupos y agregar miembros

Un grupo se crea con groupadd, y nace vacío:

$ sudo groupadd proyecto
$ getent group proyecto
proyecto:x:1003:

Recibió el GID 1003, el siguiente libre después de los grupos privados de luis y de marta. Para agregar miembros hay tres comandos equivalentes; el primero es el universal:

$ sudo usermod -aG proyecto luis
$ sudo usermod -aG proyecto marta
$ getent group proyecto
proyecto:x:1003:luis,marta
$ id luis
uid=1001(luis) gid=1001(luis) groups=1001(luis),100(users),1003(proyecto)

Para quitar a alguien de un grupo, y para borrar un grupo:

Vale aquí la advertencia del tema 16: la membresía se lee al iniciar sesión. Si luis estuviera conectado, seguiría sin pertenecer a proyecto hasta salir y volver a entrar.

9. La trampa de la -a

La opción -G de usermod no agrega un grupo: establece la lista completa de grupos secundarios. Es la -a, de append, la que cambia ese comportamiento por «añadir a los que ya tiene».

10. usermod: modificar una cuenta

usermod cambia cualquier dato de una cuenta existente. Sus opciones son, en su mayoría, las mismas de useradd:

Dos de esos datos los puede cambiar cada usuario para sí mismo, sin privilegios, con comandos propios: chsh cambia la shell, como vimos en el tema 2, y chfn, el nombre completo y los datos de contacto.

La cuarta fila ilustra otra vez la independencia entre nombres y números. Renombrar una cuenta modifica una línea de /etc/passwd; los archivos, que llevan anotado el UID, no se enteran. El directorio personal conserva su nombre anterior salvo que se lo cambie con -d y -m.

11. Un directorio para un equipo

El propósito habitual de crear un grupo es darle a un equipo un lugar común de trabajo. Lo armamos con las herramientas del tema 18, en /srv, el directorio para datos que el equipo ofrece a otros:

$ sudo mkdir /srv/proyecto
$ sudo chgrp proyecto /srv/proyecto
$ sudo chmod 770 /srv/proyecto
$ ls -ld /srv/proyecto
drwxrwx--- 2 root proyecto 4096 oct 12 17:55 /srv/proyecto

Leído con el algoritmo del tema 17: los miembros de proyecto pueden entrar, listar, crear y borrar; todos los demás, nada. Lo probamos actuando como cada usuario, con sudo -u:

$ sudo -u luis touch /srv/proyecto/plan.txt       # luis, miembro: puede crear
$ sudo -u marta ls -l /srv/proyecto               # marta, miembro: puede listar
total 0
-rw-r--r-- 1 luis luis 0 oct 12 17:56 plan.txt
$ ls /srv/proyecto                                # ana no es miembro
ls: cannot open directory '/srv/proyecto': Permission denied

El directorio funciona como se esperaba. Pero el listado delata un problema: el archivo que creó luis pertenece al grupo luis, su grupo primario, y no a proyecto. Para marta es un archivo ajeno, sobre el que tiene solo los permisos de «otros»: puede leerlo y no modificarlo. Un directorio compartido donde cada quien solo puede editar lo suyo no sirve para trabajar en equipo.

La solución no es pedir a cada usuario que ejecute chgrp después de crear cada archivo. Hay un permiso especial que hace que todo lo creado en un directorio herede su grupo. Es el tema 21, y allí terminaremos este ejemplo.

12. Dar y quitar el privilegio de administrar

Según el tema 19, en Ubuntu es administrador quien pertenece al grupo sudo. Convertir una cuenta común en administradora, y revertirlo, son dos operaciones de grupo:

$ sudo usermod -aG sudo marta                    # marta pasa a ser administradora
$ sudo -l -U marta
User marta may run the following commands on equipo:
    (ALL : ALL) ALL
$ sudo gpasswd -d marta sudo                     # y deja de serlo
Removing user marta from group sudo
$ sudo -l -U marta
User marta is not allowed to run sudo on equipo.

sudo -l -U usuario muestra los permisos de otro usuario, sin necesidad de iniciar sesión como él. En otras distribuciones el grupo equivalente se llama wheel.

Es la decisión de más peso de todo el tema. Quien pertenece a sudo puede leer los archivos de todos, cambiar cualquier contraseña y borrar el sistema. Se concede a quien administra el equipo, no a quien encuentra un Permission denied; para necesidades puntuales están las reglas limitadas de sudoers.

13. Bloquear una cuenta

Entre una cuenta activa y una borrada hay un estado intermedio muy útil: la cuenta que existe, conserva sus archivos, y no admite ingresos. Es lo que corresponde cuando alguien se ausenta por un tiempo, o apenas deja la organización, antes de decidir qué hacer con sus datos.

$ sudo usermod -L marta
$ sudo passwd -S marta
marta L 2026-10-12 0 99999 7 -1
$ sudo usermod -U marta                          # desbloquear: vuelve a valer la misma contraseña

La primera fila de la tabla esconde un malentendido frecuente. Bloquear la contraseña antepone un ! al hash, y eso inutiliza la contraseña, pero no la cuenta. Para cerrar de verdad el acceso, lo seguro es combinar el bloqueo con el vencimiento. La fecha 1 significa el segundo día de 1970: una cuenta vencida hace más de medio siglo.

Bloquear no interrumpe lo que ya está en marcha. Las sesiones abiertas y los procesos del usuario continúan; para verlos sirve ps -u usuario, y los tratamos en el bloque 7.

14. La baja de una cuenta

Eliminar una cuenta es simple de ejecutar y delicado de decidir, porque sus archivos pueden ser lo único que queda del trabajo de una persona. Antes del comando hay un procedimiento:

1. Bloquear la cuenta, para que nada cambie mientras se trabaja. cerrar
2. Comprobar que no tiene procesos: ps -u usuario. revisar
3. Buscar sus archivos fuera del directorio personal: sudo find / -user usuario 2>/dev/null. revisar
4. Respaldar lo que deba conservarse, con tar, como en el tema 15. respaldar
5. Eliminar la cuenta. borrar
6. Verificar que no quedaron archivos sin dueño. comprobar

Damos de baja nuestras dos cuentas de prueba, cada una con una herramienta:

$ sudo userdel -r marta
userdel: marta mail spool (/var/mail/marta) not found
$ sudo deluser --remove-home luis
info: Looking for files to backup/remove ...
info: Removing files ...
info: Removing crontab ...
info: Removing user `luis' ...
$ ls /home
ana

El aviso de userdel no es un error: informa que no encontró un buzón de correo que borrar. Las cuentas ya no existen. Pero el sexto paso del procedimiento tiene trabajo:

$ sudo ls -l /srv/proyecto
total 0
-rw-r--r-- 1 1001 1001 0 oct 12 17:56 plan.txt
$ sudo find / -nouser 2>/dev/null
/srv/proyecto/plan.txt

Es el archivo huérfano del que hablamos en el tema 16. El archivo que luis creó fuera de su directorio personal sigue ahí, a nombre del UID 1001, que ya no corresponde a nadie; ls muestra el número porque no tiene nombre al que traducirlo.

Terminamos la limpieza. El grupo se puede borrar ahora que no es primario de nadie, y el directorio de prueba, con su archivo, ya no hace falta. Es un rm -r con sudo: se lee la ruta dos veces.

$ sudo groupdel proyecto
$ sudo rm -r /srv/proyecto
$ getent passwd luis marta                       # nada: no existen
$ getent group proyecto                           # nada

El sistema quedó como al empezar. La referencia del tema:

En el tema 21 cerramos el bloque con los tres permisos que quedaron pendientes: el que permite a passwd escribir en un archivo que solo root puede tocar, el que resuelve el directorio compartido de la sección 11, y el que protege a /tmp.

15. Resumen

• Una cuenta consta de líneas en /etc/passwd, /etc/shadow y /etc/group, y de un directorio personal. Se gestiona con herramientas, no editando esos archivos.
• adduser, propio de Debian y Ubuntu, crea una cuenta completa preguntando los datos. useradd, universal, hace solo lo que indican sus opciones.
• Con useradd hacen falta -m para crear el directorio personal y -s para fijar la shell; la cuenta nace sin contraseña.
• El directorio personal de un usuario nuevo es una copia de /etc/skel.
• passwd cambia la contraseña propia; con sudo, la de otro. passwd -e obliga a cambiarla en el próximo ingreso.
• /etc/shadow guarda el hash de la contraseña y su vigencia. Un ! al comienzo del hash indica que está bloqueada.
• groupadd crea un grupo; usermod -aG grupo usuario agrega un miembro; gpasswd -d lo quita.
• usermod -G sin -a reemplaza todos los grupos secundarios del usuario.
• usermod modifica la shell, el nombre, el directorio, el vencimiento y el bloqueo de una cuenta.
• En Ubuntu, un usuario es administrador si pertenece al grupo sudo.
• Bloquear la contraseña no impide otros métodos de acceso; para cerrar una cuenta se la hace vencer además.
• userdel -r elimina la cuenta y su directorio personal. Los archivos que tenga en otros lugares quedan huérfanos, y se buscan con find -nouser.

16. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Crea un usuario de prueba con adduser. Comprueba su línea en /etc/passwd, su id, el contenido de su directorio personal y sus permisos.
2. Crea otro con useradd, primero sin opciones y luego, tras borrarlo, con -m -s /bin/bash -c. Compara las dos cuentas con getent passwd y ls -ld /home/*.
3. Mira el estado de la contraseña del segundo con passwd -S, asígnale una, márcala como vencida con passwd -e, y revisa su vigencia con chage -l.
4. Inicia una sesión como el primer usuario con su - nombre. Ejecuta id, pwd y sudo -l, e intenta entrar a tu propio directorio personal. Sal con exit.
5. Crea un grupo, agrega a los dos usuarios con usermod -aG, y verifica con getent group y con id.
6. Arma un directorio compartido en /srv para ese grupo, como en la sección 11, y pruébalo con sudo -u: que un miembro cree un archivo y que otro intente modificarlo.
7. Agrega un archivo a /etc/skel, por ejemplo sudo touch /etc/skel/LEEME.txt, crea un tercer usuario y comprueba que lo recibió. Quita después el archivo de /etc/skel.
8. Bloquea una de las cuentas con usermod -L, mira el efecto en sudo getent shadow nombre, e intenta entrar con su - nombre. Desbloquéala.
9. Aplica a las cuentas de prueba el procedimiento de baja de la sección 14, incluida la búsqueda de archivos con find -user antes y find -nouser después.
10. Deja el sistema como estaba: sin los usuarios, sin el grupo y sin el directorio de /srv. Compruébalo con getent y con ls /home /srv.