Служба OpenVPN зупиняється на запиті пароля закритого ключа: як це виправити
Служба не має термінала, тому зашифрованому ключу потрібні askpass і читабельний файл. Відокремте парольну фразу ключа від входу на сервер і перевірте unit.
OpenVPN запитує парольну фразу закритого ключа на локальній машині, тому робочий файл входу ніколи на неї не відповідає. Служба не має термінала для введення, і запуск або зависає, або завершується помилкою із записом у журналі, який називає введення, а не причину. Тут задіяні два секрети, і кожному потрібне власне читабельне джерело до перезапуску unit. Розбір нижче розділяє їх, а потім перевіряє ідентичність, яка справді відкриває кожен файл.
Розрізняйте два запити
Парольна фраза ключа розшифровує локальний закритий ключ; дані облікового запису автентифікують сеанс на сервері. Вони надходять із різних місць, відмовляють у різні моменти й дають різні повідомлення. Їхнє плутання змушує людей шукати скидання пароля, хоча обліковий запис не брав участі. Прочитайте текст запиту, перш ніж змінювати будь-яку опцію, бо формулювання — єдина надійна підказка, якого секрету бракує.
У Community OpenVPN 2.x askpass вказує файл, у першому рядку якого зберігається парольна фраза ключа, а auth-user-pass — файл, де ім’я користувача в одному рядку, а пароль у наступному. Жоден файл не задовольняє іншу опцію. Настільний застосунок або профіль NetworkManager можуть тримати обидва у власному сховищі секретів, яке клієнт командного рядка ніколи не читає, тому занотуйте, який клієнт ви налаштовуєте, перш ніж писати будь-який шлях.
Спрямуйте обидві опції на читабельні файли
Профіль, якому потрібні обидва введення, зрештою має три посилання на файли: зашифрований ключ, парольну фразу, що його відкриває, і пару для входу. Додайте їх, не торкаючись CA та перевірок ідентичності, бо вони вирішують, ким є сервер, і не належать до цієї проблеми. Якщо розгортання взагалі не використовує дані облікового запису, auth-user-pass створює введення, яке ніхто не може надати.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authОпції без аргументу поводяться інакше, ніж опції зі шляхом, і в службі ця різниця важлива. askpass без аргументу все ще читає консоль, а файл auth-user-pass лише з іменем користувача все ще залишає запит пароля в очікуванні. Щойно клієнт стає демоном, він узагалі не може просити введення в термінала, тож служба, налаштована так, не піднімається.
Абсолютні шляхи знімають питання про робочий каталог, але не дають доступу. Далі йдуть власник, режим і проходження, і всі три перевіряються щодо облікового запису, під яким працює процес.
Прочитайте конфігурацію unit до профілю
Яку конфігурацію завантажить екземпляр, вирішує unit, а не файл, який ви редагували. Прочитайте його командний рядок і всі drop-in, потім пройдіть від робочого каталогу до профілю, який справді використовується. Посилання на пароль, додане до іншого файлу .ovpn, для цього екземпляра нічого не змінює.
Три команди лише для читання відповідають на більшість. Перша друкує unit і всі drop-in, друга — ідентичність і налаштування пісочниці, що обмежують процес, третя — на що насправді скаржився останній запуск. Використовуйте ім’я екземпляра, яке існує на хості:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bЗверніть увагу на ProtectHome і на власні опції профілю user, group та chroot. Файл у домашньому каталозі може бути читабельним у вашій оболонці й невидимим усередині служби, коли домашні каталоги приховано. Обліковий запис, з яким запускається systemd, не завжди той, що зрештою відкриває ключ.
Доведіть, що ідентичність виконання може відкрити обидва файли
Прочитати режим недостатньо, бо кожен каталог на шляху має бути прохідним для тієї самої ідентичності. Пройдіть шлях компонент за компонентом, потім перевірте відкриття від імені облікового запису процесу. Файл із режимом 600 у власності root працює лише поки процес ще root, а після зниження привілеїв, яке роблять багато профілів, це вже не так. Дві команди покривають проходження й відкриття:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableПерша команда друкує режим кожного компонента й завершується помилкою там, де обліковий запис не може пройти; друга відповідає на єдине важливе питання — чи може ідентичність виконання відкрити файл для читання. Жодна не друкує вміст файлу, і саме це важливо, коли файл зберігає пароль. Повторіть перевірку для файлу входу, бо ці два часто зберігаються з різними власниками.
Якщо процес використовує chroot або обмежений namespace, виконайте ту саму перевірку зсередини цього подання, інакше відповідь описує не ту файлову систему. Пароль, збережений у прихованому домашньому каталозі, — звичайний приклад перевірки, яка проходить поза unit і відмовляє всередині нього.
Перевірте перший запуск, потім перепідключення
Запустіть екземпляр один раз і прочитайте першу помилку, а не останню. Відсутній файл введення, невдале розшифрування ключа й AUTH_FAILED від сервера — три різні події з трьома різними виправленнями. Виправлення попередження про права нічого не доводить про те, чи було відкрито ключ.
Рядок журналу каже, який із трьох випадків у вас. Виправлення випливає з того, яке введення відмовило:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
Потім перевірте життєвий цикл, який вам справді потрібен: запуск під час завантаження й будь-яке підтримуване перепідключення, а не лише ручний запуск із вашої оболонки. З auth-nocache введення відкидаються після першого використання, тож пізнішому перепідключенню все ще потрібне читабельне джерело. Зв’язка ключів, розблокована під час входу в робочий стіл, недоступна службі, яка стартувала раніше за будь-чий вхід, і це звичайна причина того, що ручна перевірка проходить, а перезавантаження відмовляє. Якщо перший запуск успішний, а пізніше перепідключення відмовляє, прочитайте журнал про подію перепідключення, перш ніж знову змінювати права.
Зберігання пароля поруч із ключем зменшує те, що дає шифрування, тому обмежте цей файл і його резервні копії. Видалення парольної фрази ключа — окреме рішення про облікові дані, а не виправлення відсутнього введення. Розгортання, що залежить від людського схвалення або інтерактивної MFA, потребує підтримуваного агента чи інтеграції керування; назавжди збережений одноразовий код не є рівноцінною заміною.