OpenVPN ждёт запроса пароля systemd: отвечать ли?

В терминале появляется сообщение о systemd-tty-ask-password-agent, а туннель не поднят. Соблазнительное прочтение — VPN отклонил пароль и что-то теперь ждёт исправления. Точнее сказать, служба запросила у systemd интерактивный ввод, и на запрос ещё не ответили. Какая служба спросила и какой секрет ей нужен — два вопроса, которые можно решить до того, как что-либо набирать.

Кто должен ответить, решают два условия

Первое условие — запустили ли вы этот экземпляр намеренно. Запрос, следующий за вашим действием, — ваш для ответа, а тот, что появляется без соответствующего действия, принадлежит чему-то другому. Второе — является ли секрет аутентификацией учётной записи или защитой ключа, потому что они живут в разных местах и проходят разными путями кода. Оба ответа видны в журнале, если посмотреть до действия.

Когда оба ответа ясны, решение простое: отвечайте через собственный поддерживаемый путь запроса этой службы. Когда какой-то неясен, правильный шаг — исследовать, а не вводить пароль в запрос, который вы не можете приписать.

Это всё правило, и его стоит изложить до команд. Всё дальнейшее следует из него.

Перечислите запросы, прежде чем что-либо набирать

Агент может перечислить ожидающее, ни на что не отвечая. sudo systemd-tty-ask-password-agent --list печатает необработанные запросы, и этот вывод — доказательство, нужное, чтобы связать запрос с юником. Прочитайте его перед тем, как дать учётные данные, и держите описания запросов вне любой публичной диагностической вставки.

Соотнесите список с начатой операцией и с юником, которому она принадлежит. Если ничего в списке не соответствует вашему действию, увиденный запрос принадлежит другой службе, и решать его не вам. Имя юника в списке — единственная надёжная связь между запросом и службой.

Не отвечайте на запрос, который не можете приписать. Цена ожидания — задержка, а цена ответа на неверный запрос — учётные данные не в том месте.

Какой секрет на самом деле нужен экземпляру?

auth-user-pass касается аутентификации учётной записи в службе VPN, и без файла учётных данных документированное поведение — спросить в консоли. askpass вместо этого получает парольную фразу, которая отпирает защищённый ключевой материал, и делает это до того, как процесс уходит в фон. Это разные секреты с разным сроком жизни.

Форматы файлов тоже различаются. Форма учётной записи ожидает строку имени пользователя и строку пароля, тогда как файл парольной фразы ключа читает первую строку как свой пароль. Копирование рецепта файла учётных данных из другой роли обычно даёт ещё один запрос вместо решения. Файл неправильной формы хуже отсутствия файла, потому что сбой переходит в место, за которым никто не следит.

Проверьте, какую директиву использует экземпляр, прежде чем решать, что набирать. Имя директивы подсказывает, для какого секрета запрос.

Что делает --query, чего не делает --list

--query обрабатывает каждый ожидающий запрос на вызывающем терминале, что является куда более широким действием, чем ответ на один запрос. Это не селектор OpenVPN, и на занятой машине он может ответить на запросы, принадлежащие другим юнитам. Режим наблюдения ещё шире, потому что продолжает обрабатывать запросы по мере их поступления.

Используйте самый узкий механизм, который работает. Для одной службы её собственный поток запроса уже, чем глобальный агент, и он держит ответ привязанным к юниту, который спросил.

Превратить разовый запрос в необслуживаемый глобальный агент только потому, что уведомление появилось однажды, — это путь, которым временная неприятность становится постоянным дизайном. Та же осторожность относится к отключению юнитов уведомления о пароле на всём хосте.

Решите, а затем зафиксируйте выбор

Для необслуживаемого развёртывания согласуйте источник учётных данных, права на файл и график обновления с тем, кто владеет соединением. Интерактивному второму фактору может понадобиться человек или отдельная идентичность службы. Подавление запроса не создаёт такую аутентификацию, а удаление auth-user-pass ломает лишь ту службу, которой он нужен.

После взаимодействия посмотрите на тот же экземпляр ради его следующего события и проверьте частный ресурс. Если ничего не ожидает, вернитесь к состоянию экземпляра, а не запускайте каждый юнит OpenVPN на хосте.