Proxmox — «Вхід не вдався», коли завантажується веб-інтерфейс: основні причини та виправлення

January 1, 2026 • February 3, 2026 • Читання: 5 хв • Views: 11

Було корисно?

Ви можете пропінгувати хост. Веб-інтерфейс завантажується. Попередження сертифіката — те саме «займемося цим пізніше». Ви вводите пароль, який вводили тисячу разів, і отримуєте суху відповідь: Вхід не вдався.

Це тип помилки, який забирає час, бо виглядає як проста проблема з паролем. Іноді так воно і є. Частіше — ні. Інтерфейс — лише кур’єр, і він не дуже добре пояснює, що саме зламалося. Давайте змусимо його пояснити.

Швидкий план діагностики (робіть це спершу)

Якщо вам потрібен найшвидший шлях до справжньої причини, ви полюєте за одним із трьох: неправильний realm, проблеми зі часом/квитками або відмова бекенда автентифікації. Не починайте з випадкових перезапусків сервісів. Спочатку читайте помилки.

Крок 1 — Підтвердіть, що ви використовуєте правильний realm

Якщо ви входите як root, у більшості розгортань вам потрібен Realm = PAM, тому ім’я користувача має виглядати як root@pam.
Якщо налаштовано LDAP/AD, можливо, потрібно використовувати user@yourrealm. Інтерфейс запам’ятовує останній вибір realm — це зручно, поки не почне підводити.

Крок 2 — Дивіться помилки там, де вони фактично є

Відкрийте shell (консоль, IPMI або SSH, якщо ще можливо).
Відслідковуйте логи під час спроби входу. Якщо ви бачите «authentication failure» з деталями, ви вже попереду інтерфейсу.

Крок 3 — Перевірте зсув часу (тихий вбивця)

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

Крок 4 — Переконайтеся, що pveproxy і pvedaemon не зависли і не скривлені

Інтерфейс — це просто JavaScript, що спілкується з pveproxy (API) та іншими компонентами. Якщо сервіси нездорові, ви отримаєте загальні відмови.

Крок 5 — Якщо це кластер, протестуйте з іншого вузла

У кластері конфігурація автентифікації та база користувачів поширюються через /etc/pve (pmxcfs). Якщо pmxcfs на вузлі нездоровий, він може показувати UI, але дивно поводитися при автентифікації та правах доступу.

Одна операційна істина: якщо ви не можете увійти, не сперечайтесь із GUI. Запитайте демон. Він вам рано чи пізно скаже правду.

Веб-інтерфейс Proxmox VE — це клієнт для REST API. Потік входу приблизно такий:

Браузер завантажує інтерфейс з pveproxy (порт 8006).
Ви відправляєте username@realm і пароль (можливо 2FA).
pveproxy передає автентифікацію обраному бекенду realm (PAM, PVE, LDAP/AD, OpenID тощо).
При успіху Proxmox видає квиток (cookie) і токен запобігання CSRF для API-викликів.
Інтерфейс використовує цей квиток і CSRF-токен для подальших операцій.

Це важливо, бо «вхід не вдався» — це не одна річ. Це може означати:

Бекенд realm відхилив облікові дані (справжня проблема з паролем/2FA).
Бекенд недоступний (LDAP впав, проблеми з TLS AD, DNS відмовляє).
Квиток створено, але браузер не може його зберегти (зсув часу, дивні cookie, проблеми з заголовками reverse proxy).
Вузол не читає власну конфігурацію автентифікації (проблеми з pmxcfs, права в /etc/pve).

Корисна ментальна модель: UI завантажується означає, що TCP + TLS + базова доступність сервісу в порядку. Вхід вдається означає, що бекенд автентифікації, час і станова система квитків теж в порядку. Різні шари — різні режими відмов.

Цікаві факти та контекст (чому виникають ці помилки)

Факт 1: Кластерна файлова система Proxmox (pmxcfs) реалізована як FUSE-файлова система і підкріплена corosync для розподілу. Коли вона нездорова, «простими файли» як конфіг користувачів перестають бути простими.
Факт 2: За замовчуванням порт UI/API Proxmox — 8006, історично обраний, щоб уникнути конфліктів із загальними веб-серверами, що використовують 443/8443.
Факт 3: Proxmox розрізняє PAM користувачів (системні акаунти), PVE користувачів (збережено в базі Proxmox) та зовнішні реаліми як LDAP/AD/OIDC. Вибір неправильного — найбільш поширена самостійна помилка.
Факт 4: Авторизація на основі квитків має приховану залежність від коректного часу. Сучасні системи автентифікації чутливі до зсуву годинника через захист від повторних відтворень.
Факт 5: Багато компонентів Proxmox написані на Perl (зокрема pveproxy і pvedaemon), тому логи можуть бути досить конкретними, якщо їх читати.
Факт 6: У кластерах /etc/pve — це не «просто локальна конфігурація». Це розподілене сховище стану. Якщо corosync має проблеми з кворумом, читання/записи конфігу можуть поводитися по-іншому, ніж ви очікуєте.
Факт 7: Проблеми на стороні браузера реальні: застарілі cookie, кешований JS і агресивні розширення конфіденційності можуть порушити обмін CSRF/токенами і виглядати як «вхід не вдався». Рідко, але трапляється.
Факт 8: UI Proxmox історично опирався на ExtJS. Багато поведінок фронтенду (включно з обробкою помилок) сформовані припущеннями цієї екосистеми про сесії й токени.

Основні причини, коли UI завантажується, але ви не можете увійти

1) Неправильний realm (PAM vs PVE vs LDAP/AD vs OIDC)

Інтерфейс запам’ятовує ваш останній realm. Це зручно, поки ви не перейшли з LDAP-користувача на root і не забули змінити вибір. Результат: ви пробуєте root проти LDAP, воно відхиляє і інтерфейс просто знизав плечима.

Підказка для діагностики: Якщо root «раптом» перестав працювати після додавання LDAP-реалму, це перше, що я перевіряю. Більшість «раптом» збоїв автентифікації — фактично стан UI.

2) Зсув часу або NTP зламається (квитки стають недійсними)

Зсув часу не завжди показує «квиток прострочений». Іноді це просто «вхід не вдався». Якщо батарейка RTC сідає або NTP блокується, ви можете отримати зсув, достатній для порушення сесій, перевірки TLS і координації кластера.

3) PAM відмовляє (акаунт заблоковано, прострочено або проблеми NSS)

PAM може не пройти з причин, крім «неправильний пароль»:

Акаунт заблоковано (pam_tally2 / faillock сценарії).
Пароль прострочено (особливо якщо політика застосована до системних акаунтів).
Проблеми з NSS (стійко, якщо ви підключили LDAP для системних акаунтів).

4) Невідповідність 2FA або зламана часова база

TOTP залежить від часу. Якщо серверний годинник неправильний — ваш 2FA неправильний. Якщо ви використовуєте WebAuthn, поведінка браузера й reverse-proxy має значення. І якщо UI просить «OTP», а ви вводите пароль+OTP у неправильному форматі для цього realm — воно впаде без великої підказки.

5) Проблеми `pveproxy` / `pvedaemon` (сервіс нездоровий або завис)

Так, UI може завантажитись навіть якщо бекенд частково не працює. Ви можете отримати статичний контент і при цьому провалювати автентифікацію через API. Перезапуски сервісів можуть допомогти, але розглядайте їх як знеболювальне: корисно, але не лікує причину.

6) Невідповідність сертифіката/ключа після відновлення або зміни імені хоста/IP

Якщо ви відновили вузол з бекапу, клонували VM у нову особистість або змінили hostname без прибирання, можна отримати невідповідність сертифікатів або застарілу ідентичність вузла. Це може сніжити у кластерах.

7) Файлова система кластера (`/etc/pve`) не змонтована/нездорова

Якщо /etc/pve незадовільна, конфігурація користувачів і realm може бути недоступна. Вузол може й досі віддавати UI, бо сервіс запущено, але логіка автентифікації не знайде потрібних даних.

8) Зовнішній realm відмовив (LDAP/AD, OIDC)

Збої LDAP/AD — класика: DNS веде себе дивно, проблеми з TLS довірою, пароль bind-користувача прострочено, фаєрвол або вікно технічного обслуговування контролера домену, про яке ніхто не повідомив.

9) Дивні речі з браузером/cookie/CSRF (менш часті, але реальні)

Коли UI завантажується, але відразу «вхід не вдався» після введення вірних облікових даних, спробуйте приватне вікно або інший браузер. Якщо це допомагає — ви не виправили Proxmox; ви прибрали стан у клієнті.

Жарт #1: Якщо ваш план реагування на інцидент — «очистити кеш браузера», у вас не план — у вас ритуал.

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

Ось рухи, які я насправді виконую на вузлі, коли UI завантажується, але автентифікація не працює. Кожне завдання містить команду, типічний вивід і наступне рішення. Виконуйте це на хості Proxmox, якщо не вказано інше.

Завдання 1 — Переконайтеся, що сервіси працюють: pveproxy і 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

Значення: Якщо один із сервісів неактивний, автентифікація буде ненадійною або недоступною.

Рішення: Якщо не працює — подивіться логи (Завдання 2) перед перезапуском. Якщо працюють — переходьте до перевірки realm/часу.

Завдання 2 — Дивіться лог проксі під час спроби входу

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

Значення: «invalid credentials» вказує на realm/пароль/2FA або блокування PAM.

Рішення: Якщо бачите невідповідність realm або помилки LDAP — переходьте до відповідного розділу. Якщо бачите помилки з квитками/CSRF — перевірте час і cookie.

Завдання 3 — Дивіться pvedaemon для глибших помилок автентифікації/прав

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

Значення: Це відмовлення на рівні бекенда (у цьому прикладі — PAM).

Рішення: Розслідуйте стан PAM/акаунта (Завдання 9–11). Якщо pvedaemon показує «permission denied reading /etc/pve», перевірте pmxcfs (Завдання 6–7).

Завдання 4 — Перевірте час вузла та синхронізацію 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

Значення: «System clock synchronized: no» підозріло, особливо в кластерах або при 2FA.

Рішення: Виправте синхронізацію часу перш ніж робити інше. Якщо час відстає на хвилини — очікуйте проблем із квитками та corosync.

Завдання 5 — Перевірте стан chrony (поширено на 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

Значення: Невеликі відхилення допустимі. Великі відхилення і «Leap status: Not synchronised» — ні.

Рішення: Якщо не синхронізується — перевірте фаєрвол/DNS і ваші NTP-сервери. Якщо у вас кластер — виправте час на всіх вузлах.

Завдання 6 — Переконайтеся, що pmxcfs змонтовано і здорове

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)

Значення: Якщо це відсутнє, кластерна конфігурація Proxmox не змонтована; realms і користувачі можуть поводитися дивно.

Рішення: Перевірте pve-cluster і corosync (Завдання 7). У одновузловому налаштуванні pmxcfs також має бути змонтовано.

Завдання 7 — Перевірте стан кворуму/кластера (для кластерних вузлів)

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

Значення: Якщо Quorate: No, читання/записи конфігу можуть бути обмежені, а симптоми включають дивну автентифікацію залежно від того, що саме відмовляє.

Рішення: Виправте мережу corosync, підключення вузлів і кворум. Не «перезавантажуйте поки не запрацює». Так ви перетворите легку помилку на простій простій.

Завдання 8 — Перелічіть реаліми і перевірте, які існують

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

Значення: Якщо realm, який ви обираєте в UI, відсутній (або перейменовано), ваша спроба входу приречена.

Рішення: Використайте відомий робочий realm (часто pam) для аварійного доступу, потім виправте зовнішні реаліми.

Завдання 9 — Перевірте, що акаунт root не заблоковано на ОС-рівні

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

Значення: Статус P зазвичай означає, що пароль встановлено і він придатний. L означає заблоковано.

Рішення: Якщо заблоковано — розблокуйте свідомо (Завдання 10). Якщо пароль прострочено — встановіть новий у контрольований спосіб.

Завдання 10 — Розблокуйте root (якщо ви впевнені) та задайте пароль

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

Значення: Root розблоковано. Це рішення безпеки, а не лише технічне.

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

Завдання 11 — Перевірте PAM-автентифікацію без UI

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

Значення: Якщо PAM успішний тут, але падає в UI, проблема може бути у виборі realm, очікуванні 2FA або у квитках/cookie/часі.

Рішення: Якщо PAM теж падає — це проблема ОС-автентифікації (пароль, блокування, зміни в стеку PAM).

Завдання 12 — Перевірте базу користувачів Proxmox (realm PVE)

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

Значення: Якщо ваш адміністративний користувач вимкнено або прострочено, UI-вхід зазнає невдачі навіть за працездатного LDAP.

Рішення: Увімкніть/продовжте потрібного користувача. Якщо користувач зовнішній — переконайтеся, що realm доступний.

Завдання 13 — Перевірте, чи вимкнено 2FA для користувача

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

Значення: Якщо TOTP увімкнено (або вимагається політикою), логін лише з паролем не пройде. Дехто забуває, що вмикав це місяці тому.

Рішення: Використайте коректний потік OTP або тимчасово вимкніть 2FA тільки якщо у вас є формальна процедура аварійного доступу.

Завдання 14 — Перевірте, чи API відповідає локально (щоб звузити мережеву проблему від автентифікації)

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

Значення: Якщо це не працює локально, це не «проблема браузера». У вас проблема з сервісом (pveproxy впав, TLS проблеми або локальний фаєрвол).

Рішення: Виправте pveproxy/listeners перш ніж гнатися за реаліми.

Завдання 15 — Спробуйте створити API-кутик за паролем (ізолює 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..."}}

Значення: Якщо це працює, шлях бекенда автентифікації в порядку; ймовірно проблема у GUI/cookie/reverse proxy.

Рішення: Перевірте cookie у браузері, заголовки reverse proxy і валідність часу. Якщо й це падає — читайте логи знову (Завдання 2).

Завдання 16 — Перевірте проблеми з заголовками reverse proxy (якщо ви ставите Proxmox за проксі)

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;

Значення: Відсутні/некоректні заголовки Host або proto можуть порушити область дії cookie, редиректи і інколи потік автентифікації.

Рішення: Переконайтеся, що ваш reverse proxy налаштовано спеціально для Proxmox і він підтримує WebSocket. Якщо proxy не потрібен — не додавайте його «для охайності».

Завдання 17 — Швидко перегляньте локальні правила фаєрволу

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

Значення: Неправильно налаштований фаєрвол може блокувати LDAP/AD або NTP, одночасно дозволяючи 8006, що породжує «вхід не вдався» для зовнішніх realm.

Рішення: Якщо зовнішні реаліми відмовляють — підтвердіть вихідний доступ до LDAP/DC/NTP.

Завдання 18 — Перевірте підключення до LDAP (коли задіяно LDAP/AD)

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

Значення: Зовнішня ідентичність недоступна або недосяжна з цього хоста (DNS, маршрутизація, фаєрвол, TLS, сервер упав).

Рішення: Виправте мережу/DNS/TLS перш ніж робити інше. Не «виправляйте» це створенням локальних користувачів, якщо ви не виконуєте документовану аварійну процедуру.

Три корпоративні міні-історії (як команди дійсно опікаються)

Міні-історія 1: Інцидент через хибне припущення

Компанія мала охайний кластер Proxmox: три вузли, shared storage і «enterprise-ish» інтеграцію LDAP. Команда набрала нового інженера on-call і зробила звичне: «Просто увійдіть своїм LDAP-акаунтом».

Через місяць, під час інциденту зі стореджем, команда LDAP провела планове обслуговування контролерів домену. Це мало бути прозоро. Але ні. Один DC повернувся зі старим ланцюгом сертифікатів, інший мав відставання реплікації, а балансувальник прийняв креативні рішення. Веб-інтерфейс Proxmox завантажувався скрізь, але LDAP-логіни падали.

Інженер on-call спробував root. Теж впав. Вони вирішили, що пароль root обертали або загубили та ескалували до безпеки. Тим часом проблема зі стореджем погіршувалася, бо ніхто не міг змінити IO ліміти чи перемістити навантаження.

Справжня причина була болісно дрібною: форма логіну стояла на LDAP realm, і інженер вніс root без @pam. Proxmox зробив саме те, що йому сказали: спробував автентифікувати root в LDAP. Немає такого користувача — немає входу.

Вони виправили вибір realm, увійшли як root@pam і стабілізували кластер. Пункт постмортему був не «краще навчити», а створити документований аварійний локальний адмін у realm PVE з протестованим відновленням 2FA і включити «перевірити realm у випадаючому списку» в ранбуку. Нудно. Ефективно.

Міні-історія 2: Оптимізація, що дала фіаско

Інша організація поставила Proxmox за корпоративним reverse proxy. Мета була: єдина точка входу, логування WAF і «однаковий TLS». Все розумно. Потім хтось оптимізував конфіг проксі, щоб посилити політики cookie і заголовків, бо інструмент відповідності вказав на «небезпечні дефолти».

У понеділок користувачі почали скаржитись на періодичні «вхід не вдався». UI завантажувався нормально. Іноді допомагав рефреш; іноді — ні. Інженери перезапускали pveproxy на двох вузлах і тимчасово «виправляли» це, що давало їм впевненість і грабувало час.

Помилка була в обробці заголовків і cookie проксі. За певних умов проксі змінював сприйману схему/хост, Proxmox видавав cookie з атрибутами, які браузер відкидав, і наступний обмін CSRF/токенами падав. Єдина думка UI: «вхід не вдався».

Виправлення — перестати хитрувати. Проксі переналаштували, щоб передавати коректні Host і X-Forwarded-Proto, зберігати заголовки WebSocket upgrade і не псувати атрибути cookie. Після цього входи стали знову нудно стабільними — саме те, що потрібно для автентифікації.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Команда, що тримала Proxmox для внутрішнього CI, мала звичку, яка здавалася параноїдальною: щокварталу вони перевіряли аварійний вхід у кожному кластері. Не «ми думаємо, що працює», а реальний тест входу з консолі і UI з записаним чеклістом.

Одного дня їхній upstream NTP змінився, а правило фаєрволу заблокувало вихідний NTP в одній VLAN. Один вузол відхилився. Не достатньо, щоб викликати паніку — просто достатньо, щоб квитки стали ненадійними. UI завантажувався, входи іноді падали, і сесії випадково обривалися.

Їхній моніторинг помітив зсув годинника, але справжня заслуга — у процедурі: перші кроки ранбуку включали перевірку timedatectl і chronyc tracking. Вони виправили правило фаєрволу, примусово синхронізували час, і проблема зникла.

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

Парафразована ідея (Gene Kranz): «Невдача — не варіант» насправді про дисципліну — хороші системи і спокійні процедури зменшують простір для помилок.

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

Цей розділ спеціально конкретний. Якщо ви зіставите свій симптом з рядком, можна припинити гадати.

1) «Пароль root точно працює», але вхід миттєво падає

Симптом: UI завантажується, пароль відхилено миттєво, запит на OTP не з’являється.
Корінна причина: Обрано неправильний realm (часто LDAP), тому root перевіряється проти невірного бекенду.
Виправлення: Увійдіть як root@pam з Realm «Linux PAM standard authentication». Підтвердіть реаліми за допомогою pveum realm list.

2) Вхід падає тільки для LDAP/AD користувачів; локальні працюють

Симптом: root@pam працює; user@corp-ldap — ні.
Корінна причина: Підключення LDAP/TLS/DNS/фаєрвол, прострочені облікові дані bind-користувача або технічне обслуговування DC.
Виправлення: Запустіть pveum realm sync corp-ldap і перегляньте помилки. Перевірте DNS і вихідний фаєрвол. Відновіть довіру, якщо використовується LDAPS.

3) Вхід працював вчора; сьогодні падає на кількох вузлах

Симптом: Кілька користувачів повідомляють «вхід не вдався» при правильних паролях.
Корінна причина: Зсув часу (NTP зламався) або відмова бекенда realm (LDAP/OIDC впав).
Виправлення: Перевірте timedatectl і стан NTP. Якщо зовнішній realm — тестуйте підключення з вузлів. Спочатку виправте час, потім ідентичність.

4) Вхід вдається, але UI поводиться так, ніби ви вийшли

Симптом: Ви «увійшли», але вас викидає назад або дії завершуються помилками прав.
Корінна причина: Cookie не зберігається/не повертається через reverse proxy або налаштування браузера; іноді несумісність CSRF через плутанину scheme/host.
Виправлення: Спробуйте прямий доступ до https://node:8006. Спробуйте чистий профіль браузера. Виправте заголовки reverse proxy і налаштування WebSocket.

5) UI кластерного вузла завантажується, але вхід працює лише на деяких вузлах

Симптом: Вузол A приймає вхід, вузол B відкидає — той самий користувач.
Корінна причина: Зсув часу на рівні вузла, проблеми з монтуванням pmxcfs або часткова розділеність corosync, що дає застарілу/часткову конфігурацію.
Виправлення: Порівняйте час і pvecm status. Перевірте монтування /etc/pve. Виправте транспорт кластера і відновіть кворум.

6) «Вхід не вдався» після ввімкнення 2FA

Симптом: Раніше пароль приймався; зараз завжди відхиляється.
Корінна причина: Вимагається OTP, але його не подають або вводять неправильно; зсув серверного часу робить OTP недійсним.
Виправлення: Виправте синхронізацію часу. Перевірте стан 2FA через pveum user get USER. Використайте методи відновлення згідно політики; не вигадуйте нові під час паніки.

7) Після відновлення/клону ніхто не може увійти (або UI поводиться непослідовно)

Симптом: Веб-інтерфейс доступний; автентифікація падає або сесії поводяться дивно після зміни ідентичності вузла.
Корінна причина: Невідповідність hostname, сертифікатів/ключів або дубльована ідентичність вузла в кластері.
Виправлення: Перевірте резолюцію імен і ідентичність вузла. У кластерах переконайтеся, що Node ID унікальні, а corosync-конфіг послідовний. Переоформіть сертифікати за потреби (обережно).

Жарт #2: Автентифікація як картковий пропуск у фірмі — коли вона відмовляє, це ніколи не тому, що ви тішитеся достатньо гнівно.

Контрольні списки / покроковий план

Чекліст A: Одновузловий Proxmox, UI завантажується, вхід не вдався

Спробуйте явно root@pam. Не довіряйте пам’яті dropdown з realm.
Запустіть journalctl -u pveproxy -n 100 і шукайте точну причину відмови.
Підтвердіть синхронізацію часу: timedatectl і (якщо є) chronyc tracking.
Перевірте PAM безпосередньо: pamtester login root authenticate.
Перевірте, чи root не заблоковано: passwd -S root.
Спробуйте створити API-квиток локально з curl (Завдання 15). Якщо curl працює, а GUI ні — підозрюйте браузер/proxy.
Якщо ви ставите Proxmox за reverse proxy — обійдіть його і тестуйте прямий доступ до :8006.
Лише потім розгляньте перезапуск pveproxy/pvedaemon і задокументуйте причину.

Чекліст B: Кластерний Proxmox, UI завантажується, вхід не працює на одному вузлі

Перевірте різницю часу на проблемному вузлі та робочому (timedatectl на обох).
Перевірте кворум і стан corosync: pvecm status.
Переконайтеся, що /etc/pve змонтовано: mount | grep /etc/pve.
Відслідковуйте логи pveproxy під час спроби входу.
Якщо LDAP/AD: протестуйте синхронізацію realm з проблемного вузла (pveum realm sync). Часто мережеві сегментації вражають один вузол.
Переконайтеся, що вузол не ізольовано фаєрвол-правилами (Proxmox firewall та upstream ACL).
Якщо вузол без кворуму: не вносьте конфігураційних змін. Виправте кворум насамперед.

Чекліст C: Зовнішні реаліми (LDAP/AD/OIDC) раптово відмовляють

Переконайтеся, що локальний PAM-логін працює (root@pam) щоб повернути контроль.
Перевірте DNS-резолюцію для endpoint-ів ідентичності з вузла.
Перевірте вихідні правила фаєрволу від Proxmox до LDAP/DC/OIDC.
Шукайте зміни в TLS/ланцюжку довіри, якщо використовуєте LDAPS.
Перевірте, чи не прострочені облікові дані bind або не поміняні без оновлення Proxmox.
Не «виправляйте» створенням випадкових локальних адміністраторів. Створіть єдиний попередньо затверджений break-glass обліковий запис і контролюйте його використання.

FAQ

1) Чому веб-інтерфейс Proxmox завантажується, якщо автентифікація поламана?

Тому що завантаження інтерфейсу — це здебільшого статичний контент від pveproxy. Автентифікація — окремий API виклик, що стосується бекендів realm і логіки квитків.

2) У чому різниця між `root`, `root@pam` та `root@pve`?

root@pam — це системний root-акаунт, автентифікований через PAM. root@pve — це був би користувач, керований Proxmox (якщо створений), окремий від ОС-акаунтів.

3) Я можу SSH як root, але веб-інтерфейс не пускає. Чому?

SSH і веб-інтерфейс можуть обидва використовувати PAM, але веб-інтерфейс також може включати 2FA, вибір realm і обробку квитків/cookie. Також інтерфейс може автентифікуватися проти іншого realm, ніж ви думаєте.

4) Чи може зсув часу справді спричинити «вхід не вдався» навіть при вірних паролях?

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

5) Як відрізнити проблему LDAP/AD від проблеми Proxmox?

Якщо root@pam працює, але user@corp-ldap не працює — зазвичай це проблема LDAP/AD: підключення, TLS, DNS або облікові дані bind. Підтвердіть за допомогою pveum realm sync corp-ldap і логів.

6) Чи може не-кворум у кластері спричинити помилки входу?

Це може ускладнити ситуацію, особливо якщо стан /etc/pve неузгоджений або pmxcfs/corosync нездорові. Частіше бачать блокування операцій з конфігом, але автентифікація й права можуть путатися при розділеннях.

7) Чи варто перезапускати `pveproxy`, коли бачу «вхід не вдався»?

Тільки після перевірки логів і часу. Перезапуск може приховати основну причину (наприклад, зсув NTP або відмову LDAP) і ви знову повернетесь до тієї самої проблеми, тільки розлюченіші.

8) Що робити, якщо UI працює при прямому доступі `https://node:8006`, але падає за reverse proxy?

Тоді проблема — у проксі. Виправте переслані заголовки (Host, X-Forwarded-Proto), обробку WebSocket upgrade і уникайте псування cookie.

9) Я увімкнув 2FA і тепер ніхто не може увійти. Яке найнадійніше відновлення?

Використайте задокументований метод відновлення (recovery codes, break-glass акаунт, доступ через консоль). Якщо у вас такого немає — створіть його після відновлення, бо це повториться.

10) Який найнадійніший шлях аварійного доступу?

Доступ через консоль (фізично/IPMI) плюс локальний адмін шлях (root@pam або локальний PVE admin користувач), що не залежить від зовнішніх провайдерів ідентичності.

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

Коли Proxmox каже «вхід не вдався», але UI завантажується, це не загадка. Це компактний набір передбачуваних режимів відмов: неправильний realm, зсув часу, відмови бекенда автентифікації, проблеми кластерної файлової системи та дивні випадки проксі/браузера з токенами.

Зробіть наступне:

Додайте запис до ранбука, що починається з: перевірка realm, journalctl -u pveproxy, перевірка синхронізації часу.
Реалізуйте і протестуйте аварійний доступ: локальний шлях адміністратора, що не залежить від LDAP/OIDC.
Моніторьте зсув часу на кожному вузлі. Сповіщайте про десинхронізацію NTP до того, як почнуть падати квитки.
Якщо ви використовуєте reverse proxy, ставтесь до нього як до продакшн-коду. Версіонуйте, рев’юйте й тестуйте потоки логіну після змін.
У кластерах, моніторьте кворум і здоров’я corosync. Автентифікація і конфіг живуть у спільному наборі припущень.

Інтерфейс ввічливий. Логи чесні. Довіряйте тому, хто чесний.

Схожі статті

Proxmox 2FA: як уникнути блокування й швидко відновити доступ