Чи --key-password у OpenConnect — це пароль вашого облікового запису VPN?

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

Збиває з пантелику те, що одному з'єднанню може законно бути потрібні обидва секрети. Автентифікація за клієнтським сертифікатом може вимагати зашифрованого ключа, і той самий шлюз після прийняття сертифіката може все ще проводити обмін автентифікації користувача. Жоден секрет не задовольняє інший етап, і збій в одному ззовні виглядає дуже схоже на збій в іншому.

Два секрети, два різні завдання

Читайте ролі як доступ до файлу на противагу допуску в мережу. Пароль ключа розшифровує закритий ключ PEM, указаний у --sslkey, щоб можна було пред'явити клієнтський сертифікат TLS. Це розшифрування відбувається локально, всередині процесу клієнта, і сама парольна фраза ніколи не йде на шлюз. Шлюз бачить сертифікат і підпис, зроблений ключем. Посібник OpenConnect тримає --key-password поруч із --certificate і --sslkey, а в збірках, які можуть використовувати ключ у TPM, той самий параметр несе натомість пароль кореневого ключа сховища.

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

Змішування двох дає оманливі помилки. Шлюз, який відхиляє вхід, зазвичай повідомляє про збій автентифікації, тоді як неправильна парольна фраза ключа зазвичай зазнає невдачі раніше, коли рівень TLS не може прочитати файл ключа. Це різні етапи з різними виправленнями, і назви досить схожі, щоб люди їх плутали й потім гналися за не тим журналом. Зауважте, який запит з'явився, перш ніж змінювати будь-яке налаштування, бо формулювання запиту — найдешевша діагностика, яка у вас є.

Коли пароль ключа справді потрібен

Параметр має сенс лише тоді, коли є зашифрований ключ, який треба розблокувати. Якщо ви підключаєтеся з іменем користувача й паролем і без клієнтського сертифіката, --key-password не має на що діяти, і його додавання нічого не змінює. Якщо ви підключаєтеся з --certificate і --sslkey, чи буде взагалі запитано парольну фразу, вирішує формат самого файлу ключа.

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

Корисна діагностика — подивитися, коли відбувається збій. Якщо клієнт зупиняється до початку будь-якої мережевої автентифікації, підозрюйте файл ключа, його формат або парольну фразу. Якщо сеанс TLS встановлено і шлюз потім відхиляє користувача, ключ зробив свою справу, і проблема в обміні облікового запису.

Тримайте обидва секрети поза історією оболонки

Аргументи командного рядка доступні для читання іншим локальним користувачам через таблицю процесів і часто потрапляють в історію оболонки, скрипти й стенограми підтримки. OpenConnect уміє читати пароль облікового запису зі стандартного вводу за допомогою --passwd-on-stdin, а парольна фраза ключа може надходити з інтерактивного запиту або агента, а не з аргументу. Жоден механізм сам по собі не робить секрет безпечним, але обидва тримають його далі від найвідкритіших місць.

Файли заслуговують такої ж турботи. Скрипт, який записує парольну фразу в тимчасовий файл, має створювати його з обмеженими правами, видаляти під час виходу й уникати каталогів, читабельних для всіх. Парольна фраза, що пережила сеанс у тимчасовому каталозі, — це копія, яку ви забули зробити. Змінні середовища видимі дочірнім процесам і часто потрапляють у вивід інструментів налагодження, тож вони не безкоштовне покращення порівняно з аргументами.

Діагностичний вивід — це тихий витік. Журнали клієнта за більшої докладності можуть показувати тіла запитів або значення параметрів, а скопійовану стенограму термінала легко вставити в тікет, тому прочитайте вивід, перш ніж ним ділитися.

Мертва кнопка на робочому столі — це інша несправність

Запис VPN на робочому столі, який показує індикатор обертання, а потім нічого, зазвичай узагалі не є проблемою автентифікації. Кнопка належить мережевому менеджеру, аплету виробника або плагіну, який запускає OpenConnect від вашого імені, а відсутній компонент або нечитабельний профіль можуть дати саме цей симптом. З'ясуйте, який процес запускає кнопка, і прочитайте його помилку, перш ніж чіпати облікові дані.

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

Короткий контрольний список розділяє випадки. Локальний збій до виходу будь-якого пакета вказує на ключ або встановлення клієнта. Відмова шлюзу після сеансу TLS вказує на обмін облікового запису. Кнопка, яка ніколи не запускає клієнт, вказує на інтеграцію з робочим столом. Три різні несправності, одна з яких — пароль, який ви збиралися вставити не в те поле.