Услугата OpenVPN застанува при барањето лозинка на приватниот клуч: како да се поправи
Услугата нема терминал, затоа шифрираниот клуч бара askpass и читлива датотека. Одделете ја лозинката на клучот од најавата на серверот и проверете ја unit.
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 од серверот се три различни настани со три различни поправки. Поправањето на предупредување за дозволи не докажува ништо за тоа дали клучот бил отворен.
Редот во журналот кажува кој од трите го имате. Поправката произлегува од тоа кој внес паднал:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
Потоа проверете го животниот циклус што навистина ви треба: стартување при подигање и секое поддржано повторно поврзување, не само рачно стартување од вашата обвивка. Со auth-nocache внесовите се отфрлаат по првата употреба, па подоцнежното повторно поврзување се уште бара читлив извор. Приврзок за клучеви отворен при најава на десктопот не е достапен за услуга што стартувала пред некој да се најави, и тоа е вообичаената причина зошто рачната проверка поминува, а рестартирањето паѓа. Ако првото стартување успее, а подоцнежно повторно поврзување падне, прочитајте го журналот за настанот на повторното поврзување пред повторно да менувате дозволи.
Чувањето на лозинката до клучот го намалува она што ви го дава шифрирањето, затоа ограничете ја таа датотека и нејзините резервни копии. Отстранувањето на лозинката на клучот третирајте го како одделна одлука за пристапни податоци, а не како поправка за внес што недостасува. Распоредување што зависи од човечко одобрување или интерактивна MFA бара свој поддржан агент или интеграција за управување; трајно зачуван еднократен код не е еквивалентна замена.