Служба 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 или ограниченное пространство имён, выполните ту же проверку изнутри этого представления, иначе ответ описывает не ту файловую систему. Пароль, хранящийся в скрытом домашнем каталоге, — обычный пример проверки, которая проходит вне 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, нуждается в поддерживаемом агенте или интеграции управления; навсегда сохранённый одноразовый код не является равноценной заменой.