Bloqueo de 2FA en Proxmox: cómo evitarlo (y cómo recuperarse rápido)

Modelo mental: qué protege realmente la 2FA en Proxmox

La autenticación en Proxmox VE no es una sola cosa monolítica. Es una pila de componentes que coinciden en el formulario de inicio de sesión de la interfaz web. Si quieres prevenir un bloqueo —y recuperarte limpiamente cuando ocurra— necesitas saber en qué capa estás fallando.

Capas que importan

• Realms definen dónde viven los usuarios: pam (usuarios de Linux vía PAM), pve (interno de Proxmox), además de opciones externas como LDAP/AD.
• Usuarios son identificadores cualificados por realm como alice@pam o ops@pve.
• Métodos 2FA (TOTP, WebAuthn, códigos de recuperación, etc.) se vinculan a un usuario, no a un nodo. En un clúster, eso importa.
• El plano de gestión es principalmente la API y la UI de Proxmox (pveproxy/pvedaemon). Perderlo no apaga las VM, pero bloquea tu capacidad de gestionarlas.
• Acceso root (consola local/SSH) es el verdadero break‑glass. Si pierdes también root, no estás solucionando 2FA: estás haciendo recuperación del host.

Aquí va la verdad incómoda: un “bloqueo por 2FA” frecuentemente no trata sobre la 2FA. Trata sobre la plomería de identidad. El responsable de guardia no puede autenticarse porque el realm no puede validar contraseñas, el reloj del nodo está mal, la UI está caída o la configuración 2FA del usuario está medio eliminada y ahora rechaza todo.

Idea parafraseada de Werner Vogels: Todo falla, todo el tiempo—diseña para la recuperación, no para la perfección.

Y sí, Proxmox es bastante bueno en la recuperación—si te preparaste. Si no lo hiciste, Proxmox te enseñará la diferencia entre “configuración segura” y “apagón autoinfligido.”

Datos y contexto interesantes (por qué esto sale mal)

1. TOTP es dependiente del tiempo, no mágico. Depende de que el reloj del servidor esté correcto. Unos minutos de deriva pueden parecer “2FA roto”.
2. La 2FA se generalizó porque las contraseñas fallaban a escala. El gran salto ocurrió en la década de 2010 cuando el phishing y la reutilización de credenciales se industrializaron.
3. PAM es anterior a la 2FA moderna por décadas. Linux PAM (Pluggable Authentication Modules) es un marco más antiguo que puede integrar muchos métodos de autenticación, pero las mala configuraciones son… atemporales.
4. El realm pam de Proxmox significa “cuentas del sistema”, así que tus usuarios de Linux y sus políticas de contraseña importan. ¿Deshabilitar SSH para root? Bien. ¿Perder la consola root? No está bien.
5. Los clústeres amplifican los errores de identidad. Un cambio que rompe la autenticación en un nodo puede dejarte varado si ese nodo es el único accesible.
6. La adopción de U2F/WebAuthn creció porque TOTP es phishable. Pero WebAuthn introduce un riesgo diferente: perder la llave física sin respaldo.
7. Los códigos de recuperación son más antiguos de lo que la mayoría piensa. Los servicios de consumo los usaron temprano porque los desks de soporte necesitaban una forma no telepática de ayudar a usuarios bloqueados.
8. Las políticas de “2FA en todas partes” a menudo olvidan las cuentas de servicio. Se endurecen los inicios de sesión humanos, la automatización falla y alguien “temporalmente” desactiva controles durante una crisis.

Cómo evitar el bloqueo por 2FA: las reglas que aplico

Regla 1: Necesitas una vía break‑glass probada que no dependa de la misma 2FA

No confundas “tener root” con “tener un plan break‑glass.” Un plan es algo que puedes ejecutar a las 03:00 mientras tu responsable te observa por encima del hombro.

El patrón práctico es:

• Al menos dos identidades de administrador que puedan alcanzar el clúster, almacenadas en un gestor de contraseñas con acceso auditado.
• Al menos una forma fuera de línea de completar el segundo factor o omitirlo legítimamente (códigos de recuperación, segunda llave hardware o un proceso controlado de reinicio de 2FA).
• Al menos una vía de acceso fuera de banda al host (IPMI/iDRAC/iLO, KVM‑over‑IP o consola física) que evite completamente la UI web.

Regla 2: Nunca hagas que “el único admin” se registre en 2FA sin que otro admin esté listo

Si hay exactamente una cuenta con derechos Administrator y activas 2FA en ella, estás a un dedo gordo de un corte del plano de gestión. Inscribe la 2FA como operación de dos personas: una cambia, la otra verifica y permanece conectada hasta confirmar la recuperación.

Regla 3: Trata la sincronización de tiempo como parte de la autenticación

En Proxmox, la deriva de tiempo no es “un problema de monitorización.” Es “la autenticación puede fallar.” Ejecuta NTP/chrony en todas partes, verifícalo tras reinicios y monitoriza la deriva.

Regla 4: Almacena los datos de recuperación 2FA como las claves host SSH: con cuidado, fuera de línea y con control

Los códigos de recuperación no deberían vivir en un chat compartido. Ponlos en una bóveda del gestor de contraseñas con registro de acceso, o en un almacén cifrado fuera de línea en una caja fuerte. Hazlo aburrido. Lo aburrido es bueno.

Regla 5: No elimines redundancia en nombre de la “limpieza”

A la gente le encanta “limpiar cuentas antiguas.” Genial. Hazlo después de verificar que las cuentas remanentes aún pueden autenticarse, seguir administrando y tienen respaldos 2FA funcionales. El cementerio está lleno de directorios de identidad pulcros.

Broma corta #1: La autenticación de dos factores es genial hasta que tu segundo factor decide tomarse vacaciones sin pedir permiso.

Guion de diagnóstico rápido

Esta es la secuencia de “deja de adivinar”. Está diseñada para decirte si el cuello de botella es (a) tú, (b) el tiempo, (c) el realm, (d) los servicios de Proxmox o (e) la red.

Primero: confirma que fallas en autenticación, no en conectividad

• ¿Puedes alcanzar el puerto de la UI del nodo (8006)?
• ¿El error del navegador es un problema HTTP/TLS o un rechazo de autenticación?
• ¿Otros usuarios también fallan?

Segundo: verifica el tiempo y la salud básica del host

• Revisa el estado de sincronización NTP y la hora actual.
• Comprueba que pveproxy y pvedaemon estén en ejecución.
• Revisa el espacio en disco (sí, en serio). Los discos llenos rompen cosas extrañas.

Tercero: identifica qué realm está implicado y si es accesible

• @pam depende de Linux PAM/contraseñas.
• @pve depende de la autenticación interna de Proxmox.
• Los realms LDAP/AD dependen de la red + salud del directorio + confianza TLS.

Cuarto: decide si necesitas un “login break‑glass” o un “restablecimiento de 2FA”

• Si tienes una sesión de admin abierta en otro sitio, úsala para reparar.
• Si no, usa la consola root/SSH para reparar ajustes de identidad y la configuración 2FA.

Quinto: contiene el riesgo

• No desactives controles de seguridad globalmente si solo necesitas resetear un usuario.
• No reinicies servicios del clúster al azar. Reinicia el componente mínimo necesario, con un plan de rollback.

Tareas prácticas: comandos, salidas y decisiones

Estas son tareas prácticas que realmente ejecuto. Cada una incluye qué significa la salida y qué decisión tomar a partir de ella. Ejecútalas en la shell de un nodo Proxmox como root (o vía sudo) a menos que se indique lo contrario.

Tarea 1: Confirma que el reloj del nodo es razonable (TOTP depende de ello)

cr0x@server:~$ timedatectl
               Local time: Fri 2025-12-26 13:42:11 UTC
           Universal time: Fri 2025-12-26 13:42:11 UTC
                 RTC time: Fri 2025-12-26 13:42:11
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Significado: Si System clock synchronized es no, los códigos TOTP pueden no validarse nunca.

Decisión: Si no está sincronizado, arregla el tiempo primero (chrony/ntp) y vuelve a intentar iniciar sesión antes de cambiar cualquier configuración de autenticación.

Tarea 2: Verifica la calidad de sincronía de chrony (la deriva puede ser sutil)

cr0x@server:~$ chronyc tracking
Reference ID    : 8A2B3C4D (ntp1.internal)
Stratum         : 3
Ref time (UTC)  : Fri Dec 26 13:41:58 2025
System time     : 0.000012345 seconds slow of NTP time
Last offset     : -0.000010221 seconds
RMS offset      : 0.000035000 seconds
Frequency       : 12.345 ppm fast
Residual freq   : -0.001 ppm
Skew            : 0.120 ppm
Root delay      : 0.003210 seconds
Root dispersion : 0.001900 seconds
Update interval : 64.0 seconds
Leap status     : Normal

Significado: Desplazamientos en milisegundos están bien; segundos no lo están. El estado de leap debería ser Normal.

Decisión: Si el offset es grande o el estado de leap no es Normal, arregla NTP y considera revisar la fuente de reloj del hipervisor si esto es una VM.

Tarea 3: Verificar que el servicio de UI de Proxmox esté activo

cr0x@server:~$ systemctl status pveproxy --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: active (running) since Fri 2025-12-26 13:12:02 UTC; 30min ago
   Main PID: 1456 (pveproxy)
      Tasks: 4 (limit: 6144)
     Memory: 120.5M
        CPU: 18.233s
     CGroup: /system.slice/pveproxy.service
             ├─1456 pveproxy
             └─1457 pveproxy worker

Significado: Si no está en ejecución, no estás bloqueado por 2FA; estás bloqueado por falla de servicio.

Decisión: Si está inactivo/fallado, inspecciona logs y reinicia pveproxy; no toques 2FA aún.

Tarea 4: Revisa también el demonio de autenticación (respalda la API)

cr0x@server:~$ systemctl status pvedaemon --no-pager
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled)
     Active: active (running) since Fri 2025-12-26 13:12:00 UTC; 30min ago
   Main PID: 1410 (pvedaemon)
      Tasks: 4 (limit: 6144)
     Memory: 78.1M
        CPU: 10.104s
     CGroup: /system.slice/pvedaemon.service
             ├─1410 pvedaemon
             └─1411 pvedaemon worker

Significado: Si pvedaemon está caído, las peticiones de auth pueden fallar de formas que parecen problemas de inicio de sesión.

Decisión: Si está fallando, arregla el demonio y prueba de nuevo antes de ajustar usuarios.

Tarea 5: Mira errores recientes de autenticación en logs

cr0x@server:~$ journalctl -u pveproxy -u pvedaemon --since "1 hour ago" --no-pager | tail -n 40
Dec 26 13:25:10 pve1 pveproxy[1457]: authentication failure; rhost=192.0.2.44 user=ops@pve msg=TOTPs rejected
Dec 26 13:25:12 pve1 pveproxy[1457]: failed login attempt: user 'ops@pve' - authentication failure
Dec 26 13:28:01 pve1 pveproxy[1457]: authentication failure; rhost=192.0.2.44 user=alice@pam msg=PAM authentication failed
Dec 26 13:30:22 pve1 pvedaemon[1411]: worker failed: unable to get local IP address

Significado: Esto te dice si la falla es rechazo de TOTP, fallo de PAM o rarezas de servicio/red subyacentes.

Decisión: Si es rechazo de TOTP, verifica el tiempo y la configuración 2FA del usuario. Si es fallo de PAM, revisa la cuenta/contraseña de Linux y la pila PAM. Si son errores de red/hostname, arregla la red/DNS del host.

Tarea 6: Confirma que no estás sin disco (porque todo se rompe cuando los discos se llenan)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/mapper/pve-root   94G   91G  1.2G  99% /

Significado: Al 99% entras en territorio de “fallos aleatorios”. Renovaciones de certificados, logs y escrituras de configuración pueden fallar.

Decisión: Libera espacio de inmediato (vacía logs, elimina ISOs viejas, poda backups) antes de cambiar ajustes de autenticación.

Tarea 7: Lista usuarios de Proxmox y ve en qué realm viven

cr0x@server:~$ pveum user list
userid        enable expire firstname lastname email
root@pam      1      0
alice@pam     1      0
ops@pve       1      0
auditor@pve   1      0

Significado: Puedes ver inmediatamente quién es interno (@pve) frente a sistema/PAM (@pam).

Decisión: Si tu único admin es un usuario de realm externo frágil, crea un admin local break‑glass en @pve o asegura el acceso de root@pam y pruébalo.

Tarea 8: Comprueba qué usuarios tienen derechos de administrador (no adivines)

cr0x@server:~$ pveum acl list | head -n 20
/ - user root@pam - role Administrator
/ - user ops@pve - role Administrator
/ - user auditor@pve - role PVEAuditor

Significado: Los ACL te dicen quién puede realmente arreglar el problema desde la UI/API.

Decisión: Si solo hay un Administrator, detente y añade un segundo antes de habilitar o cambiar políticas 2FA.

Tarea 9: Inspecciona la configuración 2FA a nivel de usuario

cr0x@server:~$ pveum user get ops@pve
userid: ops@pve
enable: 1
expire: 0
firstname: Operations
lastname: Team
email: ops@example.invalid
groups: admins
keys: 
totp:
  - id: totp1
    enable: 1
    created: 2025-07-10 09:21:33
    comment: primary phone

Significado: Esto muestra si TOTP está configurado y habilitado para ese usuario.

Decisión: Si el usuario no puede generar TOTPs válidos, necesitas un reinicio controlado: quitar/deshabilitar el TOTP obsoleto y registrar un nuevo factor.

Tarea 10: Comprueba los realms configurados (detecta dependencia LDAP/AD)

cr0x@server:~$ pveum realm list
realm    type   comment
pam      pam    Linux PAM standard authentication
pve      pve    Proxmox VE authentication server
corp     ldap   Corporate directory

Significado: Si tus admins se autentican vía corp y LDAP está caído, fallarás “misteriosamente” en inicios de sesión.

Decisión: Si un realm externo es obligatorio para acceso de admin, asegúrate de tener un admin local como fallback.

Tarea 11: Valida la ruta Linux/PAM para usuarios @pam

cr0x@server:~$ getent passwd alice
alice:x:1001:1001:Alice Admin,,,:/home/alice:/bin/bash

Significado: Si getent no encuentra al usuario, la autenticación PAM fallará. Si dependes de NSS/SSSD/LDAP, esto puede romperse con caídas de directorio.

Decisión: Si falta el usuario, arregla la fuente de identidad (usuario local, SSSD, LDAP) o usa una cuenta local break‑glass.

Tarea 12: Comprueba si SSH/root está disponible (chequeo de la realidad break‑glass)

cr0x@server:~$ ssh -o PreferredAuthentications=publickey root@127.0.0.1 'pveversion'
pve-manager/8.2.2/6f3a1d15 (running kernel: 6.8.12-2-pve)

Significado: Si puedes ejecutar esto localmente o vía tu red de gestión, puedes recuperar sin depender de la UI web.

Decisión: Si SSH/root no está disponible, debes usar consola fuera de banda (IPMI/iDRAC/iLO) o acceso físico—planifica en consecuencia.

Tarea 13: Confirma el estado de quórum del clúster (evita “arreglar auth” durante split‑brain)

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Dec 26 13:44:02 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.23
Quorate:          Yes

Significado: Si se pierde el quórum, algunas escrituras de configuración y operaciones de clúster se comportarán diferente. Los datos de auth pueden ser inconsistentes si estás en un mal estado de clúster.

Decisión: Si no hay quórum, estabiliza primero el clúster o realiza cambios en el nodo que actualmente tenga la configuración consistente (con extremo cuidado).

Tarea 14: Inspecciona inicios de sesión fallidos recientes en logs de auth del sistema (contexto PAM/SSH)

cr0x@server:~$ tail -n 30 /var/log/auth.log
Dec 26 13:28:01 pve1 pveproxy[1457]: pam_unix(pve:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=192.0.2.44  user=alice
Dec 26 13:28:01 pve1 pveproxy[1457]: authentication failure; rhost=192.0.2.44 user=alice@pam msg=PAM authentication failed

Significado: Confirma que los fallos de PAM son reales (contraseña incorrecta, cuenta bloqueada, directorio inaccesible), no “rarezas de 2FA”.

Decisión: Si PAM falla, arregla la cadena de autenticación de Linux (desbloquear cuenta, resetear contraseña, salud de SSSD) en lugar de tocar la 2FA de Proxmox.

Tarea 15: Comprueba si un usuario está deshabilitado o expirado (el bloqueo silencioso)

cr0x@server:~$ pveum user get auditor@pve
userid: auditor@pve
enable: 0
expire: 0

Significado: enable: 0 significa que la cuenta está deshabilitada. La gente confunde esto con fallos de 2FA.

Decisión: Vuelve a habilitar si procede, o usa otra cuenta de admin. No restablezcas la 2FA de un usuario que simplemente está deshabilitado.

Broma corta #2: “Voy a endurecer auth rapidito” es como acabas aprendiendo dónde están las llaves del centro de datos.

Rutas de recuperación cuando estás bloqueado

Hay dos clases de recuperación: arreglar el factor (tiempo, dispositivo, inscripción) o usar break‑glass para restablecer la configuración de la identidad. Tu trabajo es elegir lo menos invasivo que restaure acceso controlado.

Ruta de recuperación A: TOTP rechazado por deriva de reloj

Este es el caso más feliz. No necesitas eliminar la 2FA; necesitas corregir el tiempo.

• Arregla la sincronía NTP/chrony.
• No reinicies nada a menos que sea necesario.
• Vuelve a intentar iniciar sesión con un código TOTP nuevo (no reutilices el mismo).

Si la deriva de tiempo vuelve constantemente, investiga la pila de reloj: la BIOS, la fuente de reloj de la virtualización o la accesibilidad NTP. La deriva de tiempo es una causa raíz, no un rasgo de personalidad.

Ruta de recuperación B: usuario perdió el dispositivo autenticador, pero tienes otra sesión de admin

Si otro administrador está conectado, usa la UI o la CLI para restablecer la 2FA del usuario. Esto es lo mejor operativamente porque no cambias el comportamiento global de auth y dejas rastro en el historial de configuración y logs de Proxmox.

Desde la shell en un nodo, típicamente haces:

• Confirmar el usuario y sus entradas 2FA.
• Deshabilitar/eliminar las entradas TOTP antiguas.
• Requerir re‑inscripción y asegurar que se generen y almacenen códigos de recuperación.

Los subcomandos exactos varían por versión de Proxmox, pero el flujo es constante: identificar, quitar el factor roto, inscribir uno nuevo, probar el inicio de sesión y luego limpiar.

Ruta de recuperación C: no puedes acceder a la UI, pero tienes shell root (el break‑glass más común)

Si tienes root en un nodo (SSH o consola), puedes reparar usuarios de Proxmox y el estado 2FA directamente usando pveum y corrigiendo dependencias de realm subyacentes.

Pasos típicos:

1. Verifica la salud del host (tiempo, disco, servicios).
2. Confirma qué identidades admin existen (pveum user list, pveum acl list).
3. Si no tienes ninguna cuenta admin funcional, crea un usuario temporal @pve con contraseña fuerte, úsalo para iniciar sesión y luego rotealo y restringelo.
4. Restablece la configuración 2FA del usuario afectado.
5. Documenta lo ocurrido; no dejes cuentas de emergencia tiradas como herramientas cargadas.

Ruta de recuperación D: perdiste root y 2FA (ahora es recuperación del host)

Si nadie puede alcanzar root (SSH deshabilitado, consola inaccesible, contraseñas desconocidas), estás fuera de la “recuperación 2FA de Proxmox” y dentro de la “recuperación de acceso al servidor.” Eso implica iDRAC/IPMI, medios de rescate y potencialmente reinicios de contraseñas root. También es un problema de gobernanza: la empresa permitió un punto único de fallo en el acceso administrativo.

No “resuelvas” esto debilitando la autenticación permanentemente. Restáuralo recuperando el acceso root controlado y luego implementa un proceso real de break‑glass.

Ruta de recuperación E: fallo del realm externo (LDAP/AD caído)

Si los administradores se autentican vía LDAP/AD y el directorio está caído, puedes quedar efectivamente bloqueado sin que 2FA intervenga. Por eso existen cuentas admin locales. La solución correcta suele ser:

• Usar un admin local break‑glass (@pve o root@pam) para acceder al clúster.
• Reparar el realm externo (rutas de red, confianza TLS, DNS, salud del servicio).
• Sólo después de que vuelva la estabilidad, considera imponer el realm externo para todos.

Qué evito durante la recuperación

• Reinicios aleatorios de servicios durante un incidente de clúster. Reiniciar piezas relacionadas con corosync porque falló el login de la UI es operativa de culto de carga.
• Cambios de política global para deshabilitar la 2FA para todos los usuarios. Es un martillo grande tentador con cola larga de arrepentimiento.
• Hacerlo en vivo sin testigo para cambios de alto riesgo. Quieres una segunda persona que confirme que no acabaste de eliminar el último ACL de admin.

Tres microhistorias corporativas (cómo falla esto en la práctica)

Microhistoria 1: El incidente causado por una suposición equivocada

En una empresa SaaS mediana, el equipo de virtualización estandarizó en Proxmox para cargas internas. Tenían un realm de directorio externo configurado y la mayoría de usuarios se autenticaban vía LDAP. Parecía maduro: identidad central, offboarding coherente, menos contraseñas locales.

La suposición equivocada fue sutil: creyeron que porque la UI de Proxmox mostraba múltiples administradores, había múltiples administradores que podrían iniciar sesión durante una caída del directorio. En realidad, cada “admin” estaba en el realm externo. No había un admin local @pve, y SSH root se había deshabilitado en nombre del endurecimiento.

Luego ocurrió una rotación rutinaria de certificados del directorio. La cadena de CA se actualizó en la capa de directorio, pero los nodos Proxmox no recibieron el bundle de CA actualizado. Los binds LDAP empezaron a fallar. Proxmox no “funcionó parcialmente.” Simplemente rechazó todos los inicios de sesión admin, y el helpdesk lo declaró “2FA roto” porque el equipo había impuesto TOTP recientemente.

La recuperación tomó más tiempo del necesario porque lo trataron como un problema de aplicación en lugar de una dependencia de identidad. Finalmente usaron acceso por consola fuera de banda para iniciar sesión como root local, actualizaron stores de confianza, reiniciaron los servicios correctos y crearon un admin break‑glass @pve con contraseña en bóveda y acceso auditado.

El cambio después del incidente no fue “menos seguridad.” Fue seguridad explícita: si la identidad externa es obligatoria, el acceso de emergencia local debe existir y probarse trimestralmente.

Microhistoria 2: La optimización que volvió en contra

Una compañía financiera quiso reducir la “proliferación de credenciales.” Decidieron eliminar todas las cuentas locales de Linux en nodos Proxmox y exigir todo a través de usuarios internos de Proxmox con 2FA obligatorio. También configuraron reglas de firewall estrictas para que la UI web solo fuera accesible desde una subred de gestión.

Esto era ordenado. También creó una cadena frágil: la accesibilidad de la UI dependía de la subred de gestión, acceso por VPN y un camino de navegador funcionando. Mientras tanto, el acceso SSH para usuarios operativos se limitó y las pocas personas que podían alcanzar la consola eran del equipo de red.

Durante una ventana de mantenimiento de red, el concentrador VPN tuvo un problema y el acceso a la subred de gestión se rompió para el personal remoto. En la oficina, las pocas personas presentes no tenían roles de admin en Proxmox porque “los admins son SREs”. Los hosts de virtualización estaban bien; el plano de gestión no era accesible desde donde estaban los administradores. El equipo, en efecto, se optimizó hacia una esquina.

La solución no fue abrir todo. Mantuvieron el modelo de subred de gestión pero añadieron una segunda vía de acceso físicamente separada (bastion con controles estrictos), documentaron procedimientos de consola e introdujeron un pequeño número de admins on‑site break‑glass con llaves hardware almacenadas en un armario controlado.

La seguridad mejoró, no empeoró. La diferencia fue que se volvió resistente al mundo real, donde redes y humanos fallan simultáneamente de vez en cuando.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una organización de salud ejecutaba un clúster Proxmox con sistemas departamentales. El equipo tenía un runbook que a nadie le encantaba: pruebas trimestrales de break‑glass. Verificaban acceso por consola fuera de banda, confirmaban que un admin local @pve podía iniciar sesión, validaban que existían códigos de recuperación y comprobaban que al menos dos personas tenían permiso para acceder a la bóveda.

Un día, el teléfono de un admin fue borrado por una política MDM. Ese admin resultó ser quien hacía la mayor parte del trabajo de virtualización y su cuenta de Proxmox tenía TOTP obligatorio. Mal momento. ¿Su dispositivo TOTP de respaldo? También gestionado por la misma política MDM. Doble mala suerte.

No entraron en pánico. El ingeniero de guardia siguió el runbook: inició sesión con la cuenta break‑glass, confirmó la salud del clúster, restableció la 2FA del usuario afectado y exigió reinscripción inmediata con un segundo factor. El ticket del incidente se cerró antes de que pudiera convertirse en un “gran incidente”, porque nunca lo fue.

El informe post‑incidente fue aburrido también: “Prueba break‑glass exitosa; actualizar política MDM para evitar borrados simultáneos de factores; recordar a admins mantener códigos de recuperación offline.” En operaciones de producción, aburrido es el mayor cumplido.

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

1) Síntoma: “Código TOTP inválido” para todos

Causa raíz: deriva del reloj del nodo o NTP no sincronizado.

Solución: restaura la sincronía de tiempo (chrony/ntp), verifica que timedatectl muestre sincronizado y vuelve a intentar con un código nuevo.

2) Síntoma: solo los usuarios @pam no pueden iniciar sesión; los @pve sí

Causa raíz: problema PAM/NSS: usuario faltante, contraseña cambiada, SSSD/LDAP inaccesible o cuenta bloqueada.

Solución: valida con getent passwd y logs de auth; arregla la cadena de autenticación de Linux o usa un admin local @pve para seguir operando.

3) Síntoma: UI web inalcanzable, pero SSH funciona

Causa raíz: pveproxy caído, problema TLS, regla de firewall o condición de disco lleno bloqueando servicios.

Solución: comprueba systemctl status pveproxy, inspecciona logs, libera disco y reinicia solo el servicio fallido.

4) Síntoma: el inicio de sesión funciona en un nodo pero no en otro

Causa raíz: inconsistencia del clúster, problemas de quórum o fallo de servicio específico del nodo.

Solución: revisa pvecm status para el estado de quórum y atiende la salud del clúster; evita hacer cambios de auth durante particiones.

5) Síntoma: usuarios LDAP fallan tras una “actualización menor de certificado”

Causa raíz: cadena CA faltante en nodos Proxmox o validación TLS más estricta.

Solución: actualiza el bundle de CA de confianza en los nodos, verifica la configuración del realm y luego prueba binds e inicios de sesión.

6) Síntoma: comportamiento “usuario deshabilitado” confundido con bloqueo 2FA

Causa raíz: cuenta con enable: 0 o expirada.

Solución: inspecciona el estado del usuario con pveum user get, re‑habilita si está autorizado y valida los ACLs.

7) Síntoma: restableces 2FA y aún no puedes iniciar sesión

Causa raíz: realm equivocado seleccionado al iniciar sesión o nombre de usuario no coincide (p. ej., intentar alice en lugar de alice@pam).

Solución: verifica el ID de usuario exacto y el realm; asegúrate de que el formulario de login tenga el realm correcto.

8) Síntoma: la autenticación falla solo desde ciertas redes

Causa raíz: firewall/WAF/proxy interfiriendo, puerto 8006 bloqueado o interceptación TLS rompiendo la sesión.

Solución: confirma la ruta de red y el manejo de certificados; prueba desde la subred de gestión y desde el propio nodo.

Listas de verificación / planes paso a paso

Lista A: Antes de habilitar o imponer 2FA (haz esto una vez, hazlo bien)

1. Crea dos usuarios admin con factores independientes (dos teléfonos, o teléfono + llave hardware).
2. Genera y almacena códigos de recuperación fuera de línea bajo acceso controlado.
3. Confirma el acceso root@pam: consola y/o SSH vía bastion. Documenta el procedimiento.
4. Verifica la sincronía de tiempo en cada nodo (timedatectl, chronyc tracking).
5. Verifica que al menos una cuenta admin no dependa de LDAP/AD externo si no puedes garantizar la disponibilidad del directorio.
6. Realiza una prueba break‑glass: cierra sesión y vuelve a entrar usando el admin de respaldo y un factor diferente.
7. Escribe el rollback: qué comandos ejecutarás para quitar un factor roto y re‑habilitar el acceso.

Lista B: Si sospechas que estás bloqueado (contención primero)

1. Deja de cambiar cosas. Determina si esto es conectividad, salud de servicios o auth.
2. Revisa la sincronía de tiempo y el espacio en disco en un nodo.
3. Revisa estado y logs de pveproxy/pvedaemon para mensajes exactos de error de auth.
4. Identifica qué realm está fallando (@pam vs @pve vs LDAP).
5. Intenta iniciar sesión con un admin conocido‑bueno desde una ruta de red conocida‑buena.
6. Usa la shell root break‑glass solo si es necesario; mantén los cambios mínimos y reversibles.

Lista C: Restablecimiento controlado de 2FA para un usuario (la forma segura)

1. Confirma el ID de usuario y realm con pveum user list.
2. Confirma que el usuario tiene los ACLs requeridos; no restablezcas 2FA del usuario equivocado.
3. Captura evidencia: líneas de logs relevantes que muestren la razón del fallo.
4. Deshabilita/elimina el segundo factor roto del usuario usando las herramientas de gestión de usuarios de Proxmox.
5. Que el usuario se reinscriba inmediatamente, idealmente con dos factores.
6. Genera/almacena códigos de recuperación otra vez si aplica.
7. Confirma que el usuario puede iniciar sesión y realizar la mínima acción administrativa necesaria.
8. Cierra el ciclo: documenta lo ocurrido y cómo evitar repeticiones (política MDM, llave de respaldo, etc.).

Lista D: Endurecimiento post‑recuperación (no dejes un lío)

1. Rota cualquier contraseña de emergencia usada durante el incidente.
2. Revisa ACLs: asegúrate de que haya al menos dos admins válidos.
3. Reconfirma la sincronía de tiempo y las alertas de monitorización.
4. Audita logs por intentos de login sospechosos durante la ventana.
5. Programa una prueba break‑glass dentro de una semana—valida que tu “arreglo” no creó una nueva vía frágil.

Preguntas frecuentes

1) ¿La 2FA de Proxmox se almacena por nodo o por clúster?

En un clúster, la configuración de Proxmox se comparte efectivamente; la configuración de usuarios y auth debería ser consistente. Trata los cambios 2FA como de impacto en el clúster y verifica quórum antes de hacerlos.

2) ¿Cuál es el tipo de cuenta “break‑glass” más seguro: @pve o @pam?

@pve suele ser más seguro por su independencia de la gestión de usuarios del SO y problemas de directorio/NSS externos. Pero aún necesitas acceso shell root para operaciones break‑glass reales.

3) ¿Puede la deriva de tiempo realmente causar un bloqueo total?

Sí. La validación TOTP se basa en ventanas de tiempo. Si tu nodo está suficientemente desfasado, cualquier código correcto será rechazado. Arregla el tiempo antes de resetear factores.

4) Si LDAP está caído, ¿por qué parece un problema de 2FA?

Porque la UI solo ve “authentication failed.” Los usuarios entonces asumen que su código está mal. Los logs normalmente revelarán fallos de bind o errores PAM/NSS.

5) ¿Debería deshabilitar la 2FA globalmente durante un incidente?

Casi nunca. Deshabilita o reinicia la 2FA solo para el usuario afectado, y solo después de confirmar que la falla no es sincronía de tiempo o dependencia de realm. Desactivar globalmente es un incidente de seguridad esperando suceder.

6) ¿Qué hago si no puedo alcanzar la UI web pero sí el nodo por SSH?

Eso es un problema de servicio o de ruta de red, no de 2FA. Revisa pveproxy y espacio en disco, luego reinicia los servicios mínimos necesarios.

7) ¿Cuántos admins deberían tener acceso break‑glass?

Mínimo dos, idealmente tres en organizaciones más grandes, con acceso a la bóveda auditado. Uno es un punto único de fallo. Diez es un problema de control de acceso.

8) ¿Los códigos de recuperación reducen la seguridad?

Reducen el riesgo operativo si se almacenan correctamente. Si se almacenan inapropiadamente (texto plano, chat compartido) sí reducen la seguridad. El método de almacenamiento es la frontera de seguridad.

9) ¿Cuál es el mayor anti‑patrón operativo con 2FA en Proxmox?

Imponer 2FA sin validar acceso fuera de banda y sin un segundo admin que tenga un factor diferente. Eso no es endurecimiento; es apostar.

Conclusión: pasos siguientes que puedes hacer hoy

Si ejecutas Proxmox en producción, trata la 2FA como parte del diseño de disponibilidad, no solo de la postura de seguridad. Los bloqueos ocurren en la intersección de humanos, tiempo y plomería de identidad. No los previenes con esperanza. Los previenes con redundancia y ensayos.

Haz esto a continuación, en este orden:

1. Verifica la sincronía de tiempo en cada nodo y monitoriza la deriva.
2. Asegura que tienes al menos dos identidades Administrator, con factores segundos independientes.
3. Almacena códigos de recuperación fuera de línea bajo acceso controlado y prueba que puedes recuperarlos cuando no es una emergencia.
4. Confirma que el acceso por consola fuera de banda funciona y está documentado.
5. Realiza un ejercicio break‑glass trimestral y trata los fallos como incidentes reales.

El objetivo no es “evitar nunca quedar bloqueado.” El objetivo es hacer la recuperación predecible, auditable y rápida—para que la seguridad no se convierta en tiempo de inactividad.