OpenVPN услуга се зауставља на захтеву за лозинку приватног кључа: како то поправити

OpenVPN тражи лозинку приватног кључа на локалној машини, па радна датотека за пријаву никада јој не одговара. У услузи нема терминала за унос, а покретање или виси, или пада са записом у журналу који именује унос, а не узрок. У игри су две тајне и свака пре поновног покретања unit-а тражи сопствени читљив извор. Поступак испод их раздваја, а затим проверава идентитет који стварно отвара сваку датотеку.

Разликујте два захтева

Лозинка кључа дешифрује локални приватни кључ; подаци налога аутентификују сесију према серверу. Долазе са различитих места, падају у различитим тренуцима и дају различите поруке. Њихово мешање шаље људе да траже ресетовање лозинке, иако налог уопште није учествовао. Прочитајте текст захтева пре него што промените било коју опцију, јер је формулација једини поуздан траг која тајна недостаје.

У Community OpenVPN 2.x askpass означава датотеку која држи лозинку кључа у првом реду, а auth-user-pass датотеку са корисничким именом у једном реду и лозинком у следећем. Ниједна датотека не задовољава другу опцију. Десктоп апликација или профил NetworkManager-а могу обоје да држе у сопственом складишту тајни, које клијент из командне линије никада не чита, зато забележите који клијент конфигуришете пре него што напишете било коју путању.

Усмерите обе опције на читљиве датотеке

Профил који тражи оба уноса на крају има три референце на датотеке: шифровани кључ, лозинку која га отвара и пар за пријаву. Додајте их без дирања CA и провера идентитета, јер оне одлучују ко је сервер и нису део овог проблема. Ако распоређивање уопште не користи податке налога, auth-user-pass ствара унос који нико не може да достави.

key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth

Опције без аргумента понашају се другачије од опција са путањом, а у услузи је та разлика важна. askpass без аргумента и даље чита конзолу, а датотека auth-user-pass само са корисничким именом и даље оставља захтев за лозинку на чекању. Када клијент постане демон, не може уопште да тражи унос од терминала, па услуга тако конфигурисана не подиже се.

Апсолутне путање уклањају питање радног директоријума, али не дају приступ. Затим долазе власништво, режим и пролаз, и сва три се проверавају према налогу под којим процес ради.

Прочитајте конфигурацију unit-а пре профила

Коју конфигурацију примерак учитава одлучује unit, а не датотека коју сте уређивали. Прочитајте његову командну линију и све drop-in, затим пратите радни директоријум до профила који се стварно користи. Референца лозинке додата у другу .ovpn датотеку не мења ништа за овај примерак.

Три команде само за читање одговарају на већину. Прва штампа unit и све drop-in, друга идентитет и подешавања sandbox-а која ограничавају процес, а трећа оно на шта се последње покретање стварно пожалило. Користите име примерка које постоји на домаћину:

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -b

Обратите пажњу на ProtectHome и на сопствене опције профила user, group и chroot. Датотека под кућним директоријумом може бити читљива у вашој љусци, а невидљива унутар услуге када се кућни директоријуми сакрију. Налог са којим systemd стартује није увек налог који на крају отвара кључ.

Докажите да извршни идентитет може да отвори обе датотеке

Читање режима није довољно, јер сваки директоријум на путањи мора бити проходан за исти идентитет. Прођите путању компоненту по компоненту, затим испробајте отварање као налог који процес користи. Датотека са режимом 600 у власништву root-а ради само док је процес још root, што не важи после снижавања привилегија које раде многи профили. Две команде покривају пролаз и отварање:

namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable

Прва команда штампа режим сваке компоненте и пада тамо где налог не може да прође; друга одговара на једино важно питање, да ли извршни идентитет може да отвори датотеку за читање. Ниједна не штампа садржај датотеке, и управо је то поента када датотека држи лозинку. Поновите тест за датотеку за пријаву, јер се обе често чувају са различитим власником.

Ако процес користи chroot или ограничен namespace, пустите исти тест изнутра тог погледа, иначе одговор описује погрешан датотечни систем. Лозинка сачувана под скривеним кућним директоријумом уобичајен је пример теста који прође изван unit-а и падне унутар њега.

Проверите прво покретање, затим поновно повезивање

Покрените примерак једном и прочитајте први, а не последњи пад. Недостајућа улазна датотека, неуспешно дешифровање кључа и AUTH_FAILED од сервера три су различита догађаја са три различите поправке. Поправка упозорења о дозволама ништа не доказује о томе да ли је кључ отворен.

Ред у журналу каже који од три случаја имате. Поправка следи из тога који унос је пао:

Затим проверите животни циклус који вам стварно треба: покретање при подизању и свако подржано поновно повезивање, не само ручно покретање из ваше љуске. Са auth-nocache уноси се одбацују после прве употребе, па касније поновно повезивање и даље тражи читљив извор. Привезак кључева отворен при пријави на десктоп није доступан услузи која је стартовала пре него што се било ко пријавио, и то је уобичајен разлог зашто ручни тест прође, а рестарт падне. Ако прво покретање успе, а касније поновно повезивање падне, прочитајте журнал за догађај поновног повезивања пре него што поново промените дозволе.

Чување лозинке поред кључа смањује оно што шифровање даје, зато ограничите ту датотеку и њене резервне копије. Уклањање лозинке кључа третирајте као одвојену одлуку о акредитивима, а не као поправку за унос који недостаје. Распоређивање које зависи од људског одобрења или интерактивне MFA тражи свог подржаног агента или интеграцију управљања; трајно сачуван једнократни код није еквивалентна замена.