Debian 13: Recuperar acceso root con modo de rescate — hazlo sin empeorar las cosas

Las únicas reglas que importan en modo de rescate

El modo de rescate es un bisturí, no una motosierra. El objetivo es estrecho: recuperar acceso administrativo controlado y luego salir limpiamente.
No “arregles todo mientras estás aquí”. Así es como los incidentes de acceso root se convierten en reconstrucciones de varios días.

Regla 1: Prueba qué sistema estás tocando

Los entornos de rescate están llenos de trampas porque facilitan montar discos de varios sistemas.
Antes de cambiar nada, confirma el nombre del host, los IDs de disco y el sistema de ficheros raíz que pretendes reparar.
Si no puedes probarlo, estás adivinando. Adivinar es caro.

Regla 2: Por defecto usa solo lectura hasta identificar la falla

Muchos fallos de “acceso root” no son de autenticación. Son fallos de montaje en el arranque, initramfs roto, módulos PAM corruptos,
permisos mal aplicados en /etc/shadow, o un aviso de cifrado expirado que no ves en arranques sin consola.

Monta en solo lectura primero. Recopila pruebas. Luego remonta en lectura-escritura para el único cambio que resuelve la causa raíz.

Regla 3: Prefiere cambios mínimos y reversibles

Editar pilas PAM, sudoers o la configuración de SSHD en modo pánico es como bloquearte dos veces.
Si debes cambiar autenticación, usa un camino probado: establece una contraseña temporal de root, vuelve a habilitar un usuario administrador conocido y agenda una corrección adecuada.

Regla 4: Mantén una pista forense

Olvidarás lo que hiciste. Tu compañero preguntará. Tu yo futuro te maldecirá.
Toma notas: qué estaba roto, qué comandos ejecutaste, qué archivo editaste. Incluso un registro de texto sencillo en /root/rescue-notes.txt vale oro.

Broma #1: El modo de rescate es como una cirugía: campo estéril, instrumentos limpios y absolutamente nada de “veamos qué pasa si toco esto”.

Hechos y contexto interesantes (por qué Debian se comporta así)

• Roots de un solo usuario: El “single-user mode” tradicional de Unix precede a systemd por décadas y estaba pensado para recuperación desde consola local cuando los servicios multiusuario fallaban.
• systemd emergency vs rescue: En sistemas con systemd, los targets “rescue” buscan un sistema mínimo; “emergency” es aún más pequeño—a menudo solo un shell tipo initramfs con menos montajes.
• La cuenta root puede estar bloqueada por diseño: Muchas instalaciones Debian dependen de sudo y pueden bloquear root configurando su hash de contraseña a un valor especial. No es un fallo; es una elección de política.
• PAM es una pila, no un interruptor: Pluggable Authentication Modules fueron diseñados para permitir a empresas cambiar métodos de autentificación sin reescribir aplicaciones, lo que también significa que una línea rota puede romperlo todo.
• /etc/shadow no siempre estuvo separado: La separación entre /etc/passwd y /etc/shadow es una evolución de seguridad para ocultar hashes de contraseña a usuarios no root.
• Initramfs es un pequeño OS: Linux moderno arranca mediante un sistema de ficheros en RAM inicial que carga controladores, descifra discos, activa LVM y monta la raíz real. Si ese pequeño OS está mal, tu “problema de root” está río arriba.
• GRUB se convirtió en el predeterminado por buenas razones: La capacidad de GRUB para editar parámetros del kernel al arrancar es un salvavidas en recuperación—y también una razón por la que el acceso físico a la consola importa.
• Opciones de montaje pueden bloquearte: Una sola línea errónea en /etc/fstab puede dejarte en emergency mode, aunque las contraseñas sean correctas.

Una cita para tener en la cabeza cuando sube la presión: “La esperanza no es una estrategia.” — General Gordon R. Sullivan.

Guion de diagnóstico rápido (verifica 1/2/3)

Cuando estás en una consola con un sistema roto, la ruta más rápida es clasificar la falla. No por sensaciones. Por señales.

Verificación 1: ¿Es una falla de autenticación o de arranque/montaje?

• Si obtienes un prompt de login pero root/sudo falla: probablemente estado de cuenta, PAM, permisos de shadow o sudoers.
• Si nunca llegas a un login normal y caes en emergency mode: probablemente fstab, initramfs, activación LUKS/LVM, errores de sistema de ficheros.
• Si el sistema está arriba pero no puedes entrar remotamente: probablemente red, sshd config, claves del host, firewall o permisos de clave.

Verificación 2: ¿La raíz está íntegra y montable?

Antes de tocar la autenticación, verifica que puedes montar la raíz real. Si no puedes montar la raíz de forma segura, detente y diagnostica el almacenamiento.
Arreglar contraseñas en el punto de montaje equivocado es un clásico autoengaño.

Verificación 3: ¿Puedes reproducir la falla con logs?

En modo rescate, monta la raíz en solo lectura e inspecciona /var/log y el journal. Si la falla es reproducible y está registrada, puedes arreglarla con precisión.
Si no está registrada, aún puedes inferir la causa por la deriva de configuración y errores de arranque.

Formas de entrar en modo de rescate en Debian 13

1) GRUB: editar la línea de comando del kernel (acceso a consola)

Si puedes llegar a GRUB, normalmente puedes alcanzar la recuperación root. Resalta la entrada de arranque normal, presiona e y añade:
systemd.unit=rescue.target o systemd.unit=emergency.target a la línea Linux.

El target rescue tiende a levantar más del sistema (incluyendo algunos montajes). Emergency target es minimal y útil cuando los montajes están rotos.

2) Medio del instalador Debian: “Rescatar un sistema roto”

Arranca el ISO del instalador (o netinst) y elige la opción de rescate. Puede detectar sistemas instalados, montarlos y ofrecer un chroot.
Esto suele ser la vía más limpia en servidores sin cabeza donde tienes KVM remoto o una consola virtual.

3) Cloud/VM: adjuntar un ISO de rescate o usar la imagen de rescate del proveedor

En producción, puede que no tengas acceso físico. Usa la consola del hipervisor y arranca un ISO de rescate, o el modo de rescate del proveedor.
La misma disciplina aplica: identifica discos por IDs estables, monta en solo lectura primero y ten cuidado con volúmenes cifrados.

Mapa de triaje: qué estás realmente arreglando

“Recuperar acceso root” puede significar varios problemas diferentes. Clasifícalo antes de actuar.

A. Cuenta root bloqueada o contraseña desconocida

Root puede estar bloqueada intencionalmente, o puedes haber heredado un sistema donde nadie conoce la contraseña.
La solución suele ser: montar el sistema, chroot, establecer una nueva contraseña o reactivar sudo para un usuario administrador conocido.

B. sudo roto (sintaxis, permisos, archivo equivocado)

Una entrada sudoers malformada puede romper todo el uso de sudo. Eso parece “sin acceso root”, pero en realidad es un fallo de validación de configuración.
La solución es: validar con visudo (o reparar cuidadosamente) desde un chroot.

C. Pila PAM / auth rota

Si se eliminaron, desajustaron o malconfiguraron módulos PAM, los inicios de sesión fallarán incluso con contraseñas correctas.
La reparación suele ser restaurar paquetes/configuración correctos; evita “desactivar PAM” como arreglo temporal.

D. El sistema cae en emergency mode (fstab, fsck, dispositivo no encontrado)

Esto no es un problema de autenticación. Es un problema de dependencias de arranque. Arregla el montaje, el UUID o el sistema de ficheros primero.

E. Raíz cifrada o LVM que no se activa

Si initramfs no puede desbloquear LUKS o montar LVM, tu raíz nunca aparece. La solución está en initramfs, crypttab, metadatos LVM o controladores faltantes.

F. Acceso remoto caído (sshd, claves, firewall) pero root local existe

A veces la máquina está bien y solo el acceso remoto está roto. No restablezcas root solo porque SSH esté caído.
Repara SSH y la red con cambios mínimos.

Tareas prácticas (comandos, salidas, decisiones)

Estas son las tareas que realmente ejecuto en escenarios de rescate. Cada una tiene: comando, qué significa la salida típica y la decisión que tomas.
Los comandos asumen un shell de rescate con privilegios root. El prompt del host está fijado según tus requisitos.

Tarea 1: Identificar discos y particiones (no adivines)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS
NAME        SIZE TYPE FSTYPE UUID                                 MOUNTPOINTS
sda         480G disk
├─sda1      512M part vfat   7C2A-1F0B                            /boot/efi
├─sda2        2G part ext4   2a9c1f7b-1c77-4e7b-8f4c-2df9c5a2d9c1 /boot
└─sda3    477.5G part crypto_LUKS 3a0b6d9b-... 
  └─cryptroot 477.5G crypt LVM2_member 8h2KqX-...
    ├─vg0-root  80G lvm  ext4   7f6b9e0c-...                      /
    └─vg0-var  200G lvm  xfs    4f0d2c1a-...                      /var

Significado: Puedes ver si tratas con particiones simples, LUKS, LVM y qué tipos de FS necesitarás de herramientas (ext4, xfs, btrfs).

Decisión: Si ves capas LUKS/LVM, planea desbloquear y activar antes de montar. Si la raíz no es obvia, detente y mapea antes de editar nada.

Tarea 2: Confirma que el kernel vio el almacenamiento esperado

cr0x@server:~$ dmesg -T | grep -E "sd[a-z]|nvme|dm-|crypt|I/O error" | tail -n 20
[Mon Dec 30 01:12:03 2025] nvme nvme0: pci function 0000:01:00.0
[Mon Dec 30 01:12:03 2025] nvme0n1: p1 p2 p3
[Mon Dec 30 01:12:04 2025] device-mapper: crypt: dm-0: set key succeeded

Significado: No ver errores de I/O es bueno. Si ves timeouts o errores de lectura, podrías estar en territorio de disco fallando, no de auth.

Decisión: Si el almacenamiento es inestable, minimiza escrituras. Prefiere montajes en solo lectura, toma una imagen/snapshot si está disponible y planea reemplazo en lugar de “arreglar configs”.

Tarea 3: Si se usa LUKS, desbloquea explícitamente (y verifica)

cr0x@server:~$ cryptsetup luksOpen /dev/sda3 cryptroot
Enter passphrase for /dev/sda3:

cr0x@server:~$ cryptsetup status cryptroot
/dev/mapper/cryptroot is active.
  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 bits
  device:  /dev/sda3
  sector size:  512
  offset:  32768 sectors
  size:    1000204288 sectors
  mode:    read/write

Significado: El dispositivo mapper existe y está activo. El mode muestra si es escribible en este nivel.

Decisión: Si el desbloqueo falla, no intentes fuerza bruta. Verifica que estás en el dispositivo correcto, comprueba el layout del teclado en el entorno de rescate y confirma la fuente de la frase de paso.

Tarea 4: Activar volúmenes LVM (si existen)

cr0x@server:~$ vgscan
  Found volume group "vg0" using metadata type lvm2

cr0x@server:~$ vgchange -ay
  2 logical volume(s) in volume group "vg0" now active

Significado: Los metadatos LVM son legibles y los volúmenes lógicos están activos.

Decisión: Si la activación falla, inspecciona pvs/vgs/lvs y considera si el PV falta (disco desconectado) o está filtrado por la configuración de LVM.

Tarea 5: Monta la raíz en solo lectura primero (siempre)

cr0x@server:~$ mount -o ro /dev/vg0-root /mnt
cr0x@server:~$ mount | grep " /mnt "
/dev/mapper/vg0-root on /mnt type ext4 (ro,relatime)

Significado: El sistema de ficheros raíz se monta limpiamente en modo solo lectura.

Decisión: Si el montaje falla con “wrong fs type” o “bad superblock”, detente y ejecuta comprobaciones de sistema de ficheros con la herramienta correcta (tareas siguientes). No empieces a editar /etc si el FS está poco saludable.

Tarea 6: Monta los sistemas de ficheros de soporte (boot, EFI, var) correctamente

cr0x@server:~$ mount -o ro /dev/sda2 /mnt/boot
cr0x@server:~$ mount -o ro /dev/sda1 /mnt/boot/efi
cr0x@server:~$ mount -o ro /dev/vg0-var /mnt/var
cr0x@server:~$ findmnt -R /mnt
TARGET        SOURCE               FSTYPE OPTIONS
/mnt          /dev/mapper/vg0-root ext4   ro,relatime
/mnt/boot     /dev/sda2            ext4   ro,relatime
/mnt/boot/efi /dev/sda1            vfat   ro,relatime
/mnt/var      /dev/mapper/vg0-var  xfs    ro,relatime

Significado: Tu chroot (más tarde) verá la misma disposición que espera el sistema instalado.

Decisión: Si /var está separado y no montado, los logs del journal y el estado de auth pueden parecer “faltantes”, llevando a conclusiones erróneas.

Tarea 7: Comprueba qué falló realmente en el último arranque (journal)

cr0x@server:~$ journalctl --directory=/mnt/var/log/journal -b -1 -p err..alert --no-pager | tail -n 30
Dec 29 23:58:12 db13 systemd[1]: Failed to mount /data.
Dec 29 23:58:12 db13 systemd[1]: Dependency failed for Local File Systems.
Dec 29 23:58:12 db13 systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.

Significado: Este es un patrón de fallo de arranque (fstab mount), no un fallo de contraseña.

Decisión: Arregla la definición de montaje antes de tocar cuentas de usuario. De lo contrario “recuperarás root” y aún caerás en emergency mode.

Tarea 8: Inspeccionar y validar /etc/fstab de forma segura

cr0x@server:~$ sed -n '1,200p' /mnt/etc/fstab
UUID=7f6b9e0c-...  /      ext4  defaults,errors=remount-ro  0 1
UUID=2a9c1f7b-...  /boot  ext4  defaults                   0 2
UUID=7C2A-1F0B     /boot/efi vfat umask=0077               0 1
UUID=deadbeef-...  /data  ext4  defaults                   0 2

Significado: Ese UUID=deadbeef... es sospechoso si no existe.

Decisión: Compáralo con blkid. Si el UUID está obsoleto, corrígelo o añade nofail,x-systemd.device-timeout=10s para montajes no críticos y permitir el arranque.

Tarea 9: Verificar UUIDs y etiquetas (verdad terreno)

cr0x@server:~$ blkid
/dev/sda1: UUID="7C2A-1F0B" TYPE="vfat" PARTUUID="..."
/dev/sda2: UUID="2a9c1f7b-1c77-4e7b-8f4c-2df9c5a2d9c1" TYPE="ext4" PARTUUID="..."
/dev/mapper/vg0-root: UUID="7f6b9e0c-..." TYPE="ext4"
/dev/mapper/vg0-var: UUID="4f0d2c1a-..." TYPE="xfs"

Significado: Si un UUID en fstab no aparece en esta lista, no se montará al arrancar.

Decisión: Corrige el identificador incorrecto. Si el disco se retiró intencionalmente, elimina/comenta el montaje o márcalo como nofail.

Tarea 10: Si la integridad del sistema de ficheros es dudosa, compruébala correctamente

Para ext4, usa fsck en un sistema de ficheros desmontado. Para XFS, generalmente usa xfs_repair (y es exigente con estar desmontado).

cr0x@server:~$ umount /mnt
cr0x@server:~$ fsck.ext4 -f /dev/vg0-root
e2fsck 1.47.0 (5-Feb-2023)
/dev/vg0-root: clean, 512345/5242880 files, 12345678/20971520 blocks

Significado: “clean” significa que el FS probablemente no es tu problema.

Decisión: Si informa errores y los corrige, vuelve a montar y vuelve a revisar logs. Si reporta corrupción severa, pausa y considera imagenes/backup antes de más escrituras.

Tarea 11: Prepararse para un chroot correctamente (bind mounts)

cr0x@server:~$ mount /dev/vg0-root /mnt
cr0x@server:~$ mount /dev/sda2 /mnt/boot
cr0x@server:~$ mount /dev/sda1 /mnt/boot/efi
cr0x@server:~$ mount --bind /dev  /mnt/dev
cr0x@server:~$ mount --bind /proc /mnt/proc
cr0x@server:~$ mount --bind /sys  /mnt/sys
cr0x@server:~$ mount --bind /run  /mnt/run
cr0x@server:~$ chroot /mnt /bin/bash

Significado: Ahora operas como si arrancaras en el OS instalado, con nodos de dispositivo y proc/sys disponibles.

Decisión: Si vas a reconstruir initramfs, actualizar GRUB o reparar paquetes, hazlo desde un chroot correcto. Si no, corres el riesgo de generar artefactos de arranque para el entorno equivocado.

Tarea 12: Comprobar si root está bloqueado o expirado

cr0x@server:~$ passwd -S root
root L 2025-10-01 0 99999 7 -1

Significado: La L indica bloqueada. Otros estados incluyen P para contraseña establecida.

Decisión: Si root está bloqueada pero la necesitas temporalmente, desbloquéala y establece una contraseña, luego decide si volver a bloquear y confiar en sudo.

Tarea 13: Establecer o resetear la contraseña root de forma segura

cr0x@server:~$ passwd root
New password:
Retype new password:
passwd: password updated successfully

Significado: La autenticación root debería funcionar ahora (suponiendo que PAM no esté roto).

Decisión: Usa una contraseña temporal fuerte, guárdala en tu bóveda de incidentes y rótala después del incidente. No dejes una contraseña “temporal” en producción por meses—el tiempo convierte lo temporal en permanente.

Tarea 14: Validar sudoers (no edites a ciegas)

cr0x@server:~$ visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/ops: parsed OK

Significado: La sintaxis es válida. Si falla, te dirá dónde.

Decisión: Si sudoers está roto, arregla el archivo indicado. Si no puedes usar visudo por problemas de editor en rescate, establece EDITOR=vi explícitamente en lugar de editar con herramientas al azar.

Tarea 15: Comprobar rápidamente roturas en PAM (módulos faltantes es común)

cr0x@server:~$ grep -R --line-number -E "pam_unix|pam_sss|pam_tally2|pam_faillock" /etc/pam.d | head
/etc/pam.d/common-auth:25:auth    [success=1 default=ignore]      pam_unix.so nullok
/etc/pam.d/sshd:1:@include common-auth

cr0x@server:~$ ldconfig -p | grep pam_unix || true

Significado: Si la configuración PAM referencia módulos que no están presentes en disco, los inicios de sesión fallan. La ausencia de librerías PAM esperadas es una bandera roja después de upgrades parciales o limpiezas excesivas.

Decisión: Reinstala los paquetes relevantes desde dentro del chroot si hay acceso a red/repos; de lo contrario, usa medios locales o arregla el estado de paquetes cuando la máquina arranque.

Tarea 16: Confirmar propiedad y permisos de /etc/shadow

cr0x@server:~$ ls -l /etc/passwd /etc/shadow /etc/group /etc/gshadow
-rw-r--r-- 1 root root   2934 Dec 29 23:01 /etc/passwd
-rw-r----- 1 root shadow 1682 Dec 29 23:01 /etc/shadow
-rw-r--r-- 1 root root   1203 Dec 29 23:01 /etc/group
-rw-r----- 1 root shadow  986 Dec 29 23:01 /etc/gshadow

Significado: Si /etc/shadow es legible por todo el mundo, eso es un incidente de seguridad; si no es legible por root (sí, ocurre por ACLs extrañas), la autenticación falla.

Decisión: Arregla la propiedad y los modos si están mal. Si los permisos “parecen” correctos pero auth aún falla, revisa ACLs a nivel de sistema de ficheros o atributos inmutables.

Tarea 17: Comprobar banderas inmutables y sorpresas de ACL

cr0x@server:~$ lsattr /etc/shadow
---------------------- /etc/shadow
cr0x@server:~$ getfacl -p /etc/shadow | head
# file: /etc/shadow
# owner: root
# group: shadow
user::rw-
group::r--
other::---

Significado: Un bit inmutable (i) o una ACL extraña puede impedir ediciones o cambiar la semántica de acceso.

Decisión: Si el inmutable está puesto y no sabes por qué, detente. Eso suele ser herramienta de política. Elimínalo solo si entiendes el radio de impacto.

Tarea 18: Si SSH es el problema, valida sshd config offline

cr0x@server:~$ sshd -t -f /etc/ssh/sshd_config
cr0x@server:~$ grep -E "^(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication)" /etc/ssh/sshd_config
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes

Significado: sshd -t sale silenciosamente si la config está OK; imprime errores si no. El login root puede estar deshabilitado por política; eso no está “roto”.

Decisión: Si necesitas acceso remoto de emergencia, prefiere habilitar la clave de un usuario admin conocido en lugar de habilitar el login por contraseña de root. Si debes cambiarlo, hazlo temporalmente y registra el cambio.

Tarea 19: Reconstruir initramfs cuando falla el desbloqueo de disco/activación LVM

cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64

Significado: Se regeneran imágenes initramfs para kernels instalados.

Decisión: Haz esto cuando el arranque falla por controladores/módulos faltantes, hooks de crypttab rotos, o después de reparar paquetes LVM/crypt. Si no cambiaste nada relevante, no generes artefactos de arranque “solo porque sí”.

Tarea 20: Reinstalar o refrescar GRUB solo cuando tengas pruebas

cr0x@server:~$ grub-install /dev/sda
Installing for x86_64-efi platform.
Installation finished. No error reported.
cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.0-amd64
Found initrd image: /boot/initrd.img-6.12.0-amd64
done

Significado: GRUB está instalado y la configuración se regenera, detectando kernels/initrds.

Decisión: Haz esto solo si tuviste un síntoma de fallo del gestor de arranque (GRUB ausente, entrada de arranque errónea, después de reemplazar disco). Reinstalar GRUB para “arreglar la contraseña root” es como cambiar neumáticos para arreglar la radio.

Tarea 21: Salir del chroot limpiamente y desmontar en orden inverso

cr0x@server:~$ exit
cr0x@server:~$ umount -R /mnt/run
cr0x@server:~$ umount -R /mnt/dev
cr0x@server:~$ umount -R /mnt/proc
cr0x@server:~$ umount -R /mnt/sys
cr0x@server:~$ umount -R /mnt/boot/efi
cr0x@server:~$ umount -R /mnt/boot
cr0x@server:~$ umount -R /mnt/var
cr0x@server:~$ umount -R /mnt

Significado: No ver “target is busy” significa que tus montajes se liberaron limpiamente.

Decisión: Si un unmount se queja, encuentra qué lo mantiene (lsof o fuser) antes de reiniciar. Desmontajes sucios después de reparar el sistema de ficheros son como pasar de “lo arreglé” a “lo rompí”.

Broma #2: Lo bueno del modo de rescate es que puedes arreglar cualquier cosa. Lo malo es que también puedes arreglar cualquier cosa.

Tres mini-historias corporativas (cosas que realmente ocurren)

Incidente 1: La suposición equivocada (era “solo un reinicio de contraseña”)

Un equipo heredó una flota Debian de un proveedor. Un host dejó de aceptar SSH para el ingeniero on-call. El ingeniero asumió que la contraseña root estaba mal,
arrancó con un ISO de rescate, montó lo que parecía el volumen raíz y reseteó root.

El servidor aún no arrancaba. Seguía sin aceptar logins. La frustración creció, los cambios se multiplicaron. Alguien luego notó que el host tenía dos discos:
un disco pequeño del SO y un disco grande de datos, ambos ext4, ambos montables. El flujo de trabajo de rescate había montado el disco de datos en /mnt y reseteado una contraseña root
en un chroot equivocado que ni siquiera era el SO.

El problema real era una entrada obsoleta en /etc/fstab apuntando a un LUN iSCSI dado de baja. systemd esperaba y luego cayó en emergency mode.
El acceso root nunca fue el obstáculo; el sistema no llegaba a un target utilizable.

Recuperaron restaurando los montajes correctos, añadiendo nofail y un timeout corto para volúmenes no críticos, y reiniciaron.
Luego rotaron credenciales correctamente—porque, de hecho, habían cambiado una contraseña en el sistema de ficheros equivocado y crearon un problema de cumplimiento.

La lección no fue “ten cuidado.” Ese es un consejo barato. La lección fue imponer un procedimiento: siempre identificar la raíz vía findmnt/lsblk y confirmar
que /mnt/etc/os-release coincide con la instalación esperada antes de cualquier cambio de credenciales.

Incidente 2: La optimización que salió mal (el endurecimiento de auth tumbó todo el sitio)

Otra empresa decidió estandarizar la seguridad de login. Aplicaron un cambio a PAM para forzar mayor complejidad de contraseña y bloqueos.
Parecía razonable en la revisión de código: solo un par de líneas de módulo en /etc/pam.d/common-auth.

Un subconjunto de servidores falló en logins inmediatamente después de una actualización rutinaria y reinicio. La consola mostraba contraseñas correctas siendo rechazadas.
Root no estaba “bloqueado”; era simplemente imposible autenticarse porque un módulo PAM referenciado no existía en esos hosts.

¿Por qué el subconjunto? Algunos servidores se construyeron desde una imagen base reducida donde módulos PAM opcionales no estaban instalados.
La optimización fue “reducir la huella de paquetes”, y tuvo éxito hasta que alguien asumió que la pila de autenticación era idéntica en todas partes.

La recuperación usó modo rescate y chroot para reinstalar paquetes faltantes y revertir la configuración PAM a la línea base conocida y buena.
Tras el incidente, dividieron los cambios de PAM en dos fases: desplegar paquetes primero, validar presencia de módulos y luego activar la configuración. Aburrido. Correcto.

Incidente 3: La práctica aburrida pero correcta que salvó el día (notas y montajes solo lectura)

Un nodo de base de datos en producción dejó de arrancar después de una actualización de kernel. Cayó en emergency mode con salida mínima en la consola remota.
El on-call principal hizo algo heroico: nada. No empezó a editar; empezó a documentar.

Montó la raíz en solo lectura, sacó los últimos errores de arranque del journal y encontró que el sistema no lograba desbloquear un volumen cifrado.
La imagen initramfs se había generado sin la integración correcta de cryptsetup después de una actualización parcial.

Como montaron en solo lectura primero, evitaron escrituras de journaling y replay en una pila de almacenamiento ya bajo sospecha.
Luego remontaron en lectura-escritura solo para reconstruir initramfs y actualizar la configuración de GRUB, usando un chroot limpio con bind mounts.

La máquina arrancó bien. El postmortem fue casi indoloro porque el on-call tenía una línea de tiempo y una lista de comandos ejecutados.
Sin misterio. Sin folklore. Solo una reparación que coincidía con la evidencia.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “la contraseña root es correcta pero el login falla en todas partes”

Causa raíz: Mala configuración de PAM o módulo PAM faltante (después de upgrades, limpieza o ediciones manuales).

Solución: En chroot, valida los archivos PAM bajo /etc/pam.d. Reinstala paquetes de auth faltantes, revierte a la configuración base y prueba con consola local tras reiniciar.

2) Síntoma: Caída a emergency mode, pide contraseña root para mantenimiento

Causa raíz: Un montaje fallido en /etc/fstab (UUID equivocado, disco ausente, almacenamiento de red lento) bloqueó local-fs.target.

Solución: Monta la raíz y examina /etc/fstab. Corrige UUIDs con blkid, o marca montajes no críticos como nofail con un timeout corto.

3) Síntoma: sudo dice “no valid sudoers sources found” o “parse error”

Causa raíz: Error de sintaxis o permisos/propiedad incorrectos en /etc/sudoers o /etc/sudoers.d/*.

Solución: Usa visudo -c en chroot. Arregla el archivo problemático y asegura permisos correctos (típicamente 0440) y propiedad root.

4) Síntoma: SSH rechazado tras “endurecimiento rápido”

Causa raíz: sshd_config inválido, claves del host faltantes o permisos de archivos en ~/.ssh erróneos.

Solución: Valida la config con sshd -t. Confirma que las claves del host existen en /etc/ssh. Revisa permisos y propiedad de authorized_keys.

5) Síntoma: Después de resetear contraseña en rescate, el sistema sigue denegando login root

Causa raíz: Reseteaste la contraseña en el filesystem montado equivocado, o root está configurado para prohibir login por contraseña (política), o PAM lo bloquea.

Solución: Confirma que montaste la raíz correcta (revisa /etc/os-release, hostname y UUIDs de disco). Confirma la política en PAM/sshd y ajusta la capa correcta.

6) Síntoma: “Authentication token manipulation error” al ejecutar passwd

Causa raíz: El filesystem raíz montado en solo lectura, o permisos/propiedad de /etc/shadow rotos, o el sistema de ficheros está sin espacio/inodos.

Solución: Remonta en lectura-escritura intencionalmente, arregla modo/owner/group de /etc/shadow y revisa espacio libre con df -h y df -i.

7) Síntoma: El sistema arranca, pero servicios fallan y sudo se cuelga

Causa raíz: DNS roto o configuración NSS (por ejemplo, apuntando a LDAP/SSSD muerto) causando bloqueos; sudo a menudo dispara resolución usuario/grupo.

Solución: En rescate/chroot, inspecciona /etc/nsswitch.conf, configuración SSSD, y asegura que la autenticación local aún funcione. Considera deshabilitar temporalmente dependencias de auth remota para recuperar control.

8) Síntoma: Bucle de arranque después de actualización de kernel, no llega al prompt de login

Causa raíz: initramfs sin drivers de almacenamiento, crypttab roto, o módulos del kernel incompatibles.

Solución: Arranca un kernel anterior desde GRUB si está disponible. En rescate, chroot y ejecuta update-initramfs -u -k all, luego update-grub.

Listas de verificación / planes paso a paso

Plan A: Solo necesitas recuperar root (sin problemas de arranque/almacenamiento)

1. Arranca el target de rescate desde GRUB o el rescate del instalador.
2. Ejecuta lsblk e identifica el volumen raíz correcto.
3. Monta la raíz en solo lectura en /mnt. Confirma que /mnt/etc/os-release coincide con el host que crees que es.
4. Monta /boot, /boot/efi y /var si están separados.
5. Bind mounts /dev, /proc, /sys, /run, luego chroot.
6. Comprueba el estado de root: passwd -S root y chage -l root.
7. Establece una contraseña temporal fuerte para root: passwd root.
8. Valida sudoers: visudo -c. Arregla si es necesario.
9. Sal del chroot, desmonta limpiamente, reinicia.
10. Tras el login, rota credenciales correctamente y documenta lo cambiado.

Plan B: El sistema cae en emergency mode (bloqueadores fstab/montaje)

1. No restablezcas contraseñas todavía. Trátalo como incidente de dependencias de arranque.
2. Monta la raíz en solo lectura y lee el journal para los últimos errores de arranque.
3. Inspecciona /etc/fstab en busca de UUIDs obsoletos, montajes de red no alcanzables o discos faltantes.
4. Usa blkid para confirmar identificadores y corrígelos.
5. Para montajes no críticos, añade nofail y x-systemd.device-timeout=10s para evitar bloquear el arranque.
6. Remonta la raíz en lectura-escritura solo para aplicar el cambio mínimo.
7. Reinicia y valida que el arranque llegue al target multiusuario.

Plan C: Raíz cifrada/LVM que no se activa

1. En rescate, confirma que el dispositivo cifrado es visible (lsblk y dmesg).
2. Desbloquea con cryptsetup luksOpen; verifica el estado.
3. Activa LVM: vgscan, vgchange -ay.
4. Monta la raíz y chroot correctamente.
5. Revisa /etc/crypttab, hooks de initramfs y reconstruye initramfs.
6. Actualiza la configuración de GRUB si es necesario, luego reinicia.

Plan D: SSH está roto pero existe acceso local

1. Valida la configuración SSH con sshd -t (desde chroot si hace falta).
2. Confirma que las claves de host existen y que los permisos son correctos en /etc/ssh.
3. Prefiere restaurar el acceso por clave de un usuario admin conocido en lugar de habilitar el login por contraseña de root.
4. Sólo después de que el acceso sea estable, considera ajustes de política y endurecimiento.

FAQ

1) ¿Debo usar rescue.target o emergency.target?

Usa rescue.target cuando quieras un sistema mínimo pero con más servicios y montajes normales.
Usa emergency.target cuando los montajes están rotos o sospechas que fstab es lo que te deja caer; reduce dependencias y te da un shell más rápido.

2) ¿Resetear la contraseña root en modo de rescate es “seguro”?

Es seguro solo después de haber probado que montaste el sistema raíz correcto y que el sistema de ficheros está sano.
Es operacionalmente arriesgado porque cambia la postura de seguridad. Usa una contraseña temporal, regístrala de forma segura, róotala luego y considera volver a bloquear root si esa es tu política.

3) ¿Por qué obtengo “Authentication token manipulation error” de passwd?

La mayoría de las veces: el sistema de ficheros está montado en solo lectura, el disco está lleno o los permisos/propiedad de /etc/shadow están mal.
En modo rescate es común olvidar que montaste / como ro. Ese error te dice que no puede escribir en la base de credenciales.

4) ¿Puedo simplemente editar /etc/shadow directamente?

Puedes, pero no deberías salvo que sepas lo que haces. Usa passwd para que maneje hashing y locking del archivo correctamente.
Si debes editar, asegura permisos y formato correctos—una línea malformada puede romper inicios de sesión para todos.

5) Arreglé sudoers pero sudo sigue fallando tras reiniciar. ¿Por qué?

Revisa demoras en resolución de nombres (NSS/SSSD/LDAP) y lookup de grupos. sudo consulta membresía de usuario/grupo y puede colgar si proveedores de identidad remotos son inalcanzables.
Si es necesario, temporalmente asegura que la autenticación local en /etc/passwd//etc/group funcione.

6) ¿Cuándo debo ejecutar fsck o xfs_repair?

Ejecútalos cuando tengas evidencia: fallos de montaje, errores de I/O o mensajes del journal que indiquen corrupción.
Para sistemas ext, fsck es normal. Para XFS, usa xfs_repair (a menudo requiere estar desmontado). No ejecutes reparaciones en un filesystem montado a menos que la herramienta lo soporte explícitamente.

7) Estoy en una VM remota sin entrada de contraseña por consola para LUKS. ¿Qué hago?

Eso es una restricción de diseño, no un truco de rescate. Necesitas una forma de proporcionar la passphrase de forma remota (consola virtual), usar un keyfile con recuperación segura en tiempo de arranque,
o rediseñar el flujo de desbloqueo. El modo rescate puede ayudarte a diagnosticar, pero no puede conjurar un teclado que no tienes.

8) ¿Debo reinstalar GRUB como parte de la recuperación root?

No a menos que tengas un síntoma del gestor de arranque. Reinstalar GRUB es invasivo y puede ser disruptivo en setups de arranque complejos.
Si el sistema llega a un prompt de login, el gestor de arranque no es tu problema de acceso root.

9) ¿Cómo confirmo que monté la raíz correcta antes de cambiar algo?

Comprueba /mnt/etc/os-release, /mnt/etc/hostname y compara UUIDs de disco con tu inventario.
También verifica que existan los artefactos de arranque esperados (/mnt/boot) y que findmnt -R /mnt coincida con tu esquema de particiones conocido.

10) ¿Puedo recuperar añadiendo init=/bin/bash al arranque?

A veces, pero es tosca y evita la inicialización normal. También puede producir estados confusos con discos cifrados y expectativas de systemd.
Prefiere systemd.unit=emergency.target o el rescate del instalador, y luego haz una reparación limpia basada en chroot.

Siguientes pasos después de recuperar el acceso

Recuperar root no es la línea de meta; es recuperar la capacidad de hacer cambios deliberados. Haz tres cosas antes de declarar victoria:

1. Estabiliza el acceso: Asegura al menos dos rutas administrativas independientes (consola + SSH con claves para un usuario admin). Evita depender de una sola contraseña.
2. Arregla la causa raíz: Si el gatillo fue fstab, PAM, initramfs o una dependencia de proveedor de identidad, soluciónalo con un cambio que puedas justificar a partir de la evidencia.
3. Deja migas: Escribe lo que cambiaste, por qué y cómo revertir. Ponlo en un lugar que tu equipo realmente encuentre en el próximo incidente.

El mejor rescate es el que solo necesitas una vez. Después del incidente, invierte en particionado predecible, procedimientos de actualización probados y una política para root/sudo que esté documentada, aplicada y sea aburrida.
Lo aburrido es bueno. Los arranques aburridos también.