auth-nocache kasama ng file ng kredensyal: nakakatulong o nakakasama?

OpenVPN naglilimbag ng babala sa pagsisimula na nagmumungkahi ng auth-nocache, at ang nakatutuksong tugon ay idagdag ang opsyon at panoorin ang linyang mawala. Ipinapalagay ng payong iyon ang interaktibong pag-login. Kapag naninirahan na ang username at password sa isang file, nagbabago ang paghahambing: tumitigil ang opsyon sa pagprotekta sa matibay na kopya, at sa isang kliyenteng nagbibitiw ng pribilehiyo maaari nitong masira ang muling pakikipagkasundo mamaya. Dalawang modelo ng imbakan ang dapat ihiwalay bago mo i-edit ang isang profile.

Dalawang paraan ng pagsagot sa hiling ng kredensyal

Ang unang modelo ay isang tao na nagta-type ng kredensyal sa terminal, o isang interface ng pamamahala na humahawak sa mga ito para sa session. Itinatago ng OpenVPN ang kopyang iyon upang makasagot sa susunod na muling pakikipagkasundo nang hindi muling nagtatanong, at iyon mismo ang tinutukoy ng babala. Walang anumang nasa disk na kasangkot, kaya ang tanging dapat protektahan ay ang prosesong humahawak sa halaga. Isara ang kliyente at mawawala ang kopya kasama nito.

Ang ikalawang modelo ay auth-user-pass na tumuturo sa isang file, kung saan ang file ang imbakan at binabasa ito ng kliyente kapag kailangan ang isang halaga. Ang pagkakalantad na mahalaga rito ay hindi memorya ng proseso kundi ang mga pahintulot at pagmamay-ari ng file na iyon. Ang babala sa pagsisimula ay nagmumula sa mga direktiba sa config, hindi sa pagsusuri kung paano mo ibinibigay ang password, kaya lumilitaw ito sa dalawang modelo at hindi tumuturo sa alinman.

Ang natitira sa paghahambing na ito ay sumusunod mula sa pagkakahating iyon: pamamahala ng memorya para sa isang modelo, pamamahala ng file at pagkakakilanlan ng proseso para sa isa.

Ano ang aktwal na itinatapon ng auth-nocache

Sa interaktibong pag-login, --auth-nocache inaalis ang naka-store na kopya mula sa memorya pagkatapos gamitin. Ang halaga ay isang bagong hiling sa bawat pagitan ng muling pakikipagkasundo, dahil hindi magagamit muli ng susunod na pag-ikot ang itinapon.

Sa pag-login na nakabatay sa file, mababasa muli ng kliyente ang file, kaya halos hindi nakikita ang pagtatapon. Nagiging nakikita ito sa nag-iisang lugar na hindi inaasahan ng mga tao: pagkatapos bitiwan ng daemon ang mga pribilehiyo, kung ang file ng kredensyal ay hindi mabasa ng account na pinapatakbo nito ngayon.

Idagdag ang opsyon dahil nauunawaan mo ang pagpapalit na iyon, hindi dahil may lumitaw na babala. Ang opsyong idinagdag upang gawing mas tahimik ang log ay opsyong walang sinumang sumukat ng epekto.

Saan nasisira ang landas na nakabatay sa file

Ang kliyenteng nagsisimula bilang root upang buksan ang tunnel device at pagkatapos ay lumilipat sa user at group ay nagbabasa ng file ng kredensyal nang dalawang beses: isang beses bago ang paglipat, isang beses sa muling pakikipagkasundo na sumusunod. Kung ang file ay nasa mode 600 at pag-aari ng root, nabigo ang ikalawang pagbasa, at ang kabiguan ay lumilitaw isang oras mamaya bilang error sa pagpapatunay na mukhang problema ng server. Tingnan ang log ng kliyente sa paligid ng pagitan ng muling pakikipagkasundo, pagkatapos tingnan ang account at ang file nang magkasama.

stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | head

Mahalaga ang dalawang linya. Sinasabi ng una kung sino ang makakabasa ng file, sinasabi ng ikalawa kung sino talaga ang tumatakbong daemon, at ang pagkakaiba ng dalawa ay nagpapaliwanag ng kabiguan na hindi maayos ng paulit-ulit na pag-type muli ng password.

Ang mga praktikal na pagwawasto ay hindi kasingningning: ilipat ang file sa isang direktoryo at may-ari na mababasa ng account ng daemon, o panatilihin ang pribilehiyadong pagbasa at tiyakin na minsan lang nagbabasa ang kliyente mo. Huwag itong lutasin sa pamamagitan ng gawing mababasa ng lahat ang file.

Ang kasong talagang nagnanais ng opsyon

Ang pag-login na may dalang one-time code ay nagnanais ng auth-nocache sa ibang dahilan. Ang one-time code ay nagagamit ng unang pagpapatunay, kaya walang silbi ang naka-cache na kopya sa susunod na muling pakikipagkasundo, at ang lumang halaga ay maaari pang maulit.

Ito ay tanong tungkol sa uri ng kredensyal, hindi tungkol sa kung saan ito nakaimbak. Ang static na password sa protektadong file ay may kabaligtarang profile: kailangan itong mabasa sa bawat muling pakikipagkasundo, at ang proteksiyong kailangan mo ay nasa file.

Ihiwalay ang dalawang dahilang iyon sa mga komento ng profile, kung hindi ay ipapalagay ng susunod na administrador na naroon ang opsyon para sa dahilang pipiliin niya.

Ang paghahambing sa isang desisyon

Piliin ang interaktibong modelo kapag may tao at mahalaga ang kasariwaan, at tanggapin ang paulit-ulit na hiling bilang halaga nito. Piliin ang modelo ng file kapag tumatakbo ang kliyente nang walang pagmamatyag, at ilaan ang pagsisikap sa pagmamay-ari, mode at pagbitiw sa pribilehiyo.

Walang modelo ang gumagawa ng naka-store na password na ligtas nang mag-isa, at wala ring gumagawa sa babala sa pagsisimula na makabuluhan.

Kung ang babala ang tanging dahilan kung bakit binuksan mo ang profile, itala ang desisyon sa halip na hindi maipaliwanag na opsyon: ang kredensyal ay nagmumula sa file na mababasa ng account ng daemon, nakita nang nagtagumpay ang muling pakikipagkasundo, at ang seksiyon tungkol sa muling pakikipagkasundo sa manwal ng OpenVPN 2.6 ay nabasa bago binago ang pagitan nito. Ang talaang iyon ay mas matibay kaysa sa alinmang iisang flag.