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

Ментальна модель: що насправді захищає 2FA у Proxmox

Аутентифікація в Proxmox VE — це не щось монолітне. Це стек компонентів, які перетинаються у формі входу у Web UI. Якщо ви хочете запобігти блокуванню — і чисто відновитися, коли воно трапиться — потрібно знати, на якому рівні відбувається збій.

Рівні, що мають значення

• Realms визначають, де живуть користувачі: pam (користувачі Linux через PAM), pve (вбудовані Proxmox), а також зовнішні варіанти на кшталт LDAP/AD.
• Користувачі — це ідентифікатори з вказаною областю, наприклад alice@pam або ops@pve.
• Методи 2FA (TOTP, WebAuthn, recovery codes тощо) прив’язуються до користувача, а не до вузла. У кластері це має значення.
• План управління — це передусім API і UI Proxmox (pveproxy/pvedaemon). Втрата доступу до нього не вимикає ВМ, але блокує можливість керування.
• Доступ root (локальна консоль/SSH) — це остаточний break‑glass. Якщо ви втратите root теж, це вже не налагодження 2FA — це відновлення хоста.

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

Парафраз ідеї Вернера Фогельса: Все руйнується, весь час — проектуйте під відновлення, а не під ідеал.

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

Цікаві факти та контекст (чому це йде не так)

1. TOTP базується на часі, а не на магії. Воно залежить від правильності годинника сервера. Кілька хвилин дрейфу можуть виглядати як «2FA зламана».
2. 2FA стало масовим, бо паролі зазнали поразки у масштабі. Великий перелом стався в 2010‑х роках, коли фішинг і повторне використання облікових даних стали індустріальними.
3. PAM існує довше за сучасну 2FA. Linux PAM (Pluggable Authentication Modules) — старіша рамка, яка може інтегрувати багато методів автентифікації, але неправильні конфігурації — вічна проблема.
4. Реалм pam означає «системні облікові записи», тому ваші Linux‑користувачі та політики паролів мають значення. Відключили SSH для root? Добре. Загубили консоль root? Погано.
5. Кластери підсилюють помилки ідентичності. Зміна, яка ламає автентифікацію на одному вузлі, може залишити вас у пастці, якщо цей вузол — єдиний доступний.
6. U2F/WebAuthn зросли в популярності, бо TOTP піддається фішингу. Але WebAuthn приносить інший ризик: втрата фізичного ключа без резерву.
7. Коди відновлення старші, ніж думають багато людей. Споживчі сервіси використовували їх рано, бо служби підтримки потребували небачевого способу допомогти заблокованим користувачам.
8. Політики «2FA скрізь» часто забувають сервісні облікові записи. Людські входи загартовують, автоматизація ламається, і хтось «тимчасово» відключає контролі під час кризи.

Як уникнути блокування 2FA: правила, які я застосовую

Правило 1: Потрібен протестований шлях break‑glass, що не залежить від тієї самої 2FA

Не плутайте «наявність root» з «планом break‑glass». План — це те, що ви зможете виконати о 03:00 під наглядом менеджера.

Практичний шаблон:

• Щонайменше два адміністративні ідентифікатори, які можуть дістатися кластера, зберігаються в менеджері паролів з аудитом доступу.
• Щонайменше один офлайн спосіб завершити другий фактор або легітимно обійти його (recovery codes, другий апаратний ключ або контрольована процедура скидання 2FA).
• Щонайменше один позасмуговий доступ до хоста (IPMI/iDRAC/iLO, KVM‑over‑IP або фізична консоль), який обходить Web UI повністю.

Правило 2: Ніколи не дозволяйте «єдиному адміністратору» реєструвати 2FA без іншого адміністратора поруч

Якщо існує рівно один аккаунт з правами Administrator, і ви вмикаєте на ньому 2FA — ви на відстані однієї помилки від відмови на рівні керування. Реєстрація 2FA має бути операцією двох осіб: одна змінює, інша перевіряє й залишається в системі, поки не підтверджено шлях відновлення.

Правило 3: Ставте синхронізацію часу у частину автентифікації

У Proxmox дрейф часу — це не «питання моніторингу». Це — «автентифікація може зламатися». Запускайте NTP/chrony всюди, перевіряйте після перезавантажень і моніторте дрейф.

Правило 4: Зберігайте дані відновлення 2FA так само, як SSH‑хости: обережно, офлайн і під контролем

Коди відновлення не повинні жити в загальному чаті. Покладіть їх у сейф менеджера паролів з логуванням доступу або в зашифрований офлайн‑схов у вогнестійкому сейфі. Зробіть це нудно. Нудно — добре.

Правило 5: Не оптимізуйте надмірність у ім’я «чистоти»

Люди люблять «почистити старі акаунти». Чудово. Робіть це після перевірки, що залишилися акаунти все ще можуть автентифікуватись, можуть адмініструвати і мають робочі 2FA‑резерви. Кладовище заповнене акуратно впорядкованими директоріями ідентичностей.

Короткий жарт #1: Двофакторна автентифікація — класна штука, поки ваш другий фактор не вирішить піти у відпустку без оформлення.

План швидкої діагностики

Це послідовність «припиніть гадати». Вона призначена, щоб сказати вам, чи вузьке місце — (a) ви, (b) час, (c) realm, (d) служби Proxmox або (e) мережа.

Перше: підтвердіть, що проблема саме в автентифікації, а не в з’єднанні

• Чи доступний порт UI вузла (8006)?
• Чи помилка в браузері — HTTP/TLS, або відхилення автентифікації?
• Чи інші користувачі теж не можуть зайти?

Друге: перевірте час і базове здоров’я хоста

• Перевірте стан синхронізації NTP і поточний час.
• Переконайтеся, що pveproxy і pvedaemon запущені.
• Перевірте заповненість диска (так, це важливо). Заповнені диски ламають дивні речі.

Третє: визначте, який realm задіяний і чи досяжний він

• @pam користувачі покладаються на Linux PAM/паролі.
• @pve користувачі покладаються на внутрішню Proxmox автентифікацію.
• LDAP/AD реаліми залежать від мережі + стану директорії + довіри TLS.

Четверте: вирішіть, чи потрібен «break‑glass login», чи «скидання 2FA»

• Якщо у вас є інша відкрита сесія адміністратора — використайте її для виправлення.
• Якщо ні — використайте root‑консоль/SSH для відновлення налаштувань і стану 2FA.

П’яте: містіть ризик

• Не вимикайте контролі безпеки глобально, якщо треба скинути одного користувача.
• Не перезапускайте служби кластера навмання. Перезапустіть мінімально необхідний компонент з планом відкату.

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

Це практичні завдання, які я справді виконую. Кожне містить, що означає вивід і яке рішення з цього випливає. Виконуйте їх на shell вузла Proxmox від root (або через sudo), якщо не вказано інше.

Завдання 1: Підтвердити, що годинник вузла адекватний (TOTP залежить від нього)

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

Значення: Якщо System clock synchronized — no, TOTP коди можуть ніколи не валідоватися.

Рішення: Якщо не синхронізовано, спочатку виправте час (chrony/ntp), а потім спробуйте вхід повторно перед зміною будь‑яких налаштувань автентифікації.

Завдання 2: Перевірити якість синхронізації chrony (дрейф може бути непомітним)

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

Значення: Зміщення в мілісекундах — прийнятні; у секундах — ні. Leap status має бути Normal.

Рішення: Якщо зміщення велике або leap status не Normal, виправте NTP і перевірте джерело годинника гіпервізора, якщо це VM.

Завдання 3: Перевірити, чи сервіс UI Proxmox працює

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

Значення: Якщо він не працює, ви не заблоковані через 2FA; ви заблоковані через відмову сервісу.

Рішення: Якщо inactive/failed, дивіться логи і перезапустіть pveproxy; поки що не чіпайте 2FA.

Завдання 4: Перевірити демон автентифікації теж (він підтримує API)

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

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

Рішення: Якщо він падає, виправте демон і повторно протестуйте перед тим, як змінювати користувачів.

Завдання 5: Подивіться останні помилки автентифікації в логах

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

Значення: Це покаже, чи відбувається відхилення TOTP, помилка PAM або базове мережеве/сервісне дивне поводження.

Рішення: Якщо це відхилення TOTP — перевірте час і 2FA‑конфігурацію користувача. Якщо PAM — перевірте системний акаунт/пароль і стек PAM. Якщо мережеві/hostname‑помилки — виправте мережу/DNS хоста.

Завдання 6: Переконатися, що диски не заповнені (бо тоді все ламається)

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

Значення: При 99% ви в зоні «випадкових відмов». Оновлення сертифікатів, логи і запис конфігів можуть не проходити.

Рішення: Звільніть місце негайно (очистіть логи, видаліть старі ISO, виріжте резервні копії) перед тим, як міняти налаштування автентифікації.

Завдання 7: Перелічити користувачів Proxmox і побачити їхні realms

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

Значення: Ви одразу бачите, хто внутрішній (@pve) versus системний/PAM (@pam).

Рішення: Якщо єдиний ваш адміністратор — крихкий користувач зовнішнього realm, створіть захищений локальний break‑glass адміністратор у @pve або переконайтеся, що доступ root@pam під контролем і протестований.

Завдання 8: Перевірити, які користувачі мають права адміністратора (не гадати)

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

Значення: ACL показують, хто справді може виправити проблему через UI/API.

Рішення: Якщо є лише один Administrator — зупиніться і додайте другого перед увімкненням або зміною політик 2FA.

Завдання 9: Перевірити конфігурацію 2FA на рівні користувача

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

Значення: Це показує, чи TOTP налаштовано і ввімкнено для цього користувача.

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

Завдання 10: Перевірити налаштовані realms (помітити залежність від LDAP/AD)

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

Значення: Якщо ваші адміністратори автентифікуються через corp і LDAP недоступний, ви «таємниче» не зможете увійти.

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

Завдання 11: Валідовати шлях Linux/PAM для користувачів @pam

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

Значення: Якщо getent не знаходить користувача, PAM автентифікація впаде. Якщо ви покладаєтесь на NSS/SSSD/LDAP, це може зламатися при відмові директорії.

Рішення: Якщо користувач зник, виправте джерело ідентичності (локальний користувач, SSSD, LDAP) або використайте локальний break‑glass аккаунт.

Завдання 12: Перевірити, чи доступний SSH/root (реальність break‑glass)

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

Значення: Якщо ви можете виконати це локально або через мережу управління, ви зможете відновити доступ без Web UI.

Рішення: Якщо SSH/root недоступний, треба використовувати позасмугову консоль (IPMI/iDRAC/iLO) або фізичний доступ — плануйте це відповідно.

Завдання 13: Підтвердити статус кворуму кластера (щоб не «чинити автентифікацію» під час split‑brain)

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

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

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

Рішення: Якщо немає кворуму, стабілізуйте кластер або вносьте зміни на вузлі з коректною конфігурацією (дуже обережно).

Завдання 14: Переглянути нещодавні невдалі входи в системних логах (контекст PAM/SSH)

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

Значення: Підтверджує, що PAM‑помилки реальні (неправильний пароль, заблокований акаунт, недоступна директорія), а не «дивність 2FA».

Рішення: Якщо PAM падає, виправляйте ланцюг Linux‑автентифікації (розблокувати акаунт, скинути пароль, перевірити SSSD) замість того, щоб чіпати Proxmox 2FA.

Завдання 15: Перевірити, чи користувач вимкнений або прострочений (тихе блокування)

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

Значення: enable: 0 означає, що акаунт вимкнений. Люди плутають це з помилками 2FA.

Рішення: Увімкніть знову, якщо це дозволено, або використайте інший адмін‑акаунт. Не скидайте 2FA для користувача, який просто вимкнений.

Короткий жарт #2: «Я швидко посилю автентифікацію» — це як ви вчитеся, де зберігаються ключі від дата‑центру.

Шляхи відновлення при блокуванні

Є два класи відновлення: виправити фактор (час, пристрій, реєстрація) або використати break‑glass для скидання конфігурації ідентичності. Ваше завдання — обрати найменш інвазивне, що відновить контрольований доступ.

Шлях відновлення A: TOTP відкидається через дрейф часу

Це найщасливіший випадок. Вам не треба видаляти 2FA; треба виправити час.

• Відновіть синхронізацію NTP/chrony.
• Не перезапускайте нічого, якщо це не необхідно.
• Спробуйте вхід з новим TOTP кодом (не повторюйте той самий).

Якщо дрейф повертається — перевіряйте BIOS‑годинник, джерело часу віртуалізації або доступність NTP. Дрейф часу — корінна причина, а не риса особистості.

Шлях відновлення B: користувач втратив пристрій аутентифікатора, але інша адмін‑сесія ще відкрита

Якщо інший адміністратор залогінений, використайте UI або CLI, щоб скинути 2FA користувача. Це найкращий варіант з операційної точки зору, бо ви не змінюєте глобальну поведінку автентифікації і зберігаєте слід в історії конфігурації Proxmox і логах.

З shell на вузлі зазвичай роблять:

• Підтвердити користувача і його 2FA‑записи.
• Відключити/видалити старі TOTP‑записи.
• Потребувати повторної реєстрації та переконатися, що згенеровані коди відновлення збережені.

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

Шлях відновлення C: UI недоступний, але є root‑shell (найпоширеніший break‑glass)

Якщо у вас є root на вузлі (SSH чи консоль), ви можете відновити Proxmox‑користувачів і стан 2FA напряму за допомогою pveum і виправлення залежностей realm.

Типові кроки:

1. Перевірити здоров’я хоста (час, диск, служби).
2. Підтвердити, які адміністративні ідентичності існують (pveum user list, pveum acl list).
3. Якщо у вас немає робочого адміністратора, створіть тимчасового @pve адміністратора зі складним паролем, увійдіть через нього, потім обертайте і обмежуйте доступ.
4. Скиньте 2FA конфігурацію постраждалого користувача.
5. Задокументуйте інцидент; не лишайте аварійні акаунти як постійні «інструменти в ящику».

Шлях відновлення D: втрачені root і 2FA (тут вже відновлення хосту)

Якщо ніхто не може дістатися root (SSH вимкнено, консоль недоступна, паролі невідомі), це вже не «відновлення 2FA Proxmox», а «відновлення доступу до сервера». Це IPMI/iDRAC, rescue‑media і потенційне скидання паролів root. Також це проблема управління: компанія дозволила єдину точку відмови в доступі адміністраторів.

Не «вирішуйте» це постійним послабленням автентифікації. Відновіть контрольований доступ root, а потім впровадьте реальний процес break‑glass.

Шлях відновлення E: відмова зовнішнього realm (LDAP/AD down)

Якщо адміністратори автентифікуються через LDAP/AD і директорія недоступна, ви фактично заблоковані без участі 2FA. Ось чому існують локальні акаунти. Правильне виправлення зазвичай таке:

• Використайте локальний break‑glass адмін (@pve або root@pam), щоб отримати доступ до кластера.
• Відновіть зовнішній realm (маршрути мережі, довіра TLS, DNS, стан сервісів).
• Після стабілізації розгляньте доцільність примусового використання зовнішнього realm для всіх користувачів.

Чого я уникаю під час відновлення

• Випадкові перезапуски сервісів під час інциденту кластера. Перезапуск corosync‑пов’язаних компонентів через невдалий вхід — це операції з ефектом «культу».
• Глобальні політики з відключення 2FA для всіх користувачів. Це привабливий молот, що має довготривалі наслідки.
• Робити це вживу без свідка для ризикових змін. Потрібна друга людина, щоб підтвердити, що ви не видалили останній ACL адміністратора.

Три корпоративні міні‑історії (як це ламається в реальному житті)

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

У середній SaaS‑компанії команда віртуалізації стандартизувала Proxmox для внутрішніх навантажень. Було налаштовано зовнішню директорію realm, і більшість користувачів автентифікувалися через LDAP. Здавалося, що все доросло: централізована ідентичність, контроль offboarding, менше локальних паролів.

Хибне припущення було тонким: вони вірили, що оскільки UI Proxmox показував кількох адмінів, під час відмови директорії будуть декілька адміністраторів, які зможуть зайти. Насправді всі «адміни» були в зовнішньому realm. Локального @pve адміністратора не було, а SSH для root був відключений в ім’я захищеності.

Потім пройшла рутинна ротація сертифікатів директорії. CA‑ланцюг оновили у директорійному шарі, але вузли Proxmox не отримали оновленого бандлу CA. LDAP bind‑и почали відмовляти. Proxmox не «працював частково». Він просто відхиляв кожен вхід адміністратора, а helpdesk записав це як «2FA зламана», бо команда нещодавно впровадила TOTP.

Відновлення зайняло більше часу, ніж треба, бо вони розглядали це як проблему застосунку замість проблеми залежності ідентичності. Зрештою вони скористалися позасмуговою консоллю, увійшли як root локально, оновили сховища довіри, перезапустили потрібні служби і створили належний break‑glass @pve адмін з паролем у сейфі й аудитом доступу.

Зміна після інциденту не була «менш безпечною». Вона стала очевидною безпекою: якщо зовнішня ідентичність обов’язкова, локальний аварійний доступ має існувати й тестуватися щоквартально.

Міні‑історія 2: Оптимізація, що обернулась проти

Фінансова компанія хотіла зменшити «спред облікових даних». Вони вирішили прибрати всі локальні Linux‑акаунти з вузлів Proxmox і вимагати тільки Proxmox internal users плюс обов’язкову 2FA. Також вони налаштували жорсткі firewall‑правила, щоб UI був доступний лише з management subnet.

Це було охайно. Але й тендітно: доступ до UI залежав від management subnet, VPN і робочої браузерної траєкторії. Тим часом SSH для операційних користувачів був обмежений, а доступ до консолі мали лише кілька людей з мережної команди.

Під час вікна мережного обслуговування VPN‑концентратор дав збій і доступ до management subnet віддалених співробітників порушився. На місці в офісі небагато людей були присутні, і вони не мали ролей Proxmox‑адмінів, бо «адміни — це SRE». Хости віртуалізації були в порядку; плоскость управління була не досяжна там, де насправді були адміністратори. По суті, команда оптимізувала себе в глухий кут.

Виправлення не полягало у відкритті всього. Вони зберегли модель management subnet, але додали другий фізично відділений шлях доступу (bastion з суворими контролями), задокументували процедури консолі і ввели невелику кількість onsite break‑glass адмінів з апаратними ключами в контрольованому сейфі.

Безпека стала кращою, не гіршою. Різниця була в тому, що модель стала стійкою до реального світу, де мережі й люди іноді одночасно виходять з ладу.

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

Організація охорони здоров’я керувала кластером Proxmox, що хостив департаментні системи. Команда мала рунбук, який ніхто не любив: щоквартальні тести break‑glass. Вони перевіряли позасмугову консоль, підтверджували, що локальний @pve адмін може увійти, валідовували наявність кодів відновлення і перевіряли, що щонайменше двоє людей мають право доступу до сховища.

Одного дня телефон адміністратора було очищено політикою MDM. Цей адміністратор також робив більшість роботи з віртуалізації, і його акаунт Proxmox мав обов’язковий TOTP. Поганий момент. Резервний пристрій TOTP? Теж під тією ж політикою MDM. Подвійний невдалий момент.

Вони не панікували. Інженер на виклику скористався рунбуком: увійшов break‑glass аккаунтом, підтвердив здоров’я кластера, скинув 2FA постраждалого користувача і вимагав негайної повторної реєстрації з другим фактором. Інцидент закрили, поки він не перетворився на «велику відмову», бо він не став такою.

Пост‑інцидентний звіт був теж нудним: «Тест break‑glass успішний; оновити політику MDM, щоб уникнути одночасного очищення факторів; нагадати адміністраторам зберігати recovery codes офлайн». У виробничих операціях нудність — найбільша похвала.

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

1) Симптом: «TOTP код недійсний» для всіх

Корінна причина: дрейф годинника вузла або відсутня синхронізація NTP.

Виправлення: відновіть синхронізацію часу (chrony/ntp), перевірте, що timedatectl показує synchronized, потім спробуйте ввійти з новим кодом.

2) Симптом: лише @pam користувачі не можуть зайти; @pve користувачі працюють

Корінна причина: проблема PAM/NSS: користувача немає, пароль змінено, SSSD/LDAP недоступні або акаунт заблоковано.

Виправлення: перевірте за допомогою getent passwd і логи автентифікації; виправте ланцюг Linux‑автентифікації або використайте локального @pve адміна для роботи.

3) Симптом: Web UI недоступний, але SSH працює

Корінна причина: pveproxy впав, TLS‑проблема, firewall або наповнений диск, що блокує операції сервісів.

Виправлення: перевірте systemctl status pveproxy, дивіться логи, звільніть місце на диску, перезапустіть лише впавший сервіс.

4) Симптом: Вхід працює на одному вузлі, але не на іншому

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

Виправлення: перевірте pvecm status щодо кворуму і налагодьте стан кластера; уникайте змін автентифікації під час розділення.

5) Симптом: LDAP користувачі відмовляють після «дрібного оновлення сертифіката»

Корінна причина: відсутній CA‑ланцюжок на вузлах Proxmox або суворіша TLS‑валідація.

Виправлення: оновіть довірений CA‑бандл на вузлах, перевірте конфіг realm, потім протестуйте bind‑и і входи.

6) Симптом: поведінку «користувач вимкнений» плутають з блокуванням 2FA

Корінна причина: акаунт enable: 0 або прострочений.

Виправлення: перевірте стан користувача через pveum user get, увімкніть повторно якщо авторизовано, і перевірте ACL.

7) Симптом: ви скинули 2FA і все одно не можете увійти

Корінна причина: неправильний realm обрано в формі входу або невідповідність імені користувача (наприклад, вводять alice замість alice@pam).

Виправлення: перевірте точний user ID і realm; переконайтеся, що форма входу використовує той самий realm, що й акаунт.

8) Симптом: автентифікація відмовляє лише з певних мереж

Корінна причина: firewall/WAF/проксі перериває трафік, заблокований порт 8006 або TLS‑інтерцепція, яка ламає сесію.

Виправлення: підтвердіть мережевий шлях і обробку сертифікатів; протестуйте з management subnet і з самого вузла.

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

Чекліст A: Перед увімкненням або примусом 2FA (зробіть один раз, зробіть правильно)

1. Створіть двох адмін‑користувачів з незалежними факторами (дві телефони або телефон + апаратний ключ).
2. Згенеруйте і збережіть recovery codes офлайн під контрольованим доступом.
3. Підтвердіть шлях доступу root@pam: консоль і/або SSH через bastion. Задокументуйте.
4. Перевірте синхронізацію часу на кожному вузлі (timedatectl, chronyc tracking).
5. Переконайтеся, що щонайменше один адмін‑акаунт не залежить від зовнішнього LDAP/AD, якщо ви не можете гарантувати доступність директорії.
6. Програйте тест break‑glass: вийдіть, потім увійдіть назад, використовуючи резервного адміна і інший фактор.
7. Напишіть план відкату: які команди ви виконаєте, щоб видалити зламаний фактор і відновити доступ.

Чекліст B: Якщо підозрюєте, що заблоковані (спочатку містіть)

1. Припиніть безладні зміни. Визначте, чи це мережа, здоров’я сервісів або автентифікація.
2. Перевірте синхронізацію часу і місце на диску на одному вузлі.
3. Перегляньте статус і логи pveproxy/pvedaemon для точних повідомлень про помилки автентифікації.
4. Визначте, який realm відмовляє (@pam vs @pve vs LDAP).
5. Спробуйте вхід з відомо робочим адміном з відомою робочою мережею.
6. Використовуйте break‑glass root shell лише якщо потрібно; робіть мінімальні й оборотні зміни.

Чекліст C: Контрольоване скидання 2FA для одного користувача (безпечний шлях)

1. Підтвердити user ID і realm через pveum user list.
2. Підтвердити, що користувач має потрібні ACL; не скидайте 2FA не тієї людини.
3. Зробити доказову базу: релевантні рядки логів, що показують причину помилки.
4. Вимкнути/видалити зламаний другий фактор користувача за допомогою інструментів управління користувачами Proxmox.
5. Нехай користувач негайно пере‑реєструє фактор, бажано з двома факторами.
6. Згенеруйте/збережіть recovery codes знову, якщо потрібно.
7. Підтвердити, що користувач може увійти і виконати мінімальну адміністративну дію.
8. Закрити цикл: задокументувати, що сталося і як уникнути повторень (політика MDM, резервний ключ тощо).

Чекліст D: Після відновлення — закріплення (не лишайте безлад)

1. Поверніть паролі, використані в аварії.
2. Перегляньте ACL: переконайтеся, що є щонайменше два дійсні адміни.
3. Заново перевірте синхронізацію часу і алерти моніторингу.
4. Аудитуйте логи на підозрілі спроби входу в цей період.
5. Заплануйте тест break‑glass протягом тижня — перевірте, що ваш «фікс» не створив нову вразливу точку.

Питання й відповіді (FAQ)

1) Чи зберігається 2FA у Proxmox на рівні вузла чи кластера?

У кластері конфігурація Proxmox фактично поширюється; конфігурація користувачів і автентифікації має бути консистентною. Розглядайте зміни 2FA як такі, що впливають на весь кластер, і перевіряйте кворум перед їхнім внесенням.

2) Який найнадійніший тип «break‑glass» аккаунта: @pve чи @pam?

@pve зазвичай безпечніший для незалежності від управління ОС і зовнішніх директорій/NSS‑проблем. Але для справжнього break‑glass вам все одно потрібен доступ root shell.

3) Чи може дрейф часу справді спричинити повне блокування?

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

4) Якщо LDAP недоступний, чому це виглядає як проблема 2FA?

Тому що UI бачить просто «authentication failed». Користувачі припускають, що їхній код неправильний. Логи зазвичай покажуть помилки bind або PAM/NSS.

5) Чи варто вимикати 2FA глобально під час інциденту?

Майже ніколи. Вимикайте або скидайте тільки для постраждалого користувача і лише після підтвердження, що проблема не в часі чи залежностях realm. Глобальне відключення — це новий інцидент безпеки, який буде розкладено на майбутнє.

6) Якщо не можу дістати Web UI, але маю доступ по SSH до вузла — що робити?

Це проблема сервісу або мережевого шляху, а не 2FA. Перевірте pveproxy і вільне місце на диску, потім перезапустіть мінімально потрібні служби.

7) Скільки адміністраторів повинні мати break‑glass доступ?

Мінімум двоє, ідеально троє у більших організаціях, з аудитованим доступом до сховища. Одна людина — це єдина точка відмови. Десять — це проблема контролю доступу.

8) Чи знижують коди відновлення безпеку?

Вони знижують операційний ризик, якщо зберігаються правильно. Якщо зберігати їх неправильно (простий текст, спільний чат), вони однозначно знижують безпеку. Метод зберігання — це межа безпеки.

9) Який найбільший антипатерн у застосуванні 2FA у Proxmox?

Примусовість 2FA без перевірки позасмугового доступу і без іншого адміністратора з іншим другим фактором. Це не загартування — це гра в рулетку.

Висновок: наступні кроки, які можна зробити сьогодні

Якщо ви експлуатуєте Proxmox у продакшені, розглядайте 2FA як частину дизайну доступності, а не лише політики безпеки. Блокування відбуваються на перетині людей, часу та ідентифікаційної інфраструктури. Ви не запобіжите їм надією. Запобігаєте — надмірністю і репетиціями.

Зробіть ці кроки в такому порядку:

1. Перевірте синхронізацію часу на кожному вузлі і моніторте дрейф.
2. Переконайтеся, що у вас є щонайменше дві адміністративні ідентичності з незалежними другими факторами.
3. Збережіть recovery codes офлайн під контрольованим доступом і протестуйте, що їх можна отримати не в умовах аварії.
4. Підтвердьте, що позасмуговий консольний доступ працює і задокументований.
5. Проводьте вправу break‑glass щоквартально і розглядайте невдачі як реальні інциденти.

Мета — не «ніколи не бути заблокованим». Мета — зробити відновлення передбачуваним, аудитованим і швидким, щоб безпека не перетворювалася на простої.