Исправление: OpenVPN не смог прочитать имя пользователя Auth из стандартного ввода

could not read Auth username from stdin выглядит как проблема аутентификации, но ею не является. OpenVPN попытался запросить имя пользователя из стандартного ввода, ничего читаемого не нашёл и остановился ещё до того, как связался с сервером. Учётная запись может быть совершенно действительной; просто процессу некого спросить.

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

Читайте ошибку как локальный сбой ввода

Когда auth-user-pass появляется без аргумента файла, клиент ожидает запроса. В интерактивной оболочке этот запрос работает, потому что процесс владеет терминалом. Под systemd, заданием cron или контейнером стандартный ввод обычно пуст, и чтение сразу возвращается с ошибкой, которую вы видите.

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

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

Дайте службе поддерживаемый источник учётных данных

Поддерживаемый источник для работы без сопровождения — это файл учётных данных, переданный как аргумент auth-user-pass. Файл читается как обычный текст: первая строка — имя пользователя, вторая — пароль. Укажите на него абсолютным путём, например /etc/openvpn/client/creds , чтобы рабочий каталог служебной учётной записи не мог изменить смысл директивы.

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

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

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

Почему script-security не поможет

script-security управляет тем, может ли клиент запускать скрипты и сколько он может им передать, включая то, можно ли передать пароль скрипту через переменную окружения. Он ничего не говорит о том, откуда изначально берутся имя пользователя и пароль.

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

Интерфейс управления — законная альтернатива. Фронтенд может подключиться к нему, получить запрос учётных данных и ответить именем пользователя и паролем; так работают некоторые GUI. Если вы его используете, привяжите его к локальному адресу, защитите файлом пароля управления и ограничьте, кто может подключаться, потому что это канал управления клиентом.

Проверьте следующий этап после того, как клиент прочитает файл

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

Проверьте весь путь так, как его будет запускать служба: та же учётная запись, тот же рабочий каталог, то же окружение unit. Подключение, которое работает только при запуске из вашей оболочки, — признак того, что переменная окружения или терминал всё ещё часть потока.

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

Контрольный список: абсолютный путь к учётным данным, читаемость для служебной учётной записи, терминал не требуется, script-security оставлен на минимуме, интерфейс управления только если он привязан и аутентифицирован, а полученный ответ сервера рассматривается как отдельное событие.