Ang --key-password ba ng OpenConnect ay password ng iyong VPN account?

Basahin ang pangalan ng opsyon nang literal. Ito ay nagngangalan ng key, at ang kalituhan ay nagsisimula kapag ang file na binubuksan ay napagkamalang account na pinatutunayan. I-paste ang password ng account sa opsyong iyon at susubukan ng client na buksan ang isang key file gamit ito, na nabibigo dahil sa mga dahilan na walang kinalaman sa pag-login sa VPN.

Ang nakakalito ay maaaring lehitimong kailanganin ng isang koneksyon ang dalawang sikreto. Maaaring mangailangan ng naka-encrypt na key ang pagpapatunay ng certificate ng client, at maaari pa ring magsagawa ng palitan ng pagpapatunay ng user ang parehong gateway pagkatapos tanggapin ang certificate. Wala sa dalawang sikreto ang tumutugon sa kabilang yugto, at ang kabiguan sa isa ay mukhang halos katulad ng kabiguan sa isa kapag tiningnan mula sa labas.

Dalawang sikreto, dalawang magkaibang gawain

Basahin ang mga papel bilang pag-access sa file kumpara sa pagpasok sa network. Binibigkas ng password ng key ang pribadong PEM key na pinangalanan sa --sslkey upang maipakita ang certificate ng TLS client. Nangyayari ang pagbigkas na iyon nang lokal, sa loob ng proseso ng client, at ang passphrase mismo ay hindi kailanman naglalakbay patungo sa gateway. Ang nakikita ng gateway ay ang certificate at isang lagda na ginawa gamit ang key. Ang manwal ng OpenConnect ay naglalagay ng --key-password sa tabi ng --certificate at --sslkey, at sa mga build na makakagamit ng key na inilagay sa TPM, ang parehong opsyon ay nagdadala sa halip ng password ng root key ng imbakan.

Ang password ng account ay ibang uri. Ito ay pumapasok sa palitan ng pagpapatunay: isang form ng username at password, isang token, isang SAML round trip, o ilang kombinasyon na inihayag ng gateway. May mga deployment na hindi ito hinihingi kapag ang certificate ang tanging salik, at may mga humihingi nito kahit pagkatapos ng certificate, dahil ang certificate ay nagpapatunay ng device habang ang account ay nagpapatunay ng tao.

Ang paghahalo ng dalawa ay gumagawa ng nakalilinlang na mga error. Ang gateway na tumatanggi sa login ay karaniwang nag-uulat ng kabiguan sa pagpapatunay, samantalang ang maling passphrase ng key ay karaniwang nabibigo nang mas maaga, kapag hindi mabasa ng TLS layer ang key file. Magkaibang yugto ang mga ito na may magkaibang lunas, at sapat ang pagkakahawig ng mga pangalan para pagpalitin sila ng mga tao at pagkatapos habulin ang maling log. Pansinin kung aling prompt ang lumitaw bago mo baguhin ang anumang setting, dahil ang pananalita ng prompt ang pinakamurang diagnosis na mayroon ka.

Kailan talaga kailangan ang password ng key

May saysay lamang ang opsyon kapag may naka-encrypt na key na bubuksan. Kung kumokonekta ka gamit ang username at password at walang certificate ng client, walang maaaksyunan ang --key-password, at walang nababago sa pagsasama nito. Kung kumokonekta ka gamit ang --certificate at --sslkey, ang mismong format ng key file ang nagpapasya kung hihingin ang passphrase.

Karaniwan sa mga pinamamahalaang kapaligiran ang dalawang sikreto sa isang utos: isang certificate ng device sa isang naka-encrypt na key, kasama ang pag-sign in ng bawat user. Ang tamang pagkakasunod-sunod ay hayaan ang client na humingi ng passphrase ng key nang lokal, tapusin ang handshake ng certificate, at pagkatapos ay hiwalay na asikasuhin ang prompt ng account ng gateway. Ang pagtatangkang punan nang maaga ang dalawa sa pamamagitan ng isang script na ginagamit muli ang siyang lugar kung saan karaniwang nagsisimula ang kalituhan.

Ang kapaki-pakinabang na diagnosis ay tingnan kung kailan nangyayari ang kabiguan. Kung huminto ang client bago magsimula ang anumang pagpapatunay ng network, hinala ang key file, ang format nito, o ang passphrase. Kung naitatag ang TLS session at pagkatapos ay tinatanggihan ng gateway ang user, nagawa ng key ang trabaho nito, at ang problema ay ang palitan ng account.

Panatilihin ang dalawang sikreto sa labas ng history ng shell

Ang mga argumento ng command line ay nababasa ng ibang lokal na user sa pamamagitan ng process table at madalas na nahuhuli sa history ng shell, sa mga script, at sa mga transcript ng suporta. Maaaring basahin ng OpenConnect ang password ng account mula sa standard input gamit ang --passwd-on-stdin, at ang passphrase ng key ay maaaring manggaling sa interactive na prompt o sa isang agent sa halip na sa argumento. Walang mekanismong nagpapasiguro ng sikreto nang mag-isa, ngunit parehong inilalayo ito ng dalawa mula sa pinakalantad na lugar.

Ang mga file ay karapat-dapat sa parehong pag-iingat. Dapat gawin ng script na nagsusulat ng passphrase sa isang pansamantalang file na may mahigpit na pahintulot, burahin ito sa paglabas, at iwasan ang mga direktoryong nababasa ng lahat. Ang passphrase na nananatili pagkatapos ng session sa isang pansamantalang direktoryo ay isang kopyang nakalimutan mong gawin. Ang mga environment variable ay nakikita ng mga child process at madalas na ipinapakita ng mga debugging tool, kaya hindi ito libreng pagpapabuti kumpara sa mga argumento.

Ang diagnostic output ay ang tahimik na pagtagas. Ang mga log ng client sa mas mataas na detalye ay maaaring magpakita ng katawan ng kahilingan o mga halaga ng opsyon, at ang nakopyang terminal transcript ay madaling i-paste sa isang ticket, kaya basahin ang output bago ito ibahagi.

Ang patay na button sa desktop ay ibang depekto

Ang isang entry ng VPN sa desktop na nagpapakita ng umiikot na indicator at pagkatapos ay wala ay karaniwang hindi problema sa pagpapatunay. Ang button ay pag-aari ng isang network manager, applet ng vendor, o plugin na naglulunsad ng OpenConnect sa ngalan mo, at ang nawawalang bahagi o hindi mababasang profile ay maaaring gumawa ng eksaktong sintomas na iyon. Alamin kung anong proseso ang sinisimulan ng button at basahin ang error nito bago hawakan ang mga kredensyal.

Nakakatukso na luwagan ang pagpapatunay ng certificate o patayin ang isang tsek kapag ayaw kumonekta ng GUI. Ginagawa nitong downgrade sa seguridad ang depekto sa integrasyon ng client at bihirang ayusin ang problema sa paglulunsad. Panatilihing buo ang pagpapatunay ng server, tiyakin na ang profile ay nakaturo sa nilalayong gateway, at tingnan kung talagang naka-install ang helper na inaasahan ng GUI.

Ang maikling checklist ay naghihiwalay ng mga kaso. Ang lokal na kabiguan bago lumabas ang anumang packet ay nagtuturo sa key o sa pag-install ng client. Ang pagtanggi ng gateway pagkatapos ng TLS session ay nagtuturo sa palitan ng account. Ang button na hindi kailanman naglulunsad ng client ay nagtuturo sa integrasyon sa desktop. Tatlong magkaibang depekto, at ang isa ay isang password na malapit mo nang i-paste sa maling kahon.