OpenVPN auth-user-pass: file, stdin o prompt? Paano pumili

Tatlong bagay ang nagtatakda kung aling pinagmulan ng kredensyal ang gagamitin: kung may taong nakaupo sa console, kung maaaring manirahan ang lihim sa disk at kung kailangang sagutin ng ibang proseso ang prompt. Kung mali ang pinili, nag-uulat ang kliyente ng problema sa stdin habang ganap na wasto ang password, at walang dahilan nitong ipinapadala ang karamihan sa server. Pumili muna ng landas; may saysay lamang ang mga mensahe ng error kapag alam mo kung aling landas ang lumikha sa kanila.

Ang tatlong kundisyon na nagtatakda nito

Ang prompt sa console ang tanging landas na nangangailangan ng tao, kaya ito lang ang tahimik na nabibigo sa yunit ng systemd o sa container. Kung magsisimula ang isang tao ng kliyente at magta-type ng password, walang file na kasangkot at walang sensitibong bagay na napupunta sa disk. Kung magsisimula ang kliyente sa boot, ang parehong prompt ay nagiging pagkakasabit, at ang timeout ay karaniwang lumalabas bilang pangkalahatang pagkabigo sa koneksyon sa halip na error sa kredensyal.

Ang file ng kredensyal ang tamang sagot kapag nagsisimula ang proseso nang walang pangangasiwa at maaaring manatili ang lihim sa disk sa ilalim ng kontroladong hanay ng pahintulot. Kapag hindi dapat isulat ang lihim kahit kaunti - patakarang vault lamang, panandaliang token - kailangan mo ng stream na mabubuksan ng kliyente, na sa praktika ay nangangahulugang pagpapalit ng proseso o katulong na nagsusulat sa file descriptor. Sinasaklaw ng interface ng pamamahala ang ikaapat na kaso: controller na namamahala na sa lifecycle ng tunnel at makakasagot ng mga tanong sa pamamagitan ng socket.

• Tao sa console, walang automation: interaktibong prompt.
• Pagsisimula nang walang pangangasiwa, maaaring itago ang lihim: file ng kredensyal na may mode 0600.
• Pagsisimula nang walang pangangasiwa, hindi maaaring itago ang lihim: pagpapalit ng proseso o fd na sinusulatan ng ahente ng lihim.
• Pagmamay-ari ng ibang proseso ang kliyente: interface ng pamamahala.

Kapag tumugma ang dalawang sagot, piliin ang nagtatago ng lihim sa labas ng argv at sa labas ng history ng shell. Ang password na ipinasa bilang argumento ng programa ay mababasa ng sinumang lokal na user sa pamamagitan ng listahan ng proseso, at mahirap bawiin ang paghahayag na iyon.

Ano ang tunay na ginagawa ng bawat landas ng input

--auth-user-pass mag-isa ay humihingi ng username at password sa console. Kapag binigyan ng pangalan ng file, kinukuha ng kliyente ang unang linya bilang username at ang pangalawang linya bilang password; walang sumusuporta sa quotes, komento o syntax na key-value. Iyon ang buong format, kaya sinumang nag-e-edit nito nang umaasa ng file na INI ay sinisira ito. Ang inline na block na <auth-user-pass> ay naglalaman ng parehong dalawang linya sa profile, na ginagawang lihim ang profile mismo at inilalagay ito sa parehong klase ng paghawak ng pribadong key.

Ang iba pang dalawang landas ay stream at socket. OpenVPN ay nangangailangan lamang ng nababasang file descriptor, kaya tatanggapin nito ang pagpapalit ng proseso, entry na /dev/fd na sinusuportahan ng pipe o pangalan ng file na talagang FIFO. Ang interface ng pamamahala ay naiiba sa kalikasan: tinatanong ng kliyente ang prosesong nagmamatyag para sa mga halaga sa halip na basahin ang mga ito mismo. Mahalaga ang pagkakaibang iyon sa muling pagkonekta: ang file ng kredensyal, FIFO na muling masusulatan ng katulong ng lihim at ang interface ng pamamahala ay makapagbibigay muli nang walang tao; ang pagpapalit ng proseso ay hindi, dahil nauubos ang descriptor sa unang pagbasa.

Ang file ay dapat eksaktong dalawang linya

Dalawang mode ng pagkabigo ang sumasaklaw sa karamihan ng sirang file ng kredensyal. Ang editor ng Windows ay nag-iiwan ng CRLF na dulo, nagiging bahagi ng password ang carriage return, at tinatanggihan ng server ang halagang mukhang tama sa screen. Ang blangkong ikalawang linya - blangkong linya kung saan dapat naroon ang password - ay nag-iiwan sa kliyente ng blangkong password, na tinatanggihan ng server kahit mukhang tama ang halaga sa screen. Ang sobrang bagong linya pagkatapos ng password ay walang pinsala. Isulat ang file mula sa shell, hindi mula sa editor, at suriin ang mga byte:

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

Kasinghalaga ng nilalaman ang landas. Ang relatibong landas ay nireresolba laban sa working directory ng proseso, na para sa isang serbisyo ay bihirang ang direktoryo kung saan ka nagsubok. Gumamit ng absolutong landas, gawing pag-aari ng account na nagpapatakbo ng kliyente ang file at panatilihin ang mode 0600 upang hindi ito mabasa ng grupo at iba. Ang manwal ng OpenVPN 2.6 ay naglilista ng mga tinatanggap na anyo ng direktiba; tingnan ito bago ka mag-imbento ng pangatlo.

Subukan ang file bago mo sisihin ang server. Ang pagpapatakbo ng openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 ay nagpi-print kung nabuksan ang file at, sa kalaunan, kung tinanggap ang kredensyal, na nagsasabi sa iyo kung aling layer ang babaguhin sa susunod.

Mga stream, stdin at ang mga error na nalilikha nila

Ang pagpapadala ng password sa pipe ay ang unang sinusubukan ng karamihan at ang landas na may pinakamaraming sorpresa. Gumagana ang pagpapalit ng proseso dahil nababasang descriptor lamang ang kailangan ng kliyente: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). Gumagana lamang ang pagpapasa ng /dev/stdin kapag bukas pa at nababasa ang stdin sa sandaling magtanong ang kliyente, na hindi totoo sa pipeline na nagamit na ito.

ERROR: could not read Auth username from stdin ay may dalawang magkaibang dahilan. Sa ilang kliyenteng 2.3.x ang mensahe ay nagmula sa depekto sa paghawak ng stdin na inayos ng mga susunod na release ng 2.3, kaya ang napaka lumang kliyente ay bubuti lamang sa pag-upgrade. Sa kasalukuyang kliyente ang parehong pananalita ay nangangahulugang humingi ang kliyente ng input sa console at hindi terminal ang stdin - eksaktong sitwasyon sa yunit ng systemd, trabahong cron o container na sinimulan nang walang -t.

auth-nocache ay nagdaragdag ng ikatlong loop na parang sirang password. Itinatapon nito ang kredensyal mula sa memorya pagkatapos gamitin, kaya ang muling pagkonektang dulot ng pagbabago ng network ay walang muling ipe-play at bumabalik ang prompt. Iyon ang direktibang gumagana ayon sa disenyo. Binabago ng auth-nocache ang itinatago ng kliyente sa memorya, hindi ang iniisip ng server o tagapagbigay ng pagkakakilanlan tungkol sa account, kaya ang buong pagwawasto ay ibigay muli ang parehong file, muling binabasa sa restart - at para sa pinamamahalang koneksyon ang pagbibigay na iyon ay dapat magmula sa aprubadong imbakan ng lihim, hindi sa password sa isang script.

Ang interface ng pamamahala kapag pag-aari ng ibang proseso ang prompt

Ang controller na nagmamatyag na sa tunnel ay makakasagot din sa mga tanong nito. Simulan ang kliyente gamit ang --management 127.0.0.1 7505, basahin ang mga linya ng status at bantayan ang >PASSWORD:Need 'Auth' username/password. Sumasagot ang controller ng username "Auth" alice na sinusundan ng password "Auth" ... sa magkahiwalay na linya ng command. Inuulit ng token na 'Auth' ang identifier mula sa kahilingan at dapat tumugma, kung hindi ay binabalewala ang sagot at naghihintay ang kliyente.

Ang halaga ay isang state machine na pag-aari mo na ngayon: pagkakasunod-sunod ng mga koneksyon, mga restart ng kliyente at lokal na socket na hindi dapat maabot ng ibang user sa host. Ang binibili mo ay kredensyal na ibinigay sa runtime, walang file sa disk at walang prompt na maaaring sumabit. Kung wala nang iba sa stack mo na nagsasalita na ng protocol na ito, nagdaragdag ang landas na ito ng komponenteng kailangang alagaan.

Mga pagkabigong parang problema sa kredensyal

Ang TLS handshake na hindi natatapos, o isang VERIFY ERROR: depth=0, error=certificate signature failure, ay problema sa tiwala at nangyayari bago mabasa ang anumang username. Ang kliyenteng proto tcp na nakaturo sa tagapakinig ng UDP ay nabibigo sa parehong lugar: hindi kailanman nakakarating ang mga packet sa yugto ng authentication, kaya ang bawat password ay parang mali dahil sa asosasyon. Panatilihing bukas ang verification ng sertipiko bago ipadala ang kredensyal; walang sinasabi ang pamilyar na prompt tungkol sa kung sino ang tumatanggap ng password. Suriin ang chain ng sertipiko, common name at transport bago hawakan ang kredensyal.

Ang mga error ng shell sa script na nagbubuo ng profile ang isa pang huwad na bakas. Ang kulang na espasyo sa loob ng [ ! -f "$file" ] ay gumagawa ng command not found, humihinto nang maaga ang script, hindi kailanman muling nabuo ang profile at nagsisimula ang kliyente sa nauna. Ang error na iyon ay pag-aari ng shell, hindi ng authentication, at gaano man karaming beses mong i-type muli ang password ay hindi ito mabubura.

Hindi lahat ng prompt sa daloy na ito ay ang kredensyal na ito. Ang passphrase ng pribadong key, pag-login sa proxy ng HTTP at password ng serbisyo ay tatlong magkaibang lihim na hinihingi sa magkaibang yugto, at ang passphrase ng key ay karaniwang hinahawakan ng kliyente o ahente sa halip na auth-user-pass. Kung lumitaw ang prompt bago maitayo ang session ng TLS, sumasagot ka sa maling tanong at walang pag-reset ng account ang makakatulong. Kapag naibukod na ang maling prompt, nagsisimula ang natitirang pagsusuri sa pinakaunang layer:

• Basahin ang unang error ng protocol, hindi ang huling linya ng kredensyal: TLS, pagkatapos authentication, pagkatapos push.
• Kumpirmahin na ang file ay dalawang linya, walang carriage return at tinutukoy ng absolutong landas.
• Kumpirmahin na ang profile at command line ay hindi nagkakasalungat tungkol sa direktiba.
• Ihiwalay ang "tinanggap ang kredensyal" sa "dumadaloy ang trapiko" - ang routing at DNS ay susunod na layer.

Kapag naabot ng kliyente ang yugto ng push, tigilan ang pagtingin sa kredensyal at simulang basahin ang mga ruta at server ng DNS na ipinadala ng server. Iyon ang susunod na problema, at wala itong kinalaman sa password na kakalutas mo lang.