Виправлення: OpenVPN не зміг прочитати ім'я користувача Auth зі стандартного вводу
Помилка OpenVPN «could not read Auth username from stdin» — це локальний збій вводу. Дайте службі читабельне джерело облікових даних; script-security тут ні до чого.
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 на мінімумі, інтерфейс керування лише якщо він прив'язаний і автентифікований, а отримана відповідь сервера розглядається як окрема подія.