Solucionar “Autenticación fallida” en Proxmox PBS: tokens, permisos y huellas

Guion de diagnóstico rápido

Cuando la auth de PBS se rompe, quieres el camino más corto a la verdad. No empieces rotando todo. Empieza por decidir
si esto es (a) el secreto incorrecto, (b) los permisos equivocados, o (c) la identidad del servidor equivocada (huella/cert).
Todo lo demás es adorno.

Primero: identifica dónde ocurre la falla (lado PVE vs lado PBS)

• Si PVE no puede alcanzar PBS en absoluto: es red, DNS, firewall, o el servicio API del PBS.
• Si PVE alcanza PBS pero recibe 401/403: es token/usuario/realm/ACL.
• Si PVE se queja de huella/certificado: es un desajuste de identidad TLS.

Segundo: clasifica el comportamiento tipo HTTP

• 401 Unauthorized: credenciales/token no aceptados (token equivocado, usuario equivocado, realm equivocado, token caducado/deshabilitado).
• 403 Forbidden: identidad aceptada, permisos denegados (ACL ausente, ruta equivocada, privilegio incorrecto).
• Handshake/TLS huella desajustada: estás hablando con el servidor equivocado o el servidor cambió de identidad.

Tercero: elige una acción segura

• Para 401: valida que el token se esté enviando, que pertenezca al usuario que crees y que no tenga restricciones que olvidaste.
• Para 403: mapea los privilegios requeridos a la ruta exacta de PBS (datastore, namespace, grupo de backups).
• Para errores de huella: verifica el certificado en PBS y luego actualiza la huella en PVE. No “simplemente aceptar” en una LAN de producción a menos que hayas verificado que no te están redirigiendo.

Una cita para tener en la pared:
Idea parafraseada (Werner Vogels): construyes sistemas suponiendo que fallarán, luego haces que se recuperen rápido y de forma segura.

Modelo mental: quién se autentica ante quién

Proxmox VE (PVE) no “inicia sesión” en PBS como un humano con navegador. Usa la API HTTP de PBS.
Esa llamada API incluye una identidad de autenticación (usuario o token), y PBS evalúa esa identidad frente a sus ACLs.
Por separado, PVE fija una huella TLS para que “pbs01” sea realmente tu PBS y no lo que respondió esa IP hoy.

Entonces “autenticación fallida” puede significar que cualquiera de estas capas falló:

1. Nombre y alcanzabilidad: DNS y enrutamiento al host y puerto de PBS.
2. Identidad TLS: desajuste de huella de certificado o fallo de confianza.
3. Autenticación: usuario/contraseña, o formato de cabecera de token, realm, estado del token.
4. Autorización: ACL de PBS y privilegios en la ruta de datastore, namespace, operaciones de mantenimiento.
5. Desajuste de capacidades: PVE espera una función (namespace, comprobación de propietario, cifrado) que la configuración de PBS prohíbe o no tiene.

La buena noticia: PBS y PVE son ruidosos en los logs si miras en el lugar correcto. La mala noticia: la burbuja de error de la GUI es inútil.
Trátala como una invitación a dejar de hacer clic y empezar a leer logs como un adulto.

Hechos y contexto interesantes (por qué es complicado)

• Hecho 1: PBS usa un modelo ACL basado en rutas. Los permisos se pueden otorgar en “/” o en un subárbol específico del datastore, y la herencia importa.
• Hecho 2: PVE fija la huella del certificado del servidor PBS para la definición de almacenamiento. Es una elección anti-MITM deliberada; no es solo ser exigente.
• Hecho 3: Los tokens API en el ecosistema Proxmox son identidades separadas con sus propios privilegios y restricciones opcionales. No son “contraseñas sin MFA”.
• Hecho 4: La distinción 401 vs 403 es oro operativo. 401 significa “¿quién eres?” y 403 significa “sé quién eres y no.”
• Hecho 5: Cuando restauras backups, PBS puede aplicar comprobaciones de propiedad y permisos diferente que al hacer backups. Podrías estar autorizado para escribir backups pero no para leer/restaurar.
• Hecho 6: La API de PBS corre por defecto en el puerto 8007. A la gente todavía le pasa apuntar PVE a 8006 por inercia, porque Proxmox te entrena que 8006 es “el puerto de Proxmox”.
• Hecho 7: Los cambios de huella a menudo correlacionan con reinstalación, reemplazo de host, regeneración de certificado, o “alguien limpió /etc/proxmox-backup” sin entender las consecuencias.
• Hecho 8: El soporte de namespaces en PBS introdujo control más granular y también más formas de negar acceso por accidente (un regalo para cumplimiento, una broma para operaciones).
• Hecho 9: Verificación de backups, pruning y garbage collection son operaciones privilegiadas. Un token que puede ejecutar backups puede todavía fallar en tareas de mantenimiento más adelante.

Qué suele significar realmente “autenticación fallida”

1) Realm equivocado o formato de identidad incorrecto

Las identidades de Proxmox son user@realm. Si creaste backup@pbs y luego configuraste backup@pam,
obtendrás una falla que parece un error de contraseña. No lo es.

2) El token existe, pero usaste el ID o secreto equivocado

Los tokens tienen dos partes: el identificador del token (como un sufijo de usuario) y el secreto del token (la cadena mostrada una sola vez).
Es fácil pegar el equivocado en un campo de contraseña y luego jurar que PBS está roto.

3) El token autentica, pero la ACL lo niega (403), la GUI oculta la diferencia

El problema más común de “funciona en un lugar pero no en otro”: el token puede listar datastores, pero no puede escribir snapshots,
o puede escribir pero no puede hacer prune, o puede respaldar VMs pero no contenedores (diferente tipo de contenido en el lado PVE, diferentes llamadas API).

4) Desajuste de huella tras reconstrucción o reasignación de IP

Si cambió el certificado del servidor PBS, PVE rechazará la conexión a menos que actualices la huella fijada.
Este comportamiento es correcto. Trata los desajustes de huella como los cambios de clave host SSH: verifica primero, luego actualiza.

5) Deriva de tiempo causa rarezas en tickets/tokens

PBS y PVE son sensibles al tiempo para sesiones y validaciones. Si un host se desincronizó porque NTP dejó de funcionar silenciosamente,
puedes tener fallos que desaparecen después de un reinicio (lo cual no es una solución; es un cara o cruz).

Broma #1: Las copias de seguridad son como paracaídas—si lo necesitas y no se abre, no estás “aprendiendo”, estás “cayendo”.

Tareas prácticas (comandos, significados de salida, decisiones)

Estas son las tareas que realmente ejecuto cuando falla la auth de PBS. Cada una incluye qué implica la salida y qué decisión tomar a continuación.
Ejecuta comandos en el host apropiado (PVE o PBS). No improvises; sigue las migas de pan.

Task 1: Confirma que incluso llegas al puerto API de PBS (PVE)

cr0x@pve01:~$ nc -vz pbs01 8007
Connection to pbs01 8007 port [tcp/*] succeeded!

Significado: El camino de red y el puerto son alcanzables.
Decisión: Sube en la pila hacia TLS y auth. Si falla, arregla DNS/enrutamiento/firewall/servicio antes de tocar tokens.

Task 2: Comprueba la salud del servicio API de PBS (PBS)

cr0x@pbs01:~$ systemctl status proxmox-backup-proxy
● proxmox-backup-proxy.service - Proxmox Backup Server Proxy
     Loaded: loaded (/lib/systemd/system/proxmox-backup-proxy.service; enabled)
     Active: active (running) since Fri 2025-12-26 00:11:04 UTC; 2h 9min ago

Significado: El proxy está en ejecución; PBS debería aceptar conexiones API.
Decisión: Si está caído, reinicia y revisa logs antes de culpar a la autenticación.

Task 3: Sigue los logs del proxy de PBS durante un intento fallido (PBS)

cr0x@pbs01:~$ journalctl -u proxmox-backup-proxy -f
Dec 26 02:13:21 pbs01 proxmox-backup-proxy[1872]: authentication failure; rhost=10.10.20.11 user=backup@pbs msg=invalid credentials
Dec 26 02:13:21 pbs01 proxmox-backup-proxy[1872]: failed login attempt: backup@pbs from 10.10.20.11

Significado: PBS recibió la petición y rechazó las credenciales (probablemente 401).
Decisión: Concéntrate en formato de identidad, realm, secreto del token, y si PVE usa token o contraseña.

Task 4: Comprueba “permiso denegado” vs “credenciales inválidas” (PBS)

cr0x@pbs01:~$ journalctl -u proxmox-backup-proxy --since "30 minutes ago" | tail -n 20
Dec 26 02:18:09 pbs01 proxmox-backup-proxy[1872]: user 'backup@pbs' failed to access /datastore/vmstore: permission check failed
Dec 26 02:18:09 pbs01 proxmox-backup-proxy[1872]: api request failed: 403 Forbidden

Significado: La identidad es válida; la autorización falló (403).
Decisión: Arregla las ACLs en la ruta del datastore/namespace; no rotar tokens.

Task 5: Verifica NTP/sincronización de tiempo en ambos lados (PVE y PBS)

cr0x@pve01:~$ timedatectl
               Local time: Fri 2025-12-26 02:20:31 UTC
           Universal time: Fri 2025-12-26 02:20:31 UTC
                 RTC time: Fri 2025-12-26 02:20:31
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active

Significado: El tiempo es razonable aquí.
Decisión: Si System clock synchronized: no en cualquiera de los hosts, arregla NTP primero. La deriva de tiempo crea falsos problemas de “auth”.

Task 6: Confirma la huella que PVE tiene fijada (PVE)

cr0x@pve01:~$ grep -R "fingerprint" /etc/pve/storage.cfg
pbs: pbs-vmstore
        server pbs01
        datastore vmstore
        username backup@pbs
        fingerprint 8A:12:6F:9C:AA:6E:9D:5A:5B:22:1C:77:41:9A:0E:1F:74:54:2B:11

Significado: PVE solo confiará en un PBS que presente esa huella.
Decisión: Si el certificado de PBS cambió, actualiza esta huella después de verificar la nueva en PBS.

Task 7: Obtén la huella actual del certificado de PBS (PBS)

cr0x@pbs01:~$ openssl x509 -in /etc/proxmox-backup/proxy.pem -noout -fingerprint -sha1
sha1 Fingerprint=8A:12:6F:9C:AA:6E:9D:5A:5B:22:1C:77:41:9A:0E:1F:74:54:2B:11

Significado: Esto es lo que PVE debería fijar.
Decisión: Si difiere de storage.cfg, actualiza la huella en la definición de almacenamiento de PVE (y pregunta por qué cambió el certificado).

Task 8: Comprueba que no estás alcanzando el host equivocado (PVE)

cr0x@pve01:~$ getent hosts pbs01
10.10.20.50   pbs01

Significado: DNS resuelve pbs01 a una IP.
Decisión: Si esta IP cambió recientemente, confirma que el nuevo host es realmente PBS y no una dirección reciclada o un balanceador.

Task 9: Verifica la identidad TLS en la conexión (PVE)

cr0x@pve01:~$ echo | openssl s_client -connect pbs01:8007 -servername pbs01 2>/dev/null | openssl x509 -noout -subject -fingerprint -sha1
subject=CN = pbs01
sha1 Fingerprint=8A:12:6F:9C:AA:6E:9D:5A:5B:22:1C:77:41:9A:0E:1F:74:54:2B:11

Significado: El servidor al que llegaste presenta un certificado con CN y huella mostrados.
Decisión: Si la huella difiere de lo que PBS reporta localmente, te están redirigiendo o hay un proxy en el medio.

Task 10: Confirma que el usuario PBS existe y está habilitado (PBS)

cr0x@pbs01:~$ proxmox-backup-manager user list
┌─────────────┬───────┬───────────┬────────┐
│ userid      │ enable│ expire    │ comment│
╞═════════════╪═══════╪═══════════╪════════╡
│ root@pam    │ true  │           │        │
│ backup@pbs  │ true  │           │ PVE jobs│
└─────────────┴───────────┴───────────┴────────┘

Significado: El usuario existe y está habilitado.
Decisión: Si está deshabilitado/caducado, corrígelo. Si el usuario no existe, para: te estás autenticando a una identidad de ficción.

Task 11: Confirma que el token existe y está habilitado (PBS)

cr0x@pbs01:~$ proxmox-backup-manager user token list backup@pbs
┌───────────────┬────────┬─────────┬──────────────┐
│ tokenid       │ enable │ expire  │ comment      │
╞═══════════════╪════════╪═════════╪══════════════╡
│ pve01         │ true   │         │ PVE node token│
└────────────────┴────────┴─────────┴──────────────┘

Significado: El token backup@pbs!pve01 existe y está habilitado.
Decisión: Si el token falta/está deshabilitado/caducado, emite uno nuevo y actualiza PVE. No sigas adivinando secretos.

Task 12: Inspecciona las ACLs relevantes al datastore (PBS)

cr0x@pbs01:~$ proxmox-backup-manager acl list
┌──────────────────────┬─────────────┬───────────┬─────────┐
│ path                 │ ugid        │ role      │ propagate│
╞══════════════════════╪═════════════╪═══════════╪═════════╡
│ /datastore/vmstore   │ backup@pbs  │ DatastoreBackup │ true │
│ /datastore/vmstore   │ backup@pbs!pve01 │ DatastoreBackup │ true │
└──────────────────────┴─────────────┴───────────┴─────────┘

Significado: La identidad tiene un rol asignado en la ruta del datastore.
Decisión: Si falta la ACL o apunta a la ruta equivocada, añádela. Si solo concediste en “/” pero deshabilitaste propagate, puede que te hayas cortado el acceso.

Task 13: Confirma que el datastore existe y está sano (PBS)

cr0x@pbs01:~$ proxmox-backup-manager datastore list
┌───────────┬───────────────┬──────────┬────────┐
│ name      │ path          │ comment  │ state  │
╞═══════════╪═══════════════╪══════════╪════════╡
│ vmstore   │ /mnt/pbs/vmstore │         │ ok     │
└───────────┴─────────────┴──────────┴────────┘

Significado: El datastore existe y PBS cree que está OK.
Decisión: Si falta o está en error, arregla el montaje/permisos del datastore primero; los errores de auth pueden ser ruido secundario.

Task 14: Prueba login a la API de PBS usando un token desde un nodo (PVE)

cr0x@pve01:~$ curl -sk -H "Authorization: PBSAPIToken=backup@pbs!pve01:REDACTED" https://pbs01:8007/api2/json/version
{"data":{"version":"3.2-1","release":"bookworm"}} 

Significado: El token es válido para acceso API y TLS funciona (porque obtuviste una respuesta).
Decisión: Si esto falla con 401, tu token/secreto/realm de usuario es incorrecto. Si falla con errores TLS, arregla huella/confianza del certificado.

Task 15: Detecta fallos 403 con una llamada API dirigida (PVE)

cr0x@pve01:~$ curl -sk -H "Authorization: PBSAPIToken=backup@pbs!pve01:REDACTED" https://pbs01:8007/api2/json/admin/datastore/vmstore/status
{"errors":"permission check failed"} 

Significado: El token autentica pero carece de privilegio para ese endpoint/ruta.
Decisión: Ajusta roles/ACLs para el token (preferible) o para el usuario (menos preferible) en el datastore correcto.

Task 16: Comprueba la corrección de la configuración de almacenamiento en PVE (PVE)

cr0x@pve01:~$ pvesm status
Name        Type     Status           Total            Used       Available        %
local        dir     active        19684264         6021132        13012000   30.59%
pbs-vmstore  pbs     active               0               0               0    0.00%

Significado: PVE ve el almacenamiento PBS como activo. Si está inactivo, revisa auth/huella.
Decisión: Si está activo pero los jobs fallan, céntrate en permisos del job de backup (snapshot/upload/prune) en lugar de conectividad básica.

Task 17: Valida qué identidad usa PVE para el almacenamiento PBS (PVE)

cr0x@pve01:~$ awk '/^pbs: /{f=1} f{print} /^$/{f=0}' /etc/pve/storage.cfg
pbs: pbs-vmstore
        datastore vmstore
        server pbs01
        username backup@pbs
        fingerprint 8A:12:6F:9C:AA:6E:9D:5A:5B:22:1C:77:41:9A:0E:1F:74:54:2B:11

Significado: Puedes comprobar la lógica del realm del usuario aquí.
Decisión: Si username es de un realm equivocado (pam vs pbs) o hay un error tipográfico, arréglalo y vuelve a probar antes de tocar ACLs.

Task 18: Busca fallos de login a nivel del backend de auth (PBS)

cr0x@pbs01:~$ journalctl --since "1 hour ago" | grep -E "failed login|authentication failure" | tail -n 10
Dec 26 02:13:21 pbs01 proxmox-backup-proxy[1872]: authentication failure; rhost=10.10.20.11 user=backup@pbs msg=invalid credentials

Significado: Confirma intentos repetidos y el valor de usuario que PBS ve.
Decisión: Si los logs de PBS muestran un usuario distinto del que esperas, has configurado mal PVE (o estás probando desde el host equivocado).

Tokens y ACLs: la pila de permisos que pica

Usuario vs token: elige tokens para máquinas

Usa tokens API para nodos PVE y automatización. Usa contraseñas para humanos. Los tokens reducen el radio de impacto y eliminan la
sorpresa de “alguien rotó la contraseña root@pam para satisfacer una política”.

Un modelo limpio típico se ve así:

• Crea un usuario PBS dedicado: backup@pbs (realm pbs, no pam).
• Crea un token por nodo PVE: backup@pbs!pve01, backup@pbs!pve02, etc.
• Concede roles ACL en el datastore específico (y namespace si se usa), no en “/”.
• Concede solo lo que el nodo necesita: backup, quizá verify, quizá prune—decídelo conscientemente.

Los roles no son decoración; son el contrato

Si quieres que los backups se ejecuten pero no permitir que un nodo comprometido borre el historial, no le des roles de admin amplios.
El enfoque correcto es conceder explícitamente un rol de backup y mantener prune/GC restringidos a una identidad de mantenimiento separada.
Esa separación es aburrida. Aburrido es bueno.

Donde la gente se lastima: prueba con root, funciona, luego “reducir permisos después”, y el “después” llega como un 403
en medio de la noche.

Trampas con namespace y propiedad

PBS puede segmentar datos con namespaces. Genial para configuraciones multi-tenant, o para separar entornos (prod vs dev) sin datastores adicionales.
También genial para crear un token que puede autenticarse pero no ve nada.

Si tu job apunta a un namespace, tu ACL debe coincidir con esa ruta de namespace. Otorgar permisos al root del datastore podría no ser suficiente
dependiendo de cómo lo hayas estructurado y si propagate está activado.

Huellas y TLS: cuando la seguridad hace su trabajo

Los errores de huella se sienten como burocracia hasta que recuerdas la alternativa: enviar silenciosamente tus backups al host de un atacante
porque alguien ARP-spoofeó tu VLAN o porque una IP fue reutilizada. PVE fija la huella del certificado de PBS para poder detectar “esto no es el mismo servidor.”
Eso no es paranoia. Es martes.

Razones legítimas por las que cambian huellas

• PBS fue reinstalado o reemplazado.
• El certificado se regeneró intencionalmente.
• El archivo proxy.pem fue reemplazado durante una restauración/migración.
• Alguien restauró un snapshot antiguo de /etc/proxmox-backup.
• Mudaste PBS detrás de un reverse proxy que termina TLS (usualmente mala idea para este caso).

Razones malas por las que cambian huellas

• “Limpiamos certificados por seguridad.”
• “Reimplementamos la VM desde plantilla y asumimos que sería la misma.”
• “Cambiamos el hostname y no pensamos que importara.”

El flujo de trabajo correcto es aburrido:
verificar la huella en PBS localmente, compararla con lo que PVE tiene fijado, y luego actualizar la definición de almacenamiento
si el cambio es legítimo. Si no puedes explicar el cambio, para e investiga. Las copias de seguridad son un límite de seguridad.

Broma #2: Las huellas TLS son como la seguridad aeroportuaria—molestas hasta el día en que agradeces que alguien hiciera preguntas.

Tres mini-historias corporativas desde las trincheras de backups

Incidente #1 (suposición errónea): “Está en la misma VLAN, así que está bien”

Una empresa mediana ejecutaba clusters PVE y una única VM PBS. Estaba en una VLAN de infraestructura “confiable”. El equipo asumió que eso significaba
que nadie jamás suplantaría PBS, así que la advertencia de huella en PVE se trató como una molestia.

Durante una limpieza de red, una dirección IP usada por PBS fue reasignada brevemente a otro host. Ese host no era malicioso; simplemente estaba antes
cuando DNS se actualizó. PVE empezó a lanzar errores de autenticación y huella. Alguien, bajo presión, actualizó la huella para “hacer que los backups estuvieran verdes”
sin verificar el certificado en el lado de PBS.

Las copias de seguridad comenzaron a “funcionar” otra vez—excepto que se enviaban al equipo equivocado que no tenía datastore montado, así que las subidas fallaban a mitad de transmisión y los jobs reintentaban eternamente.
La monitorización se centraba en “job iniciado”, no en “backup finalizado”, así que el panel permaneció agradablemente optimista.

La solución fue simple pero humillante: revertir la huella, corregir DNS/IP, y tratar las indicaciones de huella como cambios de clave host SSH:
verificar por fuera del canal, luego aceptar. También cambiaron la monitorización para alertar sobre completado exitoso y sobre patrones de crecimiento del datastore.

Incidente #2 (optimización que salió mal): “Un token para todo el cluster”

Otro equipo quiso reducir la proliferación de configuración. Crearon un solo token PBS y lo pegaron en cada nodo PVE.
Funcionó, y fue rápido. También significó que cada nodo tenía la misma identidad efectiva.

Más tarde, intentaron restringir permisos limitando el token. Pero necesitaban permisos diferentes para nodos distintos:
un nodo gestionaba cargas de cumplimiento y requería permisos de verify; otro nodo era un host de desarrollo desechable donde no se permitía prune.
Con un token compartido, los cambios de permiso se volvieron políticos y lentos.

Luego se descomisionó un nodo. Nadie recordó rotar el token compartido, porque “solo son backups”. Ese disco del nodo se vendió,
y el secreto del token quedó en una copia de seguridad de configuración olvidada. Meses después, durante una auditoría, se dieron cuenta de que no tenían forma limpia de demostrar que el secreto había desaparecido.

La optimización que salió mal fue la identidad compartida. La solución: un token por nodo, ACLs limitadas por token, y una práctica de rotación ligada al ciclo de vida del nodo.
Algo más de tecleo; mucho menos pánico existencial.

Incidente #3 (práctica aburrida pero correcta): la lista de verificación que salvó el día

Un entorno regulado sufrió una falla de hardware en PBS. Restauraron PBS desde un procedimiento de recuperación conocido: reinstalar SO,
volver a adjuntar almacenamiento, restaurar configuración de PBS, validar huella del certificado, validar inventario de usuarios/tokens, y luego reactivar los jobs de PVE.
Fue un runbook aburrido, lleno de salidas de comandos y “valores esperados”.

Durante la restauración, el certificado de PBS se regeneró. Eso es normal. El runbook decía explícitamente:
“Antes de actualizar huellas en PVE, obtener la huella de /etc/proxmox-backup/proxy.pem y validar acceso por consola.”
Así que lo hicieron. Sin adivinanzas. Sin aceptar advertencias a ciegas.

Actualizaron las huellas en los nodos PVE, luego probaron con un solo backup de VM, y después ampliaron al resto de la flota.
Toda la interrupción quedó contenida a una ventana predecible. Lo mejor: el postmortem tuvo casi nada de drama, porque el proceso ya respondía las preguntas.

Por eso escribes runbooks. No porque disfrutes el papeleo, sino porque tu yo futuro está ocupado, cansado, y a una mala decisión de convertir una recuperación en un incidente.

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

1) Síntoma: “autenticación fallida” inmediatamente al añadir almacenamiento PBS

Causa raíz: Realm equivocado (@pam vs @pbs) o formato de nombre de usuario incorrecto.

Solución: Verifica que el usuario exista en PBS (proxmox-backup-manager user list) y establece username backup@pbs correctamente.

2) Síntoma: 401 Unauthorized en los logs del proxy PBS

Causa raíz: Secreto del token incorrecto, token deshabilitado/caducado, o mismatch de ID de token.

Solución: Lista tokens (proxmox-backup-manager user token list backup@pbs), vuelve a emitir si es necesario, actualiza PVE y prueba con curl.

3) Síntoma: 403 Forbidden / permission check failed

Causa raíz: ACL faltante en /datastore/<name> o namespace/propagation incorrectos.

Solución: Añade ACL en la ruta exacta con el rol apropiado y propagate; confirma vía proxmox-backup-manager acl list.

4) Síntoma: Aviso de huella tras reboot/reinstalación de PBS

Causa raíz: Cambió el certificado de PBS o PVE alcanza un host distinto.

Solución: Obtén la huella desde PBS local con openssl x509 -in /etc/proxmox-backup/proxy.pem ..., valida DNS/IP, y actualiza la huella en PVE solo tras verificar.

5) Síntoma: El almacenamiento aparece activo, pero los jobs fallan durante prune o verify

Causa raíz: El token puede escribir backups pero carece de privilegios de mantenimiento.

Solución: Separa identidades: un token para escribir backups y otro para prune/verify, o concede explícitamente roles necesarios para endpoints de mantenimiento.

6) Síntoma: Funciona desde un nodo PVE, falla desde otro

Causa raíz: Diferencias de token por nodo, o entradas storage.cfg diferentes, o reglas de firewall por IP de origen.

Solución: Compara /etc/pve/storage.cfg entre nodos; prueba curl desde cada nodo; revisa logs de PBS para rhost y user/token.

7) Síntoma: Tras habilitar 2FA para un usuario, los backups empiezan a fallar

Causa raíz: Usaste una cuenta humana para automatización. 2FA rompe flujos no interactivos a menos que uses auth por token.

Solución: Cambia PVE a tokens API de PBS para acceso de máquinas. Mantén 2FA para humanos.

8) Síntoma: “permiso denegado” al listar snapshots/contenidos

Causa raíz: La ACL permite escribir pero no permite leer/listar o navegar en la ruta/namespace relevante.

Solución: Asegura que los roles cubran las operaciones que necesitas (backup, read/list, restore). Prueba vía llamadas API que listan grupos/snapshots.

9) Síntoma: Todo falló tras “endurecimiento de seguridad”

Causa raíz: Regeneración de certificados o inserción de reverse proxy sin actualizar huellas, o ACL endurecida en “/” sin propagate.

Solución: Deshaz el proxy, vuelve a fijar huellas, y reaplica ACLs a nivel de datastore con propagate activado intencionalmente.

Listas de verificación / plan paso a paso

Plan A: arréglalo rápido sin empeorarlo (recomendado)

1. Confirma alcanzabilidad: nc -vz pbs01 8007 desde el nodo PVE que falla.
2. Lee los logs de PBS mientras reproduces: journalctl -u proxmox-backup-proxy -f.
3. Clasifica la falla:
   • invalid credentials / 401 → token/usuario/realm.
   • permission check failed / 403 → ruta/rol/propagate de ACL.
   • fingerprint mismatch → verifica cert y actualiza pin en PVE.
4. Verifica inventario de identidades en PBS:
   • proxmox-backup-manager user list
   • proxmox-backup-manager user token list backup@pbs
5. Verifica ACL en PBS: proxmox-backup-manager acl list y confirma la ruta correcta del datastore.
6. Verifica huella:
   • PBS local: openssl x509 -in /etc/proxmox-backup/proxy.pem -noout -fingerprint -sha1
   • PVE fijado: grep storage.cfg
7. Prueba con curl desde PVE usando la cabecera de token para aislar problemas de GUI.
8. Arregla exactamente una cosa, vuelve a probar, luego sigue. No “rota todo y cruza los dedos.”

Plan B: reconstruir credenciales limpiamente (cuando perdiste el hilo)

1. Crea (o recrea) un usuario PBS dedicado para jobs PVE (backup@pbs), habilitado, sin expiración.
2. Crea un token nuevo por nodo; registra el secreto una vez; guárdalo en tu gestor de secretos.
3. Asigna ACL en /datastore/<name> a la identidad del token directamente.
4. Actualiza la config de almacenamiento de PVE para usar el token y la huella correcta.
5. Ejecuta una prueba de backup de una VM; confirma que los logs de PBS muestran el token/usuario correcto y sin 403s.
6. Sólo entonces reactivar el calendario completo de backups.

Plan C: respuesta a cambio de huella (trátalo como un incidente)

1. Para y verifica el mapeo DNS/IP (getent hosts pbs01).
2. Verifica la huella localmente en PBS vía acceso por consola.
3. Compara con lo que PVE tiene fijado; si es diferente, documenta por qué.
4. Actualiza la huella en PVE y vuelve a probar la conectividad.
5. Si no puedes explicar el cambio, asume compromiso o enrutamiento erróneo hasta probar lo contrario.

Preguntas frecuentes (FAQ)

1) ¿“Autenticación fallida” siempre es contraseña o token malo?

No. Puede ser desajuste de huella TLS, realm equivocado, o incluso una denegación de permisos que la GUI simplifica en un mensaje genérico.
Siempre revisa los logs del proxy PBS para ver si es 401 o 403.

2) ¿Cuál es la diferencia entre usuario/contraseña y auth por token API en PBS?

Usuario/contraseña es amigable para interacción humana. Los tokens API están pensados para automatización, pueden revocarse independientemente,
y son más seguros para limitar con ACLs. Para PVE→PBS, usa tokens.

3) ¿Por qué a PVE le importa la huella de PBS? Estamos en una red interna.

En redes internas ocurren la mayoría de los errores de “confianza”: reutilización de IP, deriva de DNS, alguien conectando una VM de prueba, o un host comprometido.
Pinnear la huella evita enviar backups silenciosamente al endpoint equivocado.

4) Actualicé la huella y ahora funciona. ¿Terminamos?

Solo si puedes explicar por qué cambió. Si cambió porque PBS se reconstruyó, bien. Si cambió “misteriosamente”, investiga DNS, ARP, proxies,
y si el host PBS fue reemplazado o restaurado desde snapshot.

5) ¿Por qué obtengo 403 cuando los backups se ejecutan pero prune falla?

Upload de backup y prune/GC/verify son operaciones distintas. Tu token puede tener privilegios de escritura pero no de mantenimiento.
Separa responsabilidades: token de backup para escrituras, token de mantenimiento para prune/verify.

6) ¿Puedo usar root@pam en todas partes para evitar problemas de permisos?

Puedes, y te arrepentirás. Root es una gran identidad para troubleshooting y una pésima identidad de automatización a largo plazo.
Usa tokens de menor privilegio y ACLs por datastore.

7) ¿Cuál es la forma más rápida de confirmar que el token funciona fuera de la GUI?

Usa curl contra /api2/json/version con la cabecera PBSAPIToken=.... Si devuelve JSON, auth y TLS están bien.
Si falla, el mensaje de error será más específico que la GUI.

8) Mi usuario PBS existe, mi token existe, la ACL parece correcta, pero sigo obteniendo 403. ¿Ahora qué?

Confirma que la ruta de ACL coincide con el objetivo real: nombre correcto de datastore, namespace, y si la propagación está activada.
También confirma que estás otorgando a la identidad correcta: backup@pbs vs backup@pbs!pve01.

9) ¿La deriva de tiempo realmente causa errores de auth aquí?

Sí, especialmente alrededor de validación de tickets/sesiones y cualquier cosa con semántica de expiración. Si ves fallos intermitentes tras reinicios,
revisa timedatectl en ambos extremos antes de culpar a los tokens.

10) ¿Debería poner PBS detrás de un reverse proxy con mi propio certificado?

Generalmente no. Introduce piezas móviles adicionales y rompe el modelo mental de “PVE fija la identidad del certificado de PBS.”
Si debes hacerlo, trátalo como un cambio de arquitectura y planifica la gestión de huellas deliberadamente.

Conclusión: pasos siguientes para evitar llamadas nocturnas

Arreglar el “authentication failed” de PBS no se trata de heroísmos. Se trata de negarse a adivinar. Empieza por los logs, clasifica 401 vs 403 vs TLS,
y solo entonces toca tokens, ACLs o huellas.

Pasos prácticos siguientes:

• Crea un usuario PBS dedicado y un token por nodo PVE. Elimina tokens compartidos a menos que disfrutes rotar secretos a gran escala.
• Concede ACLs por datastore con propagate deliberado. Evita concesiones en “/” que se conviertan en superpoderes accidentales.
• Documenta y monitoriza cambios de huella como cambios de clave SSH: verifica, luego actualiza, y siempre registra por qué.
• Separa responsabilidades: token de escritura de backups vs token de prune/verify. El principio de menor privilegio no es religión; es una estrategia de contención.
• Añade monitorización sobre la finalización exitosa del backup y crecimiento del datastore, no solo “job arrancado”.

Cuando las copias de seguridad están sanas, son aburridas. Aspira a lo aburrido. A producción le gusta lo aburrido.