Proxmox «Inicio de sesión fallido» al cargar la interfaz web: causas principales y soluciones

enero 1, 2026 • febrero 3, 2026 • Lectura: 25 min • Views: 11

¿Te fue útil?

Puedes hacer ping al host. La interfaz web se carga. La advertencia de certificado es el típico «lo resolveremos luego». Entonces escribes la contraseña que has escrito mil veces y obtienes la respuesta seca: Inicio de sesión fallido.

Este tipo de fallo hace perder tiempo porque parece un problema simple de contraseña. A veces lo es. Con frecuencia no. La interfaz es solo el mensajero, y no explica bien qué se rompió realmente. Vamos a hacer que se explique.

Guía de diagnóstico rápido (haz esto primero)

Si quieres el camino más rápido hacia la causa real, buscas una de tres cosas: realm equivocado, problemas de tiempo/ticket o autenticación en backend fallando. No empieces reiniciando servicios al azar. Lee los errores primero.

Paso 1 — Confirma que estás usando el realm correcto

Si inicias sesión como root, en la mayoría de despliegues quieres Realm = PAM, así que el nombre de usuario debería verse como root@pam.
Si tienes LDAP/AD configurado, puede que necesites user@yourrealm. La interfaz recuerda la última selección de realm, lo cual es útil hasta que no lo es.

Paso 2 — Mira los errores de autenticación donde realmente están

Abre una shell (consola, IPMI o SSH si aún es posible).
Observa los logs mientras intentas iniciar sesión. Si ves “authentication failure” con detalles, ya vas por delante de la interfaz.

Paso 3 — Verifica el desfase horario (el asesino silencioso)

Si el reloj del nodo está mal, los tickets pueden crearse y luego rechazarse inmediatamente por expirados o no válidos aún. Esto se presenta como “Inicio de sesión fallido” incluso con credenciales perfectas.

Paso 4 — Verifica que pveproxy y pvedaemon no estén atascados o mal configurados

La interfaz es solo JavaScript hablando con pveproxy (API) y sus aliados. Si los servicios están disgustados, obtendrás fallos genéricos.

Paso 5 — Si es un clúster, prueba desde otro nodo

En un clúster, la configuración de autenticación y la base de usuarios se comparten vía /etc/pve (pmxcfs). Si pmxcfs está malsano en un nodo, puede mostrar la interfaz pero comportarse de manera extraña con la autenticación y permisos.

Una verdad operativa: si no puedes iniciar sesión, no discutas con la interfaz. Pregunta al demonio. Te lo dirá, eventualmente.

La interfaz web de Proxmox VE es un cliente para la API REST. El flujo de inicio de sesión es, a grandes rasgos:

El navegador carga la interfaz desde pveproxy (puerto 8006).
Envías username@realm y contraseña (y posiblemente 2FA).
pveproxy pasa la autenticación al backend del realm seleccionado (PAM, PVE, LDAP/AD, OpenID, etc.).
En caso de éxito, Proxmox emite un ticket (cookie) y un token de prevención CSRF para llamadas a la API.
La interfaz usa ese ticket y token CSRF para operaciones posteriores.

Eso importa porque “Inicio de sesión fallido” no es una sola cosa. Podría significar:

El backend del realm rechazó las credenciales (problema real de contraseña/2FA).
El backend no es alcanzable (LDAP caído, problema TLS de AD, fallo DNS).
El ticket se creó pero el navegador no puede almacenarlo (desfase horario, rarezas con cookies, problemas de cabeceras en proxy inverso).
El nodo no puede leer su propia configuración de autenticación (problemas con pmxcfs, permisos en /etc/pve).

Un modelo mental útil: la interfaz se carga significa que TCP + TLS + disponibilidad básica del servicio están bien. El inicio de sesión funciona significa que el backend de autenticación, el tiempo y la gestión de tickets con estado también están bien. Capas diferentes. Modos de fallo diferentes.

Datos interesantes y contexto (por qué ocurren estos fallos)

Dato 1: El sistema de archivos de clúster de Proxmox (pmxcfs) se implementa como un sistema de archivos FUSE y está respaldado por corosync para distribución. Cuando está malsano, archivos “simples” como la configuración de usuarios dejan de ser simples.
Dato 2: El puerto por defecto de la UI/API de Proxmox es el 8006, elegido históricamente para evitar colisiones comunes con servidores web y appliances que ya usan 443/8443.
Dato 3: Proxmox diferencia entre usuarios PAM (cuentas del sistema), usuarios PVE (almacenados en la base de datos de Proxmox) y realms externos como LDAP/AD/OIDC. Elegir el incorrecto es la herida autoinfligida número 1.
Dato 4: La autenticación basada en tickets tiene una dependencia implícita en la corrección del tiempo. Los sistemas modernos de autenticación son alérgicos al desfase horario porque rompe la protección contra reproducción.
Dato 5: Muchos componentes de Proxmox están escritos en Perl (notablemente pveproxy y pvedaemon), lo que significa que los logs de fallo pueden ser muy específicos si te tomas la molestia de leerlos.
Dato 6: En despliegues en clúster, /etc/pve no es “solo configuración local”. Es un almacén de estado distribuido. Si corosync pierde quórum, las lecturas y escrituras de configuración pueden comportarse de forma diferente a lo esperado.
Dato 7: Los problemas del lado del navegador son reales: cookies obsoletas, JS en caché y extensiones de privacidad agresivas pueden romper el intercambio CSRF/token y parecer “Inicio de sesión fallido”. Raro, pero ocurre.
Dato 8: La interfaz de Proxmox dependía históricamente de ExtJS. Muchos comportamientos del frontend (incluida cierta gestión de errores) fueron modelados por las suposiciones de ese ecosistema sobre sesiones y tokens.

Principales causas cuando la interfaz se carga pero no puedes iniciar sesión

1) Realm equivocado (PAM vs PVE vs LDAP/AD vs OIDC)

La interfaz recuerda tu último realm. Eso es cómodo hasta que cambias de un usuario LDAP a root y olvidas cambiarlo de vuelta. Resultado: intentas root contra LDAP, falla y la interfaz hace un encogimiento de hombros.

Pista de diagnóstico: Si root “dejó de funcionar” de repente después de que añadiste un realm LDAP, esto es lo primero que reviso. La mayoría de las roturas “repentinas” de autenticación son en realidad estado de la interfaz.

2) Desfase horario o NTP roto (los tickets se invalidan)

El desfase horario no siempre aparece como “ticket expirado”. A veces es solo “Inicio de sesión fallido”. Si la batería RTC está muriendo o tu NTP está bloqueado, puedes tener un desfase suficiente para romper sesiones, validación TLS y coordinación del clúster.

3) PAM falla (cuenta bloqueada, expirada o problemas NSS)

La autenticación PAM puede fallar por razones más allá de la “contraseña equivocada”:

Cuenta bloqueada (pam_tally2 / faillock).
Contraseña expirada (especialmente si aplicaste políticas a cuentas del sistema).
Problemas de resolución NSS (raro si inyectaste LDAP para cuentas del sistema).

4) Desajuste de autenticación de dos factores o base de tiempo rota

TOTP se basa en tiempo. Si el reloj del servidor está mal, tu 2FA estará mal. Si usas WebAuthn, el comportamiento del navegador y del proxy inverso importa. Y si la interfaz pide “OTP” pero estás introduciendo la contraseña+OTP en un formato incorrecto para ese realm, fallará sin mucha guía.

5) Problemas con `pveproxy` / `pvedaemon` (servicio inestable o atascado)

Sí, la interfaz puede cargarse incluso si el backend tiene fallos parciales. Puedes obtener contenido estático y aún así fallar en las llamadas API de autenticación. Reiniciar servicios puede ayudar, pero trata los reinicios como analgésicos: útiles, no curativos.

6) Coincidencia incorrecta de certificado/clave tras restaurar o cambiar hostname/IP

Si restauraste un nodo desde backup, clonaste una VM con nueva identidad o cambiaste el hostname sin limpiar, puedes acabar con certificados desajustados o identidad de nodo obsoleta. Esto puede agravarse en clústeres.

7) Sistema de archivos de clúster (`/etc/pve`) no montado/sano

Si /etc/pve está malsano, la configuración de usuarios y realms puede no ser legible como esperas. El nodo puede seguir sirviendo la interfaz porque el servicio se inicia, pero la lógica de autenticación puede no encontrar lo que necesita.

8) Falla del realm externo de autenticación (LDAP/AD, OIDC)

Las fallas de LDAP/AD son clásicas: DNS defectuoso, problemas con la cadena de confianza TLS, contraseña del usuario bind expirada, firewall o una ventana de mantenimiento del controlador de dominio que nadie te avisó.

9) Rarezas de navegador/cookie/CSRF (menos común, pero real)

Cuando la interfaz carga pero inmediatamente “Inicio de sesión fallido” tras introducir credenciales correctas, prueba una ventana de incógnito o otro navegador. Si eso lo arregla, no arreglaste Proxmox; arreglaste el estado en el cliente.

Broma #1: Si tu plan de respuesta a incidentes es “vaciar caché del navegador”, no tienes un plan—tienes un ritual.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estos son los pasos que realmente hago en un nodo cuando la interfaz se carga pero la autenticación falla. Cada tarea incluye un comando, qué significa una salida típica y qué decisión tomar después. Ejecuta esto en el host Proxmox salvo que se indique lo contrario.

Task 1 — Confirma que los servicios están activos: pveproxy y pvedaemon

cr0x@server:~$ systemctl status pveproxy pvedaemon --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: active (running) since Tue 2025-12-23 09:11:04 UTC; 2h 18min ago
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled)
     Active: active (running) since Tue 2025-12-23 09:11:02 UTC; 2h 18min ago

Significado: Si alguno no está activo, la autenticación será poco fiable o inexistente.

Decisión: Si no se están ejecutando, revisa los logs (Task 2) antes de reiniciar. Si están activos, continúa con las comprobaciones de realm/tiempo.

Task 2 — Observa el log del proxy mientras intentas iniciar sesión

cr0x@server:~$ journalctl -u pveproxy -f
Dec 23 11:29:31 pve pveproxy[2154]: authentication failure; rhost=192.0.2.55 user=root@pam msg=failed to authenticate user
Dec 23 11:29:31 pve pveproxy[2154]: client denied: invalid credentials

Significado: “invalid credentials” apunta a realm/contraseña/2FA o bloqueos PAM.

Decisión: Si ves mismatch de realm o errores LDAP, salta a la sección relevante. Si ves errores de ticket/CSRF, ve a comprobaciones de tiempo y cookies.

Task 3 — Observa pvedaemon para errores más profundos de autenticación/permiso

cr0x@server:~$ journalctl -u pvedaemon -n 200 --no-pager
Dec 23 11:29:31 pve pvedaemon[2031]: authentication failure; user=root@pam msg=pam_authenticate failed: Authentication failure

Significado: Esto es un rechazo a nivel de backend (PAM en este ejemplo).

Decisión: Investiga el estado de PAM/cuenta (Tasks 9–11). Si pvedaemon muestra “permission denied reading /etc/pve,” investiga pmxcfs (Tasks 6–7).

Task 4 — Verifica la hora del nodo y la sincronización NTP

cr0x@server:~$ timedatectl
               Local time: Tue 2025-12-23 11:31:08 UTC
           Universal time: Tue 2025-12-23 11:31:08 UTC
                 RTC time: Tue 2025-12-23 11:31:07
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

Significado: “System clock synchronized: no” es sospechoso, especialmente en clústeres o con 2FA.

Decisión: Arregla la sincronización de tiempo antes de cualquier otra cosa. Si el tiempo está desviado minutos, espera fallos de tickets y problemas con corosync también.

Task 5 — Comprueba el estado de chrony (común en sistemas Debian)

cr0x@server:~$ chronyc tracking
Reference ID    : 203.0.113.10 (ntp1.example)
Stratum         : 3
Ref time (UTC)  : Tue Dec 23 11:30:58 2025
System time     : 0.842123 seconds slow of NTP time
Last offset     : -0.001993812 seconds
RMS offset      : 0.012340123 seconds
Frequency       : 12.345 ppm fast
Leap status     : Normal

Significado: Pequeños offsets están bien. Grandes offsets y “Leap status: Not synchronised” no lo están.

Decisión: Si no sincroniza, revisa firewall/DNS y tus servidores NTP. Si estás en un clúster, arregla el tiempo en todos los nodos.

Task 6 — Confirma que pmxcfs está montado y sano

cr0x@server:~$ mount | grep /etc/pve
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)

Significado: Si esto falta, la configuración de clúster de Proxmox no está montada; realms y usuarios pueden comportarse de forma extraña.

Decisión: Comprueba pve-cluster y corosync (Task 7). En una instalación de un solo nodo, pmxcfs aún debe estar montado.

Task 7 — Comprueba el estado del clúster/quórum (nodos en clúster)

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

Quorum information
------------------
Date:             Tue Dec 23 11:33:12 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.3a
Quorate:          Yes

Significado: Si Quorate: No, las lecturas/escrituras de configuración pueden estar restringidas y los síntomas pueden incluir raro comportamiento de autenticación dependiendo de qué falle.

Decisión: Arregla la red de corosync, la conectividad de nodos y el quórum. No “reinicies hasta que funcione”. Así conviertes un hipo en tiempo de inactividad.

Task 8 — Lista los realms y verifica cuáles existen

cr0x@server:~$ pveum realm list
Realm        Type    Comment
pam          pam
pve          pve
corp-ldap    ldap    Corporate LDAP

Significado: Si el realm que seleccionas en la interfaz no está aquí (o fue renombrado), tu intento de inicio de sesión está condenado.

Decisión: Usa un realm conocido bueno (a menudo pam) para acceso de emergencia, y luego arregla los realms externos.

Task 9 — Valida que la cuenta root no esté bloqueada a nivel OS

cr0x@server:~$ passwd -S root
root P 2025-11-04 0 99999 7 -1

Significado: El estado P normalmente indica que hay una contraseña utilizable. L indica bloqueada.

Decisión: Si está bloqueada, desbloquéala intencionalmente (Task 10). Si la contraseña expiró, establece una nueva de forma controlada.

Task 10 — Desbloquear root (si es tu intención) y establecer una contraseña

cr0x@server:~$ passwd -u root
passwd: password expiry information changed.

Significado: Root está desbloqueado. Es una decisión de seguridad, no solo técnica.

Decisión: Si tu política prohíbe inicios de sesión root, no hagas esto a la ligera. En su lugar, usa un usuario admin en el realm PVE o arregla tu proveedor de identidad.

Task 11 — Prueba PAM directamente (sin la interfaz)

cr0x@server:~$ pamtester login root authenticate
Password:
pamtester: successfully authenticated

Significado: Si la autenticación PAM funciona aquí pero falla en la interfaz, el problema puede ser la selección de realm, expectativas de 2FA o tickets/cookies/tiempo.

Decisión: Si PAM falla aquí también, tienes un problema de autenticación a nivel de SO (contraseña, bloqueo, cambios en la pila PAM).

Task 12 — Comprueba la base de usuarios de Proxmox (realm PVE)

cr0x@server:~$ pveum user list
UserID         Enable Expire
root@pam       1
admin@pve      1
ops@corp-ldap  1

Significado: Si tu usuario admin está deshabilitado o expirado, el inicio de sesión en la interfaz falla incluso si LDAP está bien.

Decisión: Habilita/extiende el usuario correcto. Si el usuario es externo, asegúrate de que el realm sea alcanzable.

Task 13 — Comprueba si 2FA está forzado para el usuario

cr0x@server:~$ pveum user get admin@pve
┌─────────────┬──────────┐
│ key         │ value    │
╞═════════════╪══════════╡
│ enable      │ 1        │
│ expire      │ 0        │
│ firstname   │          │
│ lastname    │          │
│ email       │          │
│ keys        │          │
│ groups      │          │
│ tokens      │          │
│ totp        │ 1        │
└─────────────┴──────────┘

Significado: Si TOTP está activado (o requerido por política), los inicios de sesión solo con contraseña fallan. Algunos usuarios olvidan que lo activaron hace meses.

Decisión: Usa el flujo OTP correcto, o desactiva temporalmente 2FA solo si tienes un procedimiento formal de acceso de emergencia.

Task 14 — Verifica que la API responda localmente (acota red vs autenticación)

cr0x@server:~$ curl -k -s https://127.0.0.1:8006/api2/json/version | sed 's/[{}]//g'
"data":"release":"8.2","repoid":"a1b2c3d4"

Significado: Si esto falla localmente, no tienes un “problema de navegador”. Tienes un problema de servicio (pveproxy caído, TLS o firewall local).

Decisión: Arregla pveproxy/escuchas antes de perseguir realms.

Task 15 — Intenta solicitar un ticket API con contraseña (aisla la GUI)

cr0x@server:~$ curl -k -s -d "username=root@pam&password=CorrectHorseBatteryStaple" https://127.0.0.1:8006/api2/json/access/ticket | head
{"data":{"username":"root@pam","ticket":"PVE:root@pam:...","CSRFPreventionToken":"b0c1..."}}

Significado: Si esto funciona, la ruta de autenticación del backend está bien; el problema puede ser la GUI/cookies/proxy inverso.

Decisión: Revisa cookies del navegador, cabeceras del proxy inverso y validez del tiempo. Si falla, vuelve a leer los logs con Task 2.

Task 16 — Comprueba problemas de cabeceras de proxy inverso (si pones Proxmox detrás)

cr0x@server:~$ grep -R "proxy_set_header" -n /etc/nginx/sites-enabled 2>/dev/null | head
/etc/nginx/sites-enabled/pve.conf:12:    proxy_set_header Host $host;
/etc/nginx/sites-enabled/pve.conf:13:    proxy_set_header X-Forwarded-Proto https;
/etc/nginx/sites-enabled/pve.conf:14:    proxy_set_header X-Forwarded-For $remote_addr;

Significado: Cabeceras Host o proto faltantes/incorrectas pueden romper el ámbito de la cookie, redirecciones y a veces el flujo de autenticación.

Decisión: Asegura que tu proxy inverso esté configurado específicamente para Proxmox y soporte WebSockets. Si no necesitas un proxy inverso, no lo añadas “por orden”.

Task 17 — Inspecciona reglas de firewall locales rápidamente

cr0x@server:~$ pve-firewall status
Status: enabled/running

Significado: Un firewall mal configurado puede bloquear LDAP/AD o NTP mientras aún permite 8006, produciendo “Inicio de sesión fallido” para realms externos.

Decisión: Si fallan realms externos, confirma acceso saliente a LDAP/DC/NTP.

Task 18 — Valida la conectividad del realm LDAP (cuando interviene LDAP/AD)

cr0x@server:~$ pveum realm sync corp-ldap
syncing users and groups...
ERROR: LDAP connection failed: Can't contact LDAP server

Significado: La identidad externa está caída o inalcanzable desde este host (DNS, enrutamiento, firewall, TLS, servidor caído).

Decisión: Repara red/DNS/TLS primero. No “arregles” esto creando usuarios locales a menos que estés ejecutando un plan documentado de acceso de emergencia.

Tres microhistorias corporativas (cómo los equipos se queman de verdad)

Microhistoria 1: El incidente causado por una suposición errónea

La empresa tenía un clúster Proxmox pulcro: tres nodos, almacenamiento compartido y LDAP integrado “estilo empresarial”. El equipo incorporó a un nuevo ingeniero on-call y les dijeron lo de siempre: “Inicia sesión con tu cuenta LDAP”.

Un mes después, durante un incidente de almacenamiento, el equipo de LDAP realizó mantenimiento planificado en controladores de dominio. Se suponía que sería transparente. No lo fue. Un DC volvió con una cadena de certificados antigua, el otro tenía retardo de replicación y el balanceador de carga tomó decisiones creativas. La interfaz web de Proxmox se cargó en todas partes, pero los inicios de sesión LDAP fallaron.

El ingeniero on-call probó con root. Tampoco funcionó. Asumieron que la contraseña root había sido rotada o perdida y escalaron a seguridad. Mientras tanto, el problema de almacenamiento empeoró porque nadie pudo cambiar límites de IO de VM ni migrar cargas.

La causa real fue dolorosamente pequeña: el formulario de inicio de sesión estaba en el realm LDAP, y el ingeniero escribió root sin @pam. Proxmox hizo exactamente lo que le indicaron: autenticar root contra LDAP. No existe ese usuario, no hay inicio de sesión.

Arreglaron la selección de realm, iniciaron como root@pam y estabilizaron el clúster. La acción del postmortem no fue “capacitar mejor”. Fue crear un usuario local de emergencia documentado en el realm PVE, con recuperación 2FA probada, e incluir “revisar el desplegable de realm” en el runbook. Aburrido. Efectivo.

Microhistoria 2: La optimización que salió mal

Otra organización puso Proxmox detrás de un proxy inverso corporativo. La meta era punto de entrada único, registro WAF y “TLS consistente”. Todo razonable. Luego alguien optimizó la configuración del proxy para imponer políticas de cookies agresivas y apretó el manejo de cabeceras porque la herramienta de cumplimiento marcó “valores por defecto inseguros”.

Un lunes, los usuarios informaron “Inicio de sesión fallido” intermitente. La interfaz se cargaba bien. A veces funcionaba tras un refresco; otras no. Los ingenieros reiniciaron pveproxy en dos nodos y lo “arreglaron” temporalmente, lo que les dio confianza y les hizo perder tiempo.

El fallo estaba en el manejo por parte del proxy de cabeceras y cookies. Bajo ciertas condiciones, el proxy cambiaba el esquema/host percibido, Proxmox emitía cookies con atributos que el navegador rechazaba y el intercambio CSRF/token fallaba. La única opinión de la interfaz: “Inicio de sesión fallido”.

La solución fue dejar de intentar ser muy listo. Se reconfiguró el proxy para pasar correctamente Host y X-Forwarded-Proto, preservar las cabeceras de upgrade de WebSocket y no manglear atributos de cookies. Tras eso, los inicios de sesión volvieron a ser aburridos—exactamente lo que quieres de la autenticación.

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

Un equipo que ejecutaba Proxmox para CI interno tenía la costumbre que parecía paranoica: cada trimestre validaban un inicio de sesión de emergencia en cada clúster. No “creemos que funcione”, sino una prueba real de inicio de sesión desde consola y UI, con checklist grabado.

Un día, su upstream NTP cambió y una regla de firewall bloqueó NTP saliente en una VLAN. Un nodo Proxmox derivó. No lo suficiente para provocar pánico—solo lo justo para hacer los tickets de autenticación inestables. La interfaz se cargaba, los inicios de sesión fallaban a veces y las sesiones se cortaban aleatoriamente.

Su monitor detectó el offset de reloj, pero la verdadera victoria fue procedimental: el runbook empezaba con comprobar timedatectl y chronyc tracking. Corrigieron la regla de firewall, forzaron un ajuste de tiempo y el problema desapareció.

Sin heroísmos. Sin reinicios de contraseñas de emergencia. No “Proxmox quizá esté roto”. Solo un sistema que se comporta de manera predecible y un equipo que se negó a improvisar arreglos de autenticación en producción.

Idea parafraseada (Gene Kranz): “Failure isn’t an option” es realmente sobre disciplina—buenos sistemas y procedimientos tranquilos reducen el espacio donde puede ocurrir una falla.

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

Esta sección es intencionalmente específica. Si puedes mapear tu síntoma a una fila, puedes dejar de adivinar.

1) “La contraseña root definitivamente funciona” pero el inicio de sesión falla al instante

Síntoma: La interfaz se carga, la contraseña es rechazada al instante, sin solicitud de OTP.
Causa raíz: Realm equivocado seleccionado (a menudo realm LDAP) por lo que root se autentica contra el backend equivocado.
Solución: Inicia sesión como root@pam con Realm “Linux PAM standard authentication”. Confirma realms con pveum realm list.

2) El inicio de sesión falla solo para usuarios LDAP/AD; los locales aún funcionan

Síntoma: root@pam funciona; user@corp-ldap no.
Causa raíz: Conectividad/TLS/DNS/firewall de LDAP, credenciales bind expiradas o mantenimiento de DC.
Solución: Ejecuta pveum realm sync corp-ldap e inspecciona errores. Verifica DNS y egress de firewall. Repara la cadena de confianza si usas LDAPS.

3) Ayer funcionaba; hoy falla en varios nodos

Síntoma: Varios usuarios reportan “Inicio de sesión fallido” con contraseñas correctas.
Causa raíz: Desfase horario (NTP roto), o outage del backend del realm (LDAP/OIDC caído).
Solución: Comprueba timedatectl y estado NTP. Si es realm externo, prueba conectividad desde los nodos. Arregla el tiempo primero, luego la identidad.

4) El inicio de sesión tiene éxito, luego la interfaz actúa como si hubieras salido

Síntoma: “Inicias sesión”, luego te rebotan o las acciones fallan con errores de permiso.
Causa raíz: La cookie no se almacena/devuelve por el proxy inverso o configuraciones de privacidad del navegador; a veces token CSRF no coincide por confusión de esquema/host.
Solución: Prueba acceso directo a https://node:8006. Prueba un perfil de navegador limpio. Corrige cabeceras del proxy inverso y ajustes de WebSocket.

5) La UI del nodo del clúster se carga, pero el inicio de sesión solo funciona en algunos nodos

Síntoma: Nodo A acepta inicio de sesión, Nodo B rechaza, mismo usuario.
Causa raíz: Desfase horario a nivel de nodo, problemas de montaje de pmxcfs o particionamiento parcial de corosync causando configuración obsoleta/parcial.
Solución: Compara tiempo y pvecm status. Verifica montaje de /etc/pve. Arregla transporte del clúster y restablece el quórum.

6) “Inicio de sesión fallido” tras habilitar 2FA

Síntoma: Antes la contraseña era aceptada; ahora siempre falla.
Causa raíz: OTP requerido pero no provisto/introducido correctamente; desfase horario en el servidor invalida OTP.
Solución: Arregla sincronización de tiempo. Confirma estado 2FA con pveum user get USER. Usa los métodos de recuperación según la política; no inventes nuevos en presión.

7) Tras restaurar/clonar, nadie puede iniciar sesión (o la UI se comporta de forma inconsistente)

Síntoma: Interfaz web accesible; autenticación falla o sesiones raras tras cambio de identidad de nodo.
Causa raíz: Mismatch de hostname, certificado/clave desajustados o identidad duplicada de nodo en un clúster.
Solución: Verifica resolución de hostname e identidad del nodo. En clústeres, asegura IDs de nodo únicos y consistencia en la config de corosync. Reemite certificados si hace falta (con precaución).

Broma #2: La autenticación es como un lector de credenciales corporativo—cuando falla, nunca es porque estás parado ahí lo bastante enojado.

Listas de verificación / plan paso a paso

Checklist A: Proxmox de nodo único, la UI se carga, el inicio de sesión falla

Prueba explícitamente root@pam. No confíes en la memoria del desplegable de realm.
Ejecuta journalctl -u pveproxy -n 100 y busca la razón exacta del fallo.
Confirma sincronización de tiempo: timedatectl y (si existe) chronyc tracking.
Prueba PAM directamente: pamtester login root authenticate.
Comprueba si root está bloqueado: passwd -S root.
Prueba creación de ticket API local con curl (Task 15). Si curl funciona pero la GUI no, sospecha navegador/proxy.
Si pones Proxmox detrás de un proxy inverso, evítalo y prueba acceso directo a :8006.
Sólo entonces considera reiniciar pveproxy/pvedaemon, y documenta por qué.

Checklist B: Proxmox en clúster, la UI se carga, fallo de inicio de sesión en un nodo

Comprueba el offset de tiempo en el nodo malo frente a uno bueno (timedatectl en ambos).
Revisa quórum y salud de corosync: pvecm status.
Verifica que /etc/pve esté montado: mount | grep /etc/pve.
Observa los logs de pveproxy mientras intentas iniciar sesión.
Si LDAP/AD: prueba sincronizar realm desde el nodo afectado (pveum realm sync). Problemas de segmentación de red suelen afectar a un solo nodo.
Confirma que el nodo no esté aislado por cambios de firewall (firewall de Proxmox y ACLs upstream).
Si el nodo no tiene quórum: no hagas cambios de configuración. Arregla el quórum primero.

Checklist C: Realms externos (LDAP/AD/OIDC) fallan de repente

Confirma que el login PAM local funciona (root@pam) para recuperar control.
Comprueba resolución DNS para los endpoints de identidad desde el nodo.
Verifica reglas de firewall salientes desde Proxmox hacia LDAP/DC/OIDC.
Busca cambios en TLS/cadena de confianza si usas LDAPS.
Valida que las credenciales bind no hayan expirado o sido rotadas sin actualizar Proxmox.
No “arregles” creando administradores locales al azar. Crea exactamente una cuenta de emergencia aprobada y monitoriza su uso.

Preguntas frecuentes

1) ¿Por qué se carga la interfaz web si la autenticación está rota?

Porque cargar la interfaz es en gran parte contenido estático servido por pveproxy. La autenticación es una llamada API separada que toca backends de realm y lógica de tickets.

2) ¿Cuál es la diferencia entre `root`, `root@pam` y `root@pve`?

root@pam es la cuenta root del sistema autenticada vía PAM. root@pve sería un usuario gestionado por Proxmox (si se crea), separado de las cuentas del SO.

3) Puedo hacer SSH como root, pero el inicio de sesión web falla. ¿Cómo puede ser?

SSH y la interfaz web pueden usar PAM, pero la UI también puede implicar 2FA, selección de realm y manejo de tickets/cookies. Además, la UI podría estar autenticando contra un realm distinto al que crees.

4) ¿Puede el desfase horario realmente causar “Inicio de sesión fallido” aun con contraseñas correctas?

Sí. Los tickets y TOTP son sensibles al tiempo, y hasta desvíos modestos pueden causar rechazo inmediato o comportamiento extraño de la sesión.

5) ¿Cómo sé si es un problema LDAP/AD versus un problema de Proxmox?

Si root@pam funciona pero user@corp-ldap falla, suele ser conectividad LDAP/AD, TLS, DNS o credenciales bind. Confírmalo con pveum realm sync corp-ldap y los logs.

6) ¿Un clúster sin quórum causa fallos de inicio de sesión?

Puedes verlo contribuir, especialmente si el estado de /etc/pve no es consistente o pmxcfs/corosync están malsanos. Es más común que se bloqueen operaciones de configuración, pero la autenticación y permisos pueden volverse confusos durante particiones.

7) ¿Debería reiniciar `pveproxy` cuando vea “Inicio de sesión fallido”?

Sólo después de haber comprobado logs y tiempo. Reiniciar puede enmascarar el problema subyacente (como desfase NTP o outage LDAP) y volverás a esto más enfadado.

8) ¿Qué pasa si la UI funciona accediendo directamente a `https://node:8006` pero falla detrás de un proxy inverso?

Entonces el proxy es el problema. Arregla las cabeceras reenviadas (Host, X-Forwarded-Proto), el manejo de upgrade de WebSocket y evita manglar cookies.

9) Habilité 2FA y ahora nadie puede iniciar sesión. ¿Cuál es la recuperación más segura?

Usa tu método de recuperación documentado (códigos de recuperación, cuenta de emergencia, acceso por consola). Si no tienes uno, créalo tras recuperarte—porque esto volverá a pasar.

10) ¿Cuál es la vía de acceso de emergencia más fiable?

Acceso por consola (físico/IPMI) más una ruta de administrador local (root@pam o un usuario admin PVE local) que no dependa de proveedores de identidad externos.

Conclusión: próximos pasos para evitar que se repita

Cuando Proxmox dice “Inicio de sesión fallido” pero la interfaz se carga, no estás frente a un misterio. Estás frente a un conjunto pequeño de modos de fallo previsibles: mismatch de realm, desfase horario, fallos del backend de autenticación, problemas del sistema de archivos del clúster y rarezas de token/proxy/navegador.

Haz esto a continuación:

Añade una entrada de runbook que empiece con: comprobación de realm, journalctl -u pveproxy, verificación de sincronización de tiempo.
Implementa y prueba acceso de emergencia: una ruta de administrador local que no dependa de LDAP/OIDC.
Monitorea el desfase horario en cada nodo. Alerta sobre desincronización NTP antes de que los tickets empiecen a fallar.
Si usas un proxy inverso, trátalo como código de producción. versiona, revisa y prueba flujos de inicio de sesión tras cambios.
En clústeres, monitoriza quórum y salud de corosync. La autenticación y la configuración viven en el mismo ecosistema de supuestos.

La interfaz es cortés. Los logs son honestos. Confía en el honesto.