Виправлення Proxmox PBS «Authentication Failed»: токени, права й відбитки

Швидкий план діагностики

Коли автентифікація PBS ламається, вам потрібен найкоротший шлях до істини. Не починайте з ротації всього підряд. Почніть з визначення,
чи це (a) неправильний секрет, (b) неправильні права, чи (c) неправильна ідентичність сервера (відбиток/сертифікат).
Все інше — прикраса.

Спочатку: визначте, де відбувається збій (сторона PVE чи PBS)

• Якщо PVE зовсім не може дістатися PBS: це мережа, DNS, брандмауер або сервіс API PBS.
• Якщо PVE дістається PBS але отримує 401/403: це токен/користувач/realm/ACL.
• Якщо PVE скаржиться на відбиток/сертифікат: це невідповідність ідентичності TLS.

По-друге: класифікуйте HTTP-подібну поведінку

• 401 Unauthorized: облікові дані/токен не прийнято (неправильний токен, неправильний користувач, неправильний realm, токен прострочений/вимкнений).
• 403 Forbidden: ідентичність прийнято, але відмовлено в правах (відсутній ACL, неправильний шлях, неправильна привілея).
• TLS handshake / невідповідність відбитка: ви спілкуєтеся з неправильним сервером або сервер змінив ідентичність.

По-третє: виберіть одну безпечну дію

• Для 401: перевірте, що токен відправляється, належить користувачеві, якого ви очікуєте, і не має обмежень, про які ви забули.
• Для 403: зіставте необхідні привілеї з точним шляхом PBS (datastore, namespace, група бекапів).
• Для помилок відбитка: перевірте сертифікат на PBS, потім оновіть відбиток на PVE. Не «приймайте просто так» в продакшені, поки не впевнитесь, що вас не перенаправляють.

Одна цитата, яку варто повісити на стіну:
Парафраз ідеї (Werner Vogels): ви будуєте системи з припущенням, що відмови трапляються, а потім робите їх швидко й безпечно відновлюваними.

Ментальна модель: хто кому автентифікується

Proxmox VE (PVE) не «логіниться» до PBS як людина через браузер. Він використовує HTTP API PBS.
Цей виклик API включає ідентифікацію (користувач або токен), і PBS оцінює цю ідентичність відповідно до своїх ACL.
Окремо PVE прив’язує TLS-відбиток, щоб «pbs01» дійсно був вашим PBS, а не тим, хто відповів на цей IP сьогодні.

Отже «authentication failed» може означати, що зламався будь-який з цих шарів:

1. Імʼя та досяжність: DNS і маршрутизація до хоста PBS і порту.
2. TLS-ідентичність: невідповідність відбитка сертифіката або відмова в довірі.
3. Автентифікація: користувач/пароль або формат заголовка API токена, realm, статус токена.
4. Авторизація: PBS ACL шлях і привілеї для datastore, namespace, операцій обслуговування.
5. Несумісність можливостей: PVE очікує функцію (namespace, перевірка власника, шифрування), якої немає або яка заборонена в конфігурації PBS.

Добра новина: PBS і PVE голосно логують події, якщо дивитися в потрібному місці. Погана новина: повідомлення в GUI марні.
Трактуйте його як запрошення перестати клікати й почати читати логи як дорослий.

Факти й контекст (чому це складно)

• Факт 1: PBS використовує модель ACL на основі шляхів. Права можна надати на «/» або піддерево, специфічне для datastore, і має значення успадкування.
• Факт 2: PVE прив’язує відбиток сертифіката сервера PBS у визначенні сховища. Це навмисний захід проти MITM; це не забаганка.
• Факт 3: API-токени в екосистемі Proxmox — окремі ідентичності з власними привілеями й опціональними обмеженнями. Це не просто «паролі без MFA».
• Факт 4: Розрізнення 401 і 403 — оперативне золото. 401 означає «хто ви?» а 403 означає «я знаю хто ви і ні».
• Факт 5: Під час відновлення PBS може накладати перевірку власності й прав інакше, ніж для запису бекапів. Можливо, вам дозволено писати бекапи, але не читати/відновлювати їх.
• Факт 6: API PBS за замовчуванням працює на порті 8007. Люди іще помилково вказують 8006 через звичку, бо Proxmox навчає, що 8006 — «порт Proxmox».
• Факт 7: Зміни відбитка часто корелюють з перевстановленням, заміною хоста, регенерацією сертифіката або «хтось почистив /etc/proxmox-backup» не розуміючи наслідків.
• Факт 8: Підтримка namespace в PBS принесла більш детальний контроль, а також більше способів випадково заборонити доступ (подарунок для комплаєнсу, жарт для опсів).
• Факт 9: Перевірка бекапів, pruning і garbage collection — це привілейовані операції. Токен, що виконує бекапи, може зазнати невдачі під час операцій обслуговування пізніше.

Що насправді означає «authentication failed»

1) Невірний realm або неправильний формат ідентичності

Ідентичності Proxmox виглядають як user@realm. Якщо ви створили backup@pbs, а потім налаштували backup@pam,
ви отримаєте помилку, що виглядає як опечатка пароля. Це не вона.

2) Токен існує, але ви використали неправильний token ID або secret

Токени складаються з двох частин: ідентифікатор токена (як суфікс імені користувача) і секрет токена (рядок, показаний один раз).
Легко вставити неправильний секрет у поле пароля і потім клястися, що PBS зламався.

3) Токен автентифікується, але ACL відхиляє (403), GUI ховає нюанс

Найпоширеніша проблема «працює в одному місці, але не в іншому»: токен може перелічувати datastores, але не може записувати снапшоти,
або може писати, але не може виконати prune, або може бекапити VMs, але не контейнери (різний тип контенту на стороні PVE, різні виклики API).

4) Невідповідність відбитка після відновлення або зміни IP

Якщо сертифікат PBS змінився, PVE відмовить у підключенні, поки ви не оновите прив’язаний відбиток.
Це правильна поведінка. Розглядайте невідповідність відбитків як зміну SSH host key: перевірте спочатку, потім оновлюйте.

5) Зсу́в часу викликає дивні помилки з токенами/сесіями

PBS і PVE чутливі до часу для сесій і валідацій. Якщо один хост відхилився через проблеми з NTP,
ви можете отримати помилки, що зникають після перезавантаження (але це не виправлення; це випадковість).

Жарт №1: Бекапи — як парашути — якщо він вам знадобився і не відкрився, ви не «вчитеся», ви «падаєте».

Практичні завдання (команди, значення виводів, рішення)

Це ті завдання, які я реально виконую, коли ламається автентифікація PBS. Кожне містить, що означає вивід і яке рішення приймати далі.
Запускайте команди на відповідному хості (PVE або PBS). Не імпровізуйте; слідуйте підказкам.

Завдання 1: Підтвердити, що ви взагалі потрапляєте на порт API PBS (PVE)

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

Значення: Мережевий шлях і порт досяжні.
Рішення: Переходьте вгору по стеку до TLS і автентифікації. Якщо це падає, виправте DNS/маршрутизацію/брандмауер/сервіс перед тим, як чіпати токени.

Завдання 2: Перевірити стан служби API 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

Значення: Проксі запущено; PBS повинен приймати API-запити.
Рішення: Якщо воно зупинено, перезапустіть і перевірте логи перед тим, як звинувачувати автентифікацію.

Завдання 3: Слідкувати за логами proxmox-backup-proxy під час невдалого спроби (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

Значення: PBS отримав запит і відхилив облікові дані (ймовірно 401).
Рішення: Зосередьтесь на форматі ідентичності, realm, секреті токена та чи PVE використовує токен або пароль.

Завдання 4: Визначити «відмова в доступі» проти «невалідні облікові дані» (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

Значення: Ідентичність дійсна; авторизація провалена (403).
Рішення: Виправляйте ACL на шляху datastore/namespace; не ротауйте токени.

Завдання 5: Перевірити NTP/синхронізацію часу на обох сторонах (PVE і 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

Значення: Час тут нормальний.
Рішення: Якщо System clock synchronized: no на будь-якому хості, виправте NTP перш ніж звинувачувати токени. Зсув часу створює фейкові «автентифікаційні» проблеми.

Завдання 6: Підтвердити відбиток, який PVE прив’язав (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

Значення: PVE довірятиме лише PBS, який покаже цей відбиток.
Рішення: Якщо сертифікат PBS змінився, оновіть цей відбиток після перевірки нового відбитка на PBS.

Завдання 7: Отримати фактичний поточний відбиток сертифіката 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

Значення: Це те, що PVE має привʼязати.
Рішення: Якщо відрізняється від storage.cfg, оновіть відбиток у визначенні сховища PVE (і з’ясуйте, чому сертифікат змінився).

Завдання 8: Перевірити, що ви не потрапляєте на неправильний хост (PVE)

cr0x@pve01:~$ getent hosts pbs01
10.10.20.50   pbs01

Значення: DNS резолвить pbs01 в IP.
Рішення: Якщо цей IP нещодавно змінився, підтвердіть, що новий хост дійсно PBS, а не перерозподілена адреса або балансувальник.

Завдання 9: Перевірити TLS-ідентичність по мережі (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

Значення: Сервер, до якого ви дісталися, пред’являє сертифікат з показаним CN і відбитком.
Рішення: Якщо відбиток відрізняється від того, що PBS показує локально, вас перенаправляють або між ними стоїть проксі.

Завдання 10: Підтвердити, що користувач PBS існує й увімкнений (PBS)

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

Значення: Користувач існує й увімкнений.
Рішення: Якщо вимкнений/прострочений — виправте. Якщо користувача немає, зупиніться: ви автентифікуєтесь у вигаданій ідентичності.

Завдання 11: Переконатися, що токен існує й увімкнений (PBS)

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

Значення: Токен backup@pbs!pve01 існує й увімкнений.
Рішення: Якщо токен відсутній/вимкнений/прострочений — створіть заново та оновіть PVE. Не вгадуйте секрети.

Завдання 12: Переглянути ACL, що стосуються 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 │
└──────────────────────┴─────────────┴───────────┴─────────┘

Значення: Ідентичність призначена роль на шляху datastore.
Рішення: Якщо ACL відсутній або вказує на неправильний шлях — додайте. Якщо ви надали на «/», але propagation вимкнено, ви можете самі себе відрізати.

Завдання 13: Підтвердити, що datastore існує й здоровий (PBS)

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

Значення: Datastore існує і PBS вважає його OK.
Рішення: Якщо відсутній або в стані помилки — вирішіть проблему з монтуванням/правами спочатку; помилки автентифікації можуть бути вторинним шумом.

Завдання 14: Протестувати вхід в API PBS за допомогою токена з вузла (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"}} 

Значення: Токен дійсний для доступу до API й TLS працює (оскільки ви отримали відповідь).
Рішення: Якщо це падає з 401 — неправильний токен/секрет/realm. Якщо TLS-помилки — виправте довіру/відбиток/сертифікат.

Завдання 15: Виявити 403 помилки прав цілеспрямованим API викликом (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"} 

Значення: Токен автентифікується, але не має привілеїв для цього endpoint/шляху.
Рішення: Налаштуйте ролі/ACL для токена (переважно) або для користувача (менш бажано) на правильному шляху datastore.

Завдання 16: Перевірити коректність конфігу сховищ 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%

Значення: PVE бачить PBS-сховище як active. Якщо воно inactive — перевіряйте автентифікацію/відбиток.
Рішення: Якщо active, але завдання провалюються — зосередьтесь на правах завдань бекапу (snapshot/upload/prune), а не на базовій досяжності.

Завдання 17: Перевірити, якою ідентичністю PVE користується для 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

Значення: Тут можна звірити realm користувача.
Рішення: Якщо username має неправильний realm (pam vs pbs) або опечатку — виправте й перевірте перед тим, як чіпати ACLи.

Завдання 18: Перевірити невдалі входи на рівні бекенда автентифікації (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

Значення: Підтверджує повторні спроби і user, який бачить PBS.
Рішення: Якщо логи PBS показують іншого користувача, ніж ви очікуєте, ви неправильно налаштували PVE (або тестуєте з неправильного хоста).

Токени та ACL: стек прав, що підводить

Користувач чи токен: обирайте токени для машин

Використовуйте API-токени для вузлів PVE і автоматизації. Використовуйте паролі для людей. Токени зменшують площу ураження і усувають
«хтось змінив пароль root@pam щоб задовольнити політику» сюрприз.

Типова чиста модель виглядає так:

• Створіть виділеного користувача PBS: backup@pbs (realm pbs, не pam).
• Створіть по одному токену на вузол PVE: backup@pbs!pve01, backup@pbs!pve02 тощо.
• Надавайте ролі ACL на конкретному datastore (і namespace, якщо використовується), а не на «/».
• Надавайте лише те, що потрібно вузлу: backup, можливо verify, можливо prune — вирішуйте свідомо.

Ролі — не декор, а контракт

Якщо ви хочете, щоб бекапи запускалися, але не дозволяти скомпрометованому вузлу видаляти історію, не давайте йому широких адміністративних ролей.
Правильний підхід — явно надати роль для бекапів і тримати prune/GC обмеженими для окремої обслуговчої ідентичності.
Такий поділ нудний. Нудне — добре.

Де люди страждають: тестують з root, воно працює, потім «звузимо права пізніше», а «пізніше» приходить у вигляді 403 опівночі.

Підводні камені namespace і власності

PBS може сегментувати дані за допомогою namespace. Чудово для мультиорендерних налаштувань або розділення середовищ (prod vs dev) без додаткових datastore.
Також чудово для створення токена, який може автентифікуватися, але нічого не бачить.

Якщо ваше завдання орієнтоване на namespace, ACL має відповідати шляху цього namespace. Надання прав на корінь datastore може бути недостатнім
залежно від структури і налаштування propagate.

Відбитки й TLS: коли безпека робить свою справу

Помилки відбитків здаються бюрократією, поки ви не згадаєте альтернативу: тихе відсилання бекапів на хост нападника,
бо хтось ARP-спуфив VLAN або IP був повторно використаний. PVE прив’язує відбиток сертифіката PBS, щоб виявити «це не той самий сервер».
Це не параноя. Це звичайний робочий день.

Законні причини зміни відбитків

• PBS було перевстановлено або замінено.
• Сертифікат був навмисно регенерований.
• Файл proxy.pem було замінено під час відновлення/міграції.
• Хтось відновив старий знімок файлової системи /etc/proxmox-backup.
• Ви перемістили PBS за TLS-термінуючий реверс-проксі (зазвичай погана ідея для цього випадку).

Погані причини зміни відбитків

• «Ми почистили сертифікати через безпеку».
• «Ми розгорнули VM з шаблону і вирішили, що це те саме».
• «Ми змінили hostname і не подумали, що це важливо».

Правильний робочий процес нудний:
перевірте відбиток на PBS локально, порівняйте з тим, що прив’язав PVE, потім оновіть визначення сховища
якщо зміна легітимна. Якщо ви не можете пояснити зміну — зупиніться й розслідуйте. Бекапи — це межа безпеки.

Жарт №2: TLS-відбитки — як аеропортна безпека — набридливо, поки не настане день, коли ви будете вдячні, що хтось поставив питання.

Три корпоративні історії з полігонів бекапів

Інцидент №1 (хибне припущення): «Воно в тій самій VLAN, отже все в порядку»

Середня компанія мала PVE кластери й одну VM з PBS. Вона знаходилася в «довіреній» інфраструктурній VLAN. Команда припустила, що це означає,
що ніхто ніколи не підробить PBS, тож попередження відбитка в PVE сприймали як непотрібний шум.

Під час мережевого прибирання IP-адресу PBS ненадовго присвоїли іншому хосту. Той хост не був зловмисним; він просто встиг раніше,
коли DNS оновився. PVE почав кидати помилки автентифікації та відбитка. Хтось під тиском оновив відбиток, щоб «зробити бекапи зеленими»
без перевірки сертифіката на боці PBS.

Бекапи знову «працювали» — але відправлялися на неправильну машину без змонтованого datastore, тому завантаження падало посередині і завдання нескінченно перезапускалися.
Моніторинг відстежував «запуск завдання», а не «успішне завершення», тож дашборд залишався оптимістичним.

Виправлення було простим, але повчальним: повернули відбиток, виправили DNS/IP і почали сприймати підказки відбитка як зміни SSH host key:
перевірити поза смугою, потім прийняти. Також змінили моніторинг, щоб сигналізувати про успішне завершення і про зростання використання datastore.

Інцидент №2 (оптимізація, що повернулася боком): «Один токен для всього кластера»

Інша команда захотіла зменшити конфігураційний безлад. Тож вони створили один токен PBS і вставили його в конфіг кожного вузла PVE.
Воно працювало і було зручним. Але це означало, що кожен вузол мав ту саму ефективну ідентичність.

Пізніше вони спробували звузити права, але в різних вузлів були різні потреби:
один вузол обробляв критичні навантаження і вимагав verify; інший був тимчасовим dev-хостом, де prune не дозволявся.
З одним спільним токеном зміни прав стали політичними і повільними.

Потім один вузол вивели з експлуатації. Ніхто не згадав про ротацію спільного токена, бо «це просто бекапи». Диски того вузла продали,
а секрет токена лишився в забутому резерві конфігурації. Місяці потому, під час аудиту, вони зрозуміли, що не можуть довести, що секрет зник.

Оптимізація, що повернулася боком, — спільна ідентичність. Виправлення: один токен на вузол, обмежені ACL на кожен токен і практика ротації, прив’язана до життєвого циклу вузла.
Трохи більше друку; значно менше екзистенційного страху.

Інцидент №3 (нудна, але правильна практика): чекліст, що врятував ситуацію

Регульоване середовище зазнало апаратного збою PBS. Вони відновили PBS за відпрацьованою процедурою: перевстановлення ОС,
підключення сховищ, відновлення конфігурації PBS, валідація сертифіката, перевірка інвентарю користувачів/токенів, потім повторне вмикання завдань PVE.
Це був нудний runbook, повний виводів команд і «очікуваних значень».

Під час відновлення сертифікат PBS регенерувався. Це нормально. Runbook напряму вказував:
«Перед оновленням відбитків на PVE отримайте відбиток з /etc/proxmox-backup/proxy.pem і підтвердьте доступ до консолі.»
Вони так і зробили. Ніяких вгадувань. Ніяких кліків через попередження.

Вони оновили відбитки на вузлах PVE, потім протестували бекап однієї VM, потім масштабували на весь парк.
Увесь інцидент вклинився в передбачуване вікно. Найкраще: постмортем був майже без драми, бо процес вже відповідав на всі питання.

Саме тому пишуть runbookи. Не тому, що любите паперову роботу, а тому, що ваше майбутнє «я» буде зайняте, втомлене і одна неправильна дія від перетворення відновлення в інцидент.

Типові помилки: симптом → корінна причина → виправлення

1) Симптом: «authentication failed» відразу при додаванні PBS-сховища

Корінна причина: Неправильний realm (@pam проти @pbs) або неправильний формат імені користувача.

Виправлення: Перевірте, що користувач існує на PBS (proxmox-backup-manager user list) і встановіть username backup@pbs відповідно.

2) Симптом: 401 Unauthorized у логах proxmox-backup-proxy

Корінна причина: Неправильний секрет токена, токен вимкнений/прострочений або невідповідність token ID.

Виправлення: Перелічіть токени (proxmox-backup-manager user token list backup@pbs), перестворіть за потреби, оновіть PVE, потім протестуйте через curl.

3) Симптом: 403 Forbidden / permission check failed

Корінна причина: Відсутній ACL на /datastore/<name> або неправильний namespace/propagation.

Виправлення: Додайте ACL на точний шлях з відповідною роллю і propagate; підтвердіть через proxmox-backup-manager acl list.

4) Симптом: Запит на оновлення відбитка після перезавантаження/перевстановлення PBS

Корінна причина: Змінився сертифікат PBS або PVE потрапляє на інший хост.

Виправлення: Отримайте відбиток на PBS локально за допомогою openssl x509 -in /etc/proxmox-backup/proxy.pem ..., перевірте DNS/IP, оновіть відбиток PVE тільки після верифікації.

5) Симптом: Сховище показує active, але завдання бекапу падають під час prune або verify

Корінна причина: Токен може записувати бекапи, але не має прав обслуговування.

Виправлення: Розділіть ідентичності: один токен для запису бекапів, інший для prune/verify, або явно надайте ролі для endpoint-ів обслуговування.

6) Симптом: Працює з одного вузла PVE, падає з іншого

Корінна причина: Різні токени на вузлах, різні записи storage.cfg або правила брандмауера по IP джерела.

Виправлення: Порівняйте /etc/pve/storage.cfg між вузлами; тестуйте curl з кожного вузла; перевірте логи PBS за rhost і user/token.

7) Симптом: Після ввімкнення 2FA для користувача бекапи почали падати

Корінна причина: Для автоматизації використовували людський акаунт. 2FA ламає неінтерактивні потоки, якщо не використовувати токени API.

Виправлення: Перейдіть на API-токени PBS для доступу машин. Тримайте 2FA для людей.

8) Симптом: «permission denied» при переліку снапшотів/вмісту

Корінна причина: ACL дозволяє запис, але забороняє читання/перелік на відповідному шляху/namespace.

Виправлення: Переконайтеся, що ролі покривають необхідні операції (backup, read/list, restore). Тестуйте через API виклики, що перераховують групи/снапшоти.

9) Симптом: Все поламалось після «жорсткої політики безпеки»

Корінна причина: Регенерація сертифіката або вставка реверс-проксі без оновлення відбитків, або ACL звужено на «/» без propagation.

Виправлення: Відкати проксі, повторно прив’яжіть відбитки і повторно застосуйте ACL на рівні datastore з навмисно встановленим propagate.

Чеклісти / покроковий план

План A: швидко виправити, не зробивши гірше (рекомендовано)

1. Підтвердьте досяжність: nc -vz pbs01 8007 з проблемного вузла PVE.
2. Читайте логи PBS під час відтворення: journalctl -u proxmox-backup-proxy -f.
3. Класифікуйте помилку:
   • invalid credentials / 401 → токен/користувач/realm.
   • permission check failed / 403 → шлях ACL/роль/propagate.
   • відбиток не відповідає → перевірте сертифікат і оновіть привʼязку PVE.
4. Перевірте інвентар ідентичностей на PBS:
   • proxmox-backup-manager user list
   • proxmox-backup-manager user token list backup@pbs
5. Перевірте ACL на PBS: proxmox-backup-manager acl list і підтвердіть правильний шлях datastore.
6. Перевірте відбиток:
   • PBS локально: openssl x509 -in /etc/proxmox-backup/proxy.pem -noout -fingerprint -sha1
   • PVE привʼязані: grep storage.cfg
7. Протестуйте через curl з PVE, використовуючи заголовок токена, щоб ізолювати проблеми GUI.
8. Виправте рівно одну річ, повторно тестуйте, потім продовжуйте. Ніякої «ротації всього і сподівайся».

План B: відновити облікові дані чисто (коли загубили нитку)

1. Створіть (або відтворіть) виділеного користувача PBS для робіт PVE (backup@pbs), увімкненого, без терміну дії.
2. Створіть новий токен на вузол; зафіксуйте секрет один раз; збережіть у менеджері секретів.
3. Призначте ACL на /datastore/<name> для ідентичності токена безпосередньо.
4. Оновіть конфігурацію сховища PVE, щоб використовувати токен і правильний відбиток.
5. Запустіть тестовий бекап однієї VM; підтвердіть, що логи PBS показують правильний token/user і немає 403.
6. Тільки потім відновлюйте повний розклад бекапів.

План C: реакція на зміну відбитка (ставтесь до цього як до інциденту)

1. Зупиніться і перевірте відображення DNS/IP (getent hosts pbs01).
2. Підтвердіть відбиток локально на PBS через консольний доступ.
3. Порівняйте з тим, що прив’язав PVE; якщо відрізняється — задокументуйте причину.
4. Оновіть відбиток у PVE і повторно перевірте з’єднання.
5. Якщо ви не можете пояснити зміну — припускайте компрометацію або помилкову маршрутизацію, поки не доведете протилежне.

FAQ

1) Чи завжди «authentication failed» означає неправильний пароль або токен?

Ні. Це може бути невідповідність TLS-відбитка, неправильний realm або навіть відмова в правах, яку GUI сплющив до загального повідомлення.
Завжди перевіряйте логи proxmox-backup-proxy, щоб дізнатися, чи це 401 чи 403.

2) У чому різниця між user/password і API token auth для PBS?

User/password зручні для інтерактивного використання людьми. API-токени призначені для автоматизації, їх можна відкликати окремо
і їх простіше обмежувати через ACL. Для зв’язку PVE→PBS використовуйте токени.

3) Чому PVE звертає увагу на відбиток PBS? Ми в приватній мережі.

У приватних мережах трапляється більшість «довірених» помилок: повторне використання IP, дрейф DNS, підключення тестової VM або скомпрометований хост.
Привʼязка відбитка запобігає мовчазному відсиланню бекапів на неправильну кінцеву точку.

4) Я оновив відбиток і тепер все працює. Чи все добре?

Лише якщо ви можете пояснити, чому він змінився. Якщо зміна була через відновлення PBS — добре. Якщо зміни «таємничі» — розслідуйте DNS, ARP, проксі
і чи хост PBS був замінений або відновлений зі знімка.

5) Чому я отримую 403 під час виконання prune, хоча бекап завантажується?

Upload бекапу і prune/GC/verify — різні операції. Ваш токен може мати права запису, але не привілеї обслуговування.
Розділіть обовʼязки: токен для запису бекапів і токен для обслуговування.

6) Чи можу я використовувати root@pam скрізь, щоб уникнути проблем з правами?

Можете, але пошкодуєте. Root — чудова ідентичність для діагностики і погана для довгострокової автоматизації.
Використовуйте принцип найменших привілеїв: токени й ACL, зумовлені datastore.

7) Який найшвидший спосіб підтвердити, що токен працює поза GUI?

Використайте curl до /api2/json/version з заголовком PBSAPIToken=.... Якщо отримали JSON — автентифікація й TLS в порядку.
Якщо ні — повідомлення про помилку буде конкретнішим, ніж GUI.

8) Користувач PBS існує, токен існує, ACL виглядає правильно, але я все ще отримую 403. Що далі?

Переконайтеся, що шлях ACL відповідає фактичній цілі: правильна назва datastore, namespace і чи включено propagate.
Також перевірте, що ви надаєте права правильній ідентичності: backup@pbs проти backup@pbs!pve01.

9) Чи справді зсу́в часу викликає помилки автентифікації тут?

Так, особливо для валідації сесій і всього, що має семантику прострочення. Якщо бачите переривчасті помилки після перезавантажень,
перевірте timedatectl на обох сторонах перед тим, як звинувачувати токени.

10) Чи варто ставити PBS за реверс-проксі з власним сертифікатом?

Зазвичай ні. Це додає зайвих складових і порушує ментальну модель «PVE прив’язує сертифікат PBS».
Якщо це необхідно, розглядайте як архітектурну зміну і плануйте управління відбитками ретельно.

Висновок: наступні кроки, щоб не потрапити в pager jail

Виправлення PBS «authentication failed» — не про героїчні дії. Це про відмову від вгадувань. Починайте з логів, класифікуйте 401 vs 403 vs TLS,
і лише потім торкайтеся токенів, ACL або відбитків.

Практичні наступні кроки:

• Створіть виділеного користувача PBS і по одному токену на вузол PVE. Позбудьтеся спільних токенів, якщо вам не подобається масова ротація секретів.
• Надавайте ACL на рівні datastore з навмисним propagate. Уникайте надання на «/», що миттєво дає надмірні повноваження.
• Документуйте і моніторте зміни відбитків як зміни SSH host key: перевіряйте, потім оновлюйте, і завжди фіксуйте причину.
• Розділіть обов’язки: токен для запису бекапів і токен для prune/verify. Найменші привілеї — це не релігія, це стратегія стримування ризику.
• Додайте моніторинг за успішним завершенням бекапів і за зростанням datastore, а не тільки «запуск завдання».

Коли бекапи здорові — вони нудні. Намагайтесь досягти нудьги. Продакшен любить нудьгу.