Исправка: 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 оставен на минимум, интерфејс за управување само ако е врзан и автентификуван, а добиениот одговор од серверот се третира како посебен настан.