Служба 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, другая — ідэнтычнасць і налады пясочніцы, што абмяжоўваюць працэс, трэцяя — на што фактычна скардзіўся апошні запуск. Выкарыстоўвайце імя асобніка, якое існуе на хосту:

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. Файл у хатнім каталогу можа быць чытэльным у вашым shell і нябачным унутры службы, калі хатнія каталогі схаваныя. Уліковы запіс, з якога стартуе 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 ад сервера — тры розныя падзеі з трыма рознымі выпраўленнямі. Выпраўленне папярэджання пра правы нічога не даказвае пра тое, ці быў ключ адкрыты.

Радок журнала кажа, які з трох вы маеце. Выпраўленне вынікае з таго, які ўвод знерваўся:

Затым праверце жыццёвы цыкл, які вам сапраўды патрэбны: запуск пры загрузцы і любое падтрыманае перападлучэнне, а не толькі ручны запуск з вашага shell. З auth-nocache уводы скідаюцца пасля першага выкарыстання, таму пазнейшаму перападлучэнню ўсё яшчэ патрэбна чытэльная крыніца. Звязка ключоў, разблакаваная пры ўваходзе ў працоўны стол, недаступная службе, якая стартавала раней за чый-небудзь уваход, і гэта звычайная прычына, чаму ручны тэст праходзіць, а перазагрузка зрываецца. Калі першы запуск удаецца, а пазнейшае перападлучэнне зрываецца, прачытайце журнал падзеі перападлучэння, перш чым зноў мяняць правы.

Захоўванне пароля побач з ключом паслабляе тое, што дае шыфраванне, таму абмяжуйце гэты файл і яго копіі. Выдаленне пароля ключа — асобнае рашэнне пра ўліковыя даныя, а не выпраўленне адсутнага ўводу. Разгортванне, якое залежыць ад чалавечага ўзгаднення або інтэрактыўнай MFA, патрабуе падтрыманага агента або інтэграцыі кіравання; назаўсёды захаваны аднаразовы код не з'яўляецца раўназначнай заменай.