Услугата 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, се нуждае от поддържан агент или интеграция за управление; трайно запазен еднократен код не е равностойна замяна.