Корекция: 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 на минимума, интерфейс за управление само ако е вързан и удостоверен, а полученият отговор от сървъра се третира като отделно събитие.