Ang serbisyo ng OpenVPN ay humihinto sa paghingi ng password ng pribadong key: paano ayusin

OpenVPN ay humihingi ng passphrase ng pribadong key sa lokal na makina, kaya ang gumaganang login file ay hindi ito sinasagot kailanman. Sa isang serbisyo walang terminal na maitatype, at ang pagsisimula ay maaaring mag-hang o mabigo na may journal entry na pinangalanan ang input at hindi ang dahilan. May dalawang sikreto na kasangkot, at ang bawat isa ay nangangailangan ng sarili nitong nababasang pinagmulan bago i-restart ang unit. Ang hakbang sa ibaba ay naghihiwalay sa kanila, pagkatapos ay sinusuri ang pagkakakilanlan na aktuwal na nagbubukas ng bawat file.

Ihiwalay ang dalawang hiling

Ang passphrase ng key ay nagde-decrypt ng lokal na pribadong key; ang mga kredensyal ng account ay nagpapatunay ng session sa server. Galing sila sa magkaibang lugar, nabigo sa magkaibang sandali at nagbibigay ng magkaibang mensahe. Ang pagpapalit-palit sa kanila ay nagpapadala ng mga tao na maghanap ng password reset samantalang hindi naman kasangkot ang account. Basahin ang teksto ng hiling bago baguhin ang anumang opsyon, dahil ang pananalita ang tanging mapagkakatiwalaang palatandaan kung aling sikreto ang nawawala.

Sa Community OpenVPN 2.x, ang askpass ay tumutukoy sa file na may passphrase ng key sa unang linya, at ang auth-user-pass ay tumutukoy sa file na may username sa isang linya at password sa susunod. Wala sa dalawang file ang makakasapat sa kabilang opsyon. Maaaring itago ng desktop app o profile ng NetworkManager ang dalawa sa sarili nitong imbakan ng sikreto, na hindi binabasa ng command-line client, kaya tandaan kung aling client ang kinokonpigura mo bago magsulat ng anumang landas.

Ituro ang dalawang opsyon sa nababasang mga file

Ang profile na nangangailangan ng dalawang input ay hihinto sa tatlong reperensya ng file: ang naka-encrypt na key, ang passphrase na nagbubukas nito at ang pares ng login. Idagdag ang mga ito nang hindi hinahawakan ang CA o ang mga pagsusuri ng pagkakakilanlan, dahil ang mga iyon ang nagpapasya kung sino ang server at hindi bahagi ng problemang ito. Kung ang deployment ay hindi gumagamit ng kredensyal ng account, ang pagdaragdag ng auth-user-pass ay lumilikha ng input na walang makapagbibigay.

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

Ang mga opsyon na walang argumento ay kumikilos nang iba kaysa sa mga opsyon na may landas, at sa isang serbisyo mahalaga ang pagkakaiba. Ang askpass na walang argumento ay nagbabasa pa rin ng console, at ang auth-user-pass na file na may username lamang ay nag-iiwan pa rin ng hiling ng password na naghihintay. Kapag naging daemon ang client ay hindi na ito makakahiling ng input sa terminal, kaya ang serbisyong nakonpigura nang ganito ay hindi bumangon.

Ang mga ganap na landas ay nag-aalis ng tanong tungkol sa working directory ngunit hindi nagbibigay ng access. Kasunod ang pagmamay-ari, mode at pagdaan, at ang tatlo ay sinusuri laban sa account na pinatatakbo ng proseso.

Basahin ang konpigurasyon ng unit bago ang profile

Ang unit, hindi ang file na ineedit mo, ang nagpapasya kung aling konpigurasyon ang nilo-load ng instance. Basahin ang command line nito at anumang drop-in, pagkatapos ay sundan ang working directory hanggang sa profile na aktuwal na ginagamit. Ang reperensya ng passphrase na idinagdag sa ibang .ovpn file ay walang binabago para sa instance na ito.

Tatlong read-only na utos ang sumasagot sa karamihan. Ang una ay nagpi-print ng unit at anumang drop-in, ang pangalawa ay ng pagkakakilanlan at mga setting ng sandbox na nagtatali sa proseso, at ang pangatlo ay kung ano talaga ang inirereklamo ng huling pagsisimula. Gamitin ang pangalan ng instance na umiiral sa host:

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

Bigyang-pansin ang ProtectHome at ang sariling mga opsyon ng profile na user, group at chroot. Ang file sa ilalim ng home directory ay maaaring nababasa sa shell mo ngunit hindi nakikita sa loob ng serbisyo kapag itinago ang mga home directory. Ang account na ginagamit ng systemd sa pagsisimula ay hindi laging ang account na sa huli ay nagbubukas ng key.

Patunayan na kayang buksan ng runtime identity ang dalawang file

Hindi sapat ang pagbasa ng mode, dahil bawat direktoryo sa landas ay dapat madaanan ng parehong pagkakakilanlan. Lakbayin ang landas nang piyesa-piyesa, pagkatapos ay subukan ang pagbukas bilang account na ginagamit ng proseso. Ang file na may mode 600 na pag-aari ng root ay gumagana lamang habang root pa ang proseso, na hindi totoo pagkatapos ng pagbaba ng pribilehiyo na ginagawa ng maraming profile. Dalawang utos ang sumasaklaw sa pagdaan at pagbukas:

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

Ang unang utos ay nagpi-print ng mode ng bawat piyesa at nabigo kung saan hindi makadaan ang account; ang pangalawa ay sumasagot sa tanging mahalagang tanong, kung kayang buksan ng runtime identity ang file para basahin. Wala sa kanila ang nagpi-print ng nilalaman ng file, at iyon ang punto kapag may passphrase ang file. Ulitin ang pagsubok para sa login file, dahil madalas silang itinatago na may magkaibang pagmamay-ari.

Kung gumagamit ang proseso ng chroot o limitadong namespace, patakbuhin ang parehong pagsubok mula sa loob ng pananaw na iyon, kung hindi ay mali ang sistemang file na inilalarawan ng sagot. Ang passphrase na itinago sa ilalim ng nakatagong home directory ang karaniwang halimbawa ng pagsubok na pumapasa sa labas ng unit at nabibigo sa loob nito.

Suriin ang unang pagsisimula, pagkatapos ang muling pagkonekta

Simulan ang instance nang isang beses at basahin ang unang kabiguan at hindi ang huli. Ang nawawalang input file, nabigong pag-decrypt ng key at AUTH_FAILED mula sa server ay tatlong magkaibang pangyayari na may tatlong magkaibang pag-aayos. Ang pag-aayos ng babala sa pahintulot ay walang pinapatunayan tungkol sa kung nabuksan ang key.

Sinasabi ng linya sa journal kung alin sa tatlo ang mayroon ka. Ang pag-aayos ay nagmumula sa kung aling input ang nabigo:

Pagkatapos ay subukan ang lifecycle na aktuwal na kailangan mo: pagsisimula sa boot at anumang sinusuportahang muling pagkonekta, hindi lamang manu-manong pagsisimula mula sa shell mo. Sa auth-nocache ang mga input ay itinatapon pagkatapos ng unang paggamit, kaya ang susunod na muling pagkonekta ay nangangailangan pa rin ng nababasang pinagmulan. Ang keyring na binubuksan sa pag-login sa desktop ay hindi available sa serbisyong nagsimula bago mag-login ang sinuman, at iyon ang karaniwang dahilan kung bakit pumapasa ang manu-manong pagsubok at nabibigo ang reboot. Kung nagtagumpay ang unang pagsisimula at nabigo ang susunod na muling pagkonekta, basahin ang journal para sa pangyayari ng muling pagkonekta bago muling baguhin ang mga pahintulot.

Ang pagtatago ng passphrase sa tabi ng key ay nagpapababa sa ibinibigay ng encryption, kaya limitahan ang file na iyon at ang mga backup nito. Ituring ang pag-alis ng passphrase ng key bilang hiwalay na desisyon sa kredensyal, hindi bilang pag-aayos para sa nawawalang input. Ang deployment na umaasa sa pag-apruba ng tao o interaktibong MFA ay nangangailangan ng sinusuportahang agent o integrasyon ng pamamahala; ang permanenteng nakatagong one-time code ay hindi katumbas na kapalit.