1. Objetivo y alcance

Esta guía agrupa los capítulos en los que se configura, sobre un sistema Linux, todo aquello que decide quién entra y qué puede hacer una vez dentro: las cuentas y sus credenciales, los permisos sobre los recursos y la autenticación mediante PAM. Es la parte práctica del contenido «Configuración de sistemas de control de acceso y autenticación de personas» del módulo, cuya teoría se desarrolla en la guía de autenticación y control de acceso, y toca también la gestión de credenciales y cuentas.

Este capítulo es una introducción, presenta cómo se reparte el trabajo en Linux entre sus componentes y deja los detalles de cada uno para los capítulos siguientes.

Si desea profundizar en los conceptos teóricos, como el modelo AAA (Authentication, Authorization and Accounting) o los modelos de control de acceso DAC (Discretionary Access Control), MAC (Mandatory Access Control), RBAC (Role-Based Access Control) y ABAC (Attribute-Based Access Control), los explica el capítulo de fundamentos de la guía de autenticación.

1.1. Términos básicos

Estos términos aparecen a lo largo del capítulo y se definen aquí para tenerlos a mano:

Término Significado

UID y GID

Números que identifican a un usuario y a un grupo, del inglés User Identifier y Group Identifier. El sistema trabaja con números. Los nombres son una comodidad para las personas

Hash

Resultado de transformar una contraseña con una función matemática que no se puede invertir. El sistema guarda el hash y no la contraseña

PAM

Pluggable Authentication Modules: componente que centraliza cómo se comprueba la identidad de quien intenta entrar

sudo

Orden que permite a un usuario autorizado ejecutar una operación con los privilegios de otra cuenta, normalmente root

su

Orden que abre una sesión como otro usuario, tras introducir la contraseña de ese usuario

Permisos

Reglas que indican quién puede leer, escribir o ejecutar un archivo o un directorio

Registro

También llamado log: archivo donde el sistema anota los eventos que ocurren, como los accesos

2. Por qué el control de acceso se aplica en capas

Todo acceso a un sistema atraviesa cuatro fases:

  1. Identificación: la persona dice quién es.

  2. Autenticación: el sistema comprueba que realmente lo es.

  3. Autorización: el sistema decide qué puede hacer.

  4. Trazabilidad: el sistema deja constancia de lo que hizo.

Cada fase es una barrera y ninguna es infalible. Una configuración robusta no confía en una sola, sino que hace que el fallo de una no implique la caída de las demás. Este es el principio de defensa en profundidad aplicado a la identidad.

Supóngase que un atacante obtiene la contraseña de un empleado mediante phishing, es decir, engañándole para que la escriba en una página falsa:

  • La autenticación ha fallado, pero un segundo factor, como el que se configura con PAM, puede impedir el acceso.

  • Si accede, la autorización limita el daño: una cuenta sin privilegios no puede modificar /etc ni leer los hashes de /etc/shadow, y las reglas de sudo acotan lo que puede elevar.

  • Aun así, la trazabilidad lo delata: un acceso desde un origen inusual, una elevación de privilegios o una modificación de archivos críticos dejan huella y permiten reaccionar.

Por el contrario, una autenticación débil con permisos laxos y sin registros no deja ninguna segunda oportunidad. Los capítulos siguientes refuerzan cada capa con medidas concretas y verificables.

3. Las cuatro fases del acceso en un sistema Linux

En Linux, cada fase la materializa un componente distinto, y conocerlos permite saber dónde actuar cuando una fase falla.

Las cuatro fases del acceso en un sistema Linux
Figura 1. Las cuatro fases del acceso en un sistema Linux
Fase Componente Archivos y órdenes Capítulo

Identificación

Base de datos de usuarios

/etc/passwd, id, getent

gestión de usuarios y grupos

Autenticación

PAM y los servicios que lo usan

/etc/pam.d/, /etc/shadow

PAM y gestión de usuarios y grupos

Autorización

Permisos del núcleo y sudo

ls -l, /etc/sudoers

permisos y control de acceso básico y gestión de usuarios y grupos

Trazabilidad

Registros del sistema

/var/log/auth.log, journalctl, last

trazabilidad y auditoría de accesos

3.1. Identificación

El núcleo no conoce nombres de usuario, solo UID y GID numéricos. La traducción entre el nombre que teclea la persona y esos números la realiza un mecanismo llamado NSS (Name Service Switch), que consulta las fuentes de datos configuradas en /etc/nsswitch.conf.

id
getent passwd "$USER"
grep -E '^(passwd|group):' /etc/nsswitch.conf
Orden Significado

id

Muestra el UID, el GID y los grupos del usuario actual. Sin parámetros, consulta al usuario que la ejecuta

getent passwd "$USER"

getent consulta una base de datos del sistema. passwd es la base de datos de usuarios y "$USER" es una variable con el nombre del usuario actual, que se usa como clave de búsqueda

La tercera orden es grep -E '^(passwd|group):' /etc/nsswitch.conf. grep busca las líneas que cumplen un patrón, y -E activa las expresiones regulares extendidas. El patrón ^(passwd|group): selecciona las líneas que empiezan por passwd: o group:, donde ^ indica el inicio de la línea y la barra vertical | significa «o».

Qué observar. La salida es parecida a esta:

uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),4(adm),27(sudo)

ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash

passwd:         files systemd
group:          files systemd

La primera línea muestra su UID, su GID y los grupos a los que pertenece. La segunda es su entrada en la base de datos de usuarios, que empieza por el nombre, la letra x que indica que la contraseña está en otro archivo, el UID y el GID. Las dos últimas indican de dónde se obtienen los datos, donde files son los archivos locales como /etc/passwd y systemd son las cuentas de servicios que crea el propio sistema.

Ampliación: directorios corporativos.

En una organización, las cuentas suelen estar en un directorio central y no en cada máquina. LDAP (Lightweight Directory Access Protocol) es el protocolo con el que se consulta ese directorio, y SSSD (System Security Services Daemon, servicio de segundo plano de seguridad del sistema) es el servicio que conecta el equipo con él y guarda una caché local. Cuando existe SSSD, /etc/nsswitch.conf añade sss a las fuentes, y la orden getent encuentra a las personas del directorio, mientras que grep sobre /etc/passwd solo ve las cuentas locales. Este tema se estudia en la guía de autenticación centralizada y federada.

3.2. Autenticación

Las aplicaciones no comprueban contraseñas por su cuenta sino que delegan en PAM, que lee la política de cada servicio en un archivo propio dentro de /etc/pam.d/. Así se puede cambiar cómo se autentica a la gente, por ejemplo añadiendo un segundo factor, sin modificar la aplicación.

Las contraseñas no se guardan tal cual, sino como hash en /etc/shadow. Al iniciar sesión, el sistema calcula el hash de lo que se teclea y lo compara con el guardado. Por eso /etc/shadow solo puede leerlo el administrador.

ls -l /etc/passwd /etc/shadow
ls /etc/pam.d/
Orden Significado

ls -l /etc/passwd /etc/shadow

ls lista archivos. -l usa el formato largo, que muestra permisos, propietario, grupo, tamaño y fecha. Se indican dos archivos para compararlos

ls /etc/pam.d/

Lista el contenido del directorio /etc/pam.d/, donde hay un archivo por servicio

Qué observar. /etc/passwd es legible por todos, porque cualquier programa necesita traducir UID a nombres, y /etc/shadow no:

-rw-r--r-- 1 root root   1656 Oct 19 23:18 /etc/passwd
-rw-r----- 1 root shadow  824 Oct 19 23:18 /etc/shadow

En /etc/pam.d/ hay un archivo por servicio, como sshd, sudo o login, cada uno con su propia política.

Ampliación: claves públicas en SSH.

El acceso por SSH (Secure Shell), el protocolo de administración remota, con clave pública es una excepción, porque lo verifica el propio servidor sshd y no pasa por la fase de autenticación de PAM. Esto tiene consecuencias para el bloqueo de cuentas, que se estudian en el capítulo de gestión de usuarios y grupos.

3.3. Autorización

Una vez identificada y autenticada, la persona solo puede hacer lo que el sistema le autoriza. En Linux hay dos mecanismos básicos:

  • Los permisos de archivos y directorios. Cada uno tiene un propietario, un grupo y tres conjuntos de permisos de lectura r, escritura w y ejecución x: para el propietario, para el grupo y para el resto de usuarios.

  • sudo, que decide qué operaciones administrativas puede ejecutar cada usuario con los privilegios de otra cuenta, normalmente root. Un usuario solo puede usarlo si la política de /etc/sudoers se lo permite, o si pertenece al grupo sudo.

sudo -l
ls -ld /home /root
Orden Significado

sudo -l

sudo ejecuta una orden con otros privilegios. -l no ejecuta nada, sino que lista (list) lo que el usuario actual puede ejecutar con sudo

ls -ld /home /root

-l usa el formato largo y -d muestra los datos del propio directorio en lugar de listar su contenido, que es lo que se quiere para ver sus permisos

Qué observar. La salida de sudo -l en una instancia de OpenStack podría ser parecida a esta:

User ubuntu may run the following commands on lab:
    (ALL : ALL) ALL
    (ALL) NOPASSWD: ALL

La salida muestra lo que el usuario puede ejecutar. Cada línea tiene el formato (cuenta : grupo) órdenes:

  • (ALL : ALL) ALL permite ejecutar cualquier orden como cualquier usuario y grupo. Procede de la regla de /etc/sudoers para los miembros del grupo sudo.

  • (ALL) NOPASSWD: ALL permite lo mismo sin pedir contraseña. La crea cloud-init en /etc/sudoers.d/ para que la cuenta inicial pueda administrar la máquina virtual. Por eso en estas máquinas sudo no pide contraseña al usuario ubuntu.

sudo suma todas las reglas que se aplican al usuario. Si una cuenta no tiene ninguna, la salida indica User …​ is not allowed to run sudo.

Ubuntu 26.04. Desde esta versión, la orden sudo es una reimplementación en el lenguaje Rust llamada sudo-rs. Su salida de sudo -l es igual, pero no muestra el primer bloque de opciones por defecto. La versión clásica sigue instalada con el nombre sudo.ws.

ls -ld muestra una cadena como drwxr-xr-x para /home y drwx------ para /root. La primera letra indica el tipo, d en un directorio, y las nueve siguientes son los permisos de propietario, grupo y resto, de modo que en /root solo el propietario puede entrar.

Capas adicionales.

Sobre estos dos mecanismos, Linux añade otras capas que se estudian más adelante: las listas de control de acceso, las opciones de montaje y los atributos de los archivos, en el capítulo de permisos y control de acceso básico. Existen además el control de acceso obligatorio, con AppArmor o SELinux, y las capacidades del proceso, que no se tratan en este capítulo.

3.4. Trazabilidad

Los intentos de autenticación, los usos de sudo y los cambios de cuenta quedan anotados en el registro del sistema, que en Debian y Ubuntu está en /var/log/auth.log y en el diario de systemd, consultable con journalctl. Las sesiones iniciadas se consultan con last.

last -n 5
sudo journalctl -t sudo --since '-1h' --no-pager | tail -5
Orden Significado

last -n 5

last lista las sesiones iniciadas. -n 5 limita la salida a las cinco más recientes

sudo journalctl -t sudo --since '-1h' --no-pager

journalctl consulta el diario del sistema. -t sudo filtra por el programa que generó el mensaje, en este caso sudo. --since '-1h' limita a la última hora. --no-pager evita que la salida se abra en un visor interactivo

La orden termina con | tail -5. La tubería | pasa la salida de la orden anterior a tail, que muestra solo las últimas cinco líneas.

Qué observar. Cada línea de sudo indica quién ejecutó qué orden y con qué cuenta de destino:

Oct 19 23:28:33 lab sudo[108540]:   ubuntu : PWD=/home/ubuntu ; USER=root ; COMMAND=/usr/bin/cat /etc/hostname

Ubuntu 26.04. En esta versión las órdenes last, lastb y lastlog ya no se instalan. Si last responde Command 'last' not found, instale el paquete que la proporciona con sudo apt install wtmpdb. Ese paquete solo registra los accesos posteriores a su instalación. Para lastlog existe el paquete lastlog2, que ofrece la orden lastlog2. La orden lastb no tiene sustituto, y los intentos de acceso fallidos se consultan en el diario con journalctl.

Sin estos registros es imposible detectar una intrusión o reconstruir lo ocurrido, y su valor depende de que cada persona tenga una cuenta individual. Para un registro más detallado de accesos a archivos y llamadas al sistema se utiliza auditd, que se estudia en el capítulo de trazabilidad y auditoría de accesos.

4. Mapa del directorio

Capítulo Qué configura Fase principal Tema de la guía teórica

Usuarios y grupos

Cuentas, grupos, shadow, caducidad, sudo y baja segura

Identificación, autenticación y trazabilidad

Factor de conocimiento

Permisos y control de acceso básico

Permisos, umask, bits especiales, listas de control de acceso (ACL), atributos y montaje

Autorización

Modelos de control de acceso

PAM

Bloqueo por intentos, política de contraseñas, su y contraseñas de un solo uso basadas en tiempo (TOTP)

Autenticación

Factor de posesión y autenticación multifactor, MFA por Multi-Factor Authentication

Trazabilidad y auditoría de accesos

journald, rsyslog, last, auditd y envío remoto de registros

Trazabilidad

Trazabilidad en el modelo AAA

5. Ejercicios prácticos

Los ejercicios de este capítulo son de análisis: no hay que ejecutar ninguna orden nueva, sino razonar a partir de los conceptos de la sección 3 y de salidas de ejemplo ya preparadas. Las prácticas con órdenes de gestión de cuentas, permisos, PAM y registros se realizan en los capítulos siguientes, una vez estudiadas esas herramientas.

Nº Ejercicio Competencia que desarrolla

1

Clasificación de acciones por fase

Situar cada acción en identificación, autenticación, autorización o trazabilidad

2

Lectura de salidas

Interpretar id, ls -l y sudo -l para decidir qué puede hacer una cuenta

3

Autenticación y autorización en el registro

Distinguir un fallo de autenticación de una autorización denegada

4

Cuentas compartidas y capítulo de referencia

Valorar el efecto de las cuentas compartidas y localizar el capítulo adecuado

Los ejercicios 1 y 3 solo requieren la sección 3. El ejercicio 2 requiere además la sección 3.3, y el 4, la sección 4.

5.1. Ejercicio 1. Clasificación de acciones por fase

Indique a qué fase corresponde cada acción: identificación, autenticación, autorización o trazabilidad.

  1. El sistema traduce el nombre ana al UID 1001.

  2. El sistema compara el hash de la contraseña tecleada con el guardado en /etc/shadow.

  3. sudo comprueba en /etc/sudoers si ana puede ejecutar systemctl restart nginx.

  4. Queda anotado en /var/log/auth.log que ana ejecutó esa orden a las 10:42.

  5. El núcleo deniega a ana la lectura de un archivo con permisos rw-r----- que pertenece a otro usuario y a otro grupo.

  6. PAM pide un código TOTP además de la contraseña.

Solución

  1. Identificación. NSS consulta /etc/passwd u otras fuentes.

  2. Autenticación. PAM y /etc/shadow.

  3. Autorización. Política de sudo.

  4. Trazabilidad. Registro del sistema.

  5. Autorización. Permisos del núcleo.

  6. Autenticación. Segundo factor gestionado por PAM.

5.2. Ejercicio 2. Lectura de salidas

Un compañero le muestra la siguiente información sobre la cuenta luis:

$ id luis
uid=1002(luis) gid=1002(luis) groups=1002(luis),1010(contabilidad)

$ ls -l /srv/datos/
-rw-r----- 1 root contabilidad  512 Oct 19 10:00 balance.txt
-rw------- 1 root root          128 Oct 19 10:00 claves.txt
-rw-r--r-- 1 root root          256 Oct 19 10:00 aviso.txt

$ sudo -l -U luis
User luis is not allowed to run sudo on lab.

Responda a las preguntas:

  1. ¿Puede luis leer balance.txt? ¿Y modificarlo?

  2. ¿Puede luis leer claves.txt? ¿Y aviso.txt?

  3. ¿Puede luis leer claves.txt si antepone sudo a la orden? ¿Por qué?

  4. ¿Qué dos mecanismos de autorización intervienen en este ejercicio y por qué son independientes?

Solución

  1. Puede leerlo, porque pertenece al grupo contabilidad y el grupo tiene r--. No puede modificarlo: el grupo no tiene w.

  2. claves.txt no: solo root tiene permisos y luis es «resto». aviso.txt sí, porque «resto» tiene r--.

  3. No. sudo -l indica que luis no puede usar sudo, así que la orden se rechaza.

  4. Los permisos de los archivos, que deciden quién lee o escribe cada dato, y la política de sudo, que decide quién ejecuta operaciones administrativas. Son independientes: poder leer balance.txt no concede ningún privilegio administrativo, y tener sudo no depende de los permisos de ningún archivo concreto.

5.3. Ejercicio 3. Autenticación y autorización en el registro

En el registro de un equipo aparecen estas dos líneas, generadas por dos intentos distintos de la cuenta observador al ejecutar sudo ls /root:

sudo: observador : user NOT in sudoers ; TTY=pts/0 ; PWD=/home/observador ; USER=root ; COMMAND=/usr/bin/ls /root
sudo: pam_unix(sudo:auth): authentication failure; logname=ubuntu uid=1001 euid=0 tty=/dev/pts/0 ruser=observador rhost=  user=observador

Responda a las preguntas:

  1. ¿Qué fase del modelo refleja cada línea?

  2. En uno de los intentos la persona escribió la contraseña correcta y en el otro una incorrecta. ¿Cuál es cuál? Justifique la respuesta.

  3. ¿Por qué en el intento con la contraseña correcta no hay ningún fallo de autenticación aunque la orden no se ejecutó?

Solución

  1. authentication failure corresponde a la autenticación: la identidad no se pudo demostrar. user NOT in sudoers corresponde a la autorización: la identidad era válida, pero no tenía permiso.

  2. Contraseña correcta: user NOT in sudoers, porque superó la autenticación y falló después en la autorización. Contraseña incorrecta: authentication failure, porque no llegó a superar la autenticación.

  3. La autenticación fue válida, así que no se registró ningún fallo. sudo comprobó después la autorización y no encontró a observador en sudoers, de modo que denegó la orden.

5.4. Ejercicio 4. Cuentas compartidas y capítulo de referencia

  1. Razone qué faltaría en el registro si todos los administradores compartieran una única cuenta y cómo afectaría a la investigación de un incidente.

    Solución

    Faltaría la imputabilidad: las líneas de sudo y de auth.log mostrarían siempre la misma cuenta y no se podría saber qué persona ejecutó cada orden. Tampoco se podría revocar el acceso de una sola persona sin afectar a las demás, ni distinguir la actividad legítima de la de una cuenta comprometida. Por eso se exigen cuentas nominales y sudo en lugar de contraseñas compartidas.

  2. Indique en qué capítulo de este directorio buscaría la solución a cada problema:

    • Una persona ha dejado la organización y hay que dar de baja su cuenta.

    • Un archivo de nóminas es legible por todo el mundo.

    • Se quiere bloquear una cuenta tras cinco contraseñas incorrectas.

    • Se necesita saber quién se conectó ayer a las 3:00 de la madrugada.

      Solución

      • Baja de la cuenta: usuarios y grupos.

      • Archivo de nóminas legible: permisos y control de acceso básico.

      • Bloqueo tras intentos fallidos: PAM (pam_faillock).

      • Conexiones de ayer: trazabilidad y auditoría de accesos.

6. Referencias

7. Licencia

Licencia CC BY-NC-ND 4.0

Esta página forma parte del curso Bastionado de Redes y Sistemas © 2026 de José Juan Sánchez Hernández y su contenido se distribuye bajo una licencia Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

Esta licencia exige que quienes reutilicen el material otorguen el debido crédito al autor. Permite copiar y redistribuir el material en cualquier medio o formato, únicamente en su forma original, y solo para fines no comerciales.