Binabasa ng OpenVPN ang password mula sa terminal, hindi sa stdin

OpenVPN humihingi ng username at password sa controlling terminal, at ang file na nakaredirect sa standard input ay hindi ang terminal na iyon. Ang isang detalyeng iyon ang nagpapaliwanag sa script na bumabitin habang ang password ay naroon sa tubo. Ang prompt ay iginuguhit ng client at ang pagbasa ay galing sa terminal device, kaya walang nababago kapag ini-redirect ang stdin. Pakainin ang client sa pamamagitan ng isa sa mga dokumentadong input nito at kokonekta ang parehong script sa unang pagtatangka.

Tatlong paraan ang sumasaklaw sa halos lahat ng kaso, at bawat isa ay nabibigo sa sariling paraan. Pumili ayon sa prompt na talagang ipinapakita ng client, hindi ayon sa opsyong pinakamadaling i-script.

Hindi galing sa stdin ang prompt

Kapag kailangan ng OpenVPN ng credentials, binubuksan nito ang controlling terminal at doon nagbabasa. Kaya mukhang maayos ang interactive na pagsubok habang ang parehong command sa ilalim ng cron o file ng unit ay nakatayong walang galaw na may prompt na nakasulat sa log na walang tumitingin. Ang ilang build ay bumabalik sa standard input kapag walang terminal, at ang inkonsistensiyang iyon ay mas malala kaysa matigas na pagkabigo dahil itinatago nito ang problema hanggang sa deployment.

Suriin ang kapaligiran bago magsulat ng anumang code: patakbuhin ang client sa ilalim ng parehong user, gamit ang parehong stdin, tulad ng gagawin ng scheduler o service manager. Kung hindi kailanman lumilitaw ang prompt sa log at hindi umuusad ang proseso, may naghihintay ng terminal na wala.

Unang paraan: file ng credentials na may dalawang linya

Ang opsyon ng authentication ay tumatanggap ng path, at ang file ay may eksaktong dalawang linya, username muna at pagkatapos ang password, na walang iba. Ibigay ang path nang tahasan sa halip na umasa sa default na filename, dahil ang ligaw na file ng credentials sa working directory ang paraan para mapunta sa paggamit ang maling account. Itakda ang mode sa 0600 at ibigay ang pagmamay-ari sa account na nagpapatakbo ng client.

Binabasa ng client ang file na iyon nang isang beses sa pagsisimula, kaya ang pag-ikot ng password ay nangangahulugang pag-restart ng proseso. Karaniwang iyon ang gustong pag-uugali, at nabibilang ito sa runbook sa tabi ng pamamaraan ng pag-ikot.

Ikalawang paraan: askpass para sa passphrase ng key

Ang pribadong key na protektado ng passphrase ay nagluluwal ng pangalawa at ibang prompt, at may sariling sagot mula sa file: binabasa ng opsyong askpass ang passphrase mula sa unang linya ng isang file. Para sa mga tunnel na nakabatay sa SSH, ang katumbas ay programang askpass na pinapatakbo ng client, at ang standard output nito ang nagiging lihim.

Wala sa dalawang anyo ang naglalagay ng lihim sa listahan ng argument, at parehong hinahayaang umiral ito bilang file o bilang executable na naglilimbag nito. Ang proteksiyon ay mga pahintulot ng file at pagmamay-ari ng proseso, hindi kadiliman. Ang katulong na nag-echo ng hardcoded na string ay isang lihim na may dagdag na hakbang.

Ikatlong paraan: sariling CLI ng portal client

Karaniwang may command-line entry point ang mga enterprise client na kumokonekta sa pinangalanang portal nang walang anumang window, at iyon ang sinusuportahang paraan. Sa Linux, inilalantad ng GlobalProtect client ang mga operasyon ng pagkonekta at pag-import ng certificate sa pamamagitan ng CLI nito, at ang mga portal na gumagamit ng certificate authentication ay nangangailangan ng hakbang ng pag-import bago gumana ang automated na koneksiyon. Piliin ito kaysa sa sintetikong pagpindot ng key: nakakakuha ka ng tunay na exit status, walang pag-asa sa focus ng window, at nakakaligtas ito sa naka-lock na screen.

Kung ang unang koneksiyon ay nangangailangan pa ng tao para tanggapin ang certificate, hindi pa tapos ang automation. Gawin ang pag-import habang nagse-set up at itala ito bilang paunang kundisyon.

Kapag kailangan ng flow ang pseudo-terminal

Ang sekwensiyang humihingi ng password at pagkatapos ng one-time code ay walang iisang file na mababasa. Ang terminal driver tulad ng Expect ang tamang kasangkapan dahil hinihintay nito ang bawat pattern nang sunud-sunod, at kailangan nitong nakapagsimula na ang proseso bago ito makapagtugma ng anuman.

Dalawang pagkabigo ang nangingibabaw. Ang script na naghihintay ng prompt nang hindi sinisimulan ang client ay naghihintay magpakailanman, at ang Tcl ay hindi shell, kaya ang shell arithmetic na nakasulat sa loob ng expect block ay hindi sinusuri ayon sa pagbasa nito. Iwanang bukas ang debug flag habang binubuo ang mga pattern, at pagkatapos patayin ito.

Mga lihim na tumatagas, at saan sila nagtatago

Anumang ipinasa bilang argument ay nakikita sa listahan ng proseso, kaya ang credentials ay nabibilang sa file o sa likod ng katulong, hindi kailanman sa command line. Ang mga one-time code ay nauubos ayon sa disenyo at kailangang gawin para sa bawat pagtatangka. Ang mga log ng pagkabigo ay madalas may username at kung minsan higit pa, kaya i-redact ang mga ito bago ipadala kahit saan, at ilayo ang lihim mula sa profile mismo, dahil ang configuration file na may naka-embed na password ay nadidikit sa mga ticket at repository. Ang pag-ikot ng account ay nangangahulugan noon ng paghabol sa bawat kopya, at iyon ang eksaktong gastos na iniiwasan ng layout na ito.

I-audit ang mga paraang pinili mo, at pagkatapos ikabit ang mga ito sa file ng unit o sa scheduler na talagang magpapatakbo ng client. Ang tunnel ay nabubuhay nang eksaktong kasingtagal ng prosesong iyon.