Ĉu --key-password de OpenConnect estas la pasvorto de via VPN-konto?

Legu la nomon de la opcio laŭvorte. Ĝi nomas ŝlosilon, kaj la konfuzo komenciĝas kiam la dosiero malŝlosata estas konfuzata kun la konto aŭtentikigata. Algluu la kontan pasvorton en tiun opcion kaj la kliento provos malfermi per ĝi ŝlosildosieron, kio malsukcesas pro kaŭzoj tute ne rilataj al la VPN-ensaluto.

La konfuza parto estas, ke unu konekto povas laŭleĝe bezoni ambaŭ sekretojn. Klienta atestila aŭtentikigo povas postuli ĉifritan ŝlosilon, kaj la sama pordego povas poste fari uzantan aŭtentikigan interŝanĝon post kiam la atestilo estas akceptita. Neniu sekreto plenumas la alian etapon, kaj malsukceso en unu aspektas de ekstere tre simile al malsukceso en la alia.

Du sekretoj, du malsamaj taskoj

Legu la rolojn kiel dosiera aliro kontraŭ reta allaso. La ŝlosila pasvorto malĉifras la privatan PEM-ŝlosilon nomatan en --sslkey, por ke la TLS-klienta atestilo povu esti prezentata. Tiu malĉifrado okazas loke, ene de la klienta procezo, kaj la pasfrazo mem neniam vojaĝas al la pordego. Kion la pordego vidas, estas la atestilo kaj subskribo farita per la ŝlosilo. La manlibro de OpenConnect tenas --key-password apud --certificate kaj --sslkey, kaj ĉe versioj, kiuj povas uzi ŝlosilon en TPM, la sama opcio portas anstataŭe la pasvorton de la stoka radika ŝlosilo.

La konta pasvorto estas alispeca. Ĝi eniras la aŭtentikigan interŝanĝon: formularo kun uzantnomo kaj pasvorto, ĵetono, SAML-ciklo aŭ ia kombinaĵo, kiun la pordego anoncas. Iuj instaloj tute ne petas ĝin kiam la atestilo estas la sola faktoro, kaj iuj petas ĝin eĉ post atestilo, ĉar la atestilo pruvas la aparaton dum la konto pruvas la personon.

Miksi la du kreas trompajn erarojn. Pordego, kiu rifuzas ensaluton, kutime raportas aŭtentikigan malsukceson, dum malĝusta ŝlosila pasfrazo kutime malsukcesas pli frue, kiam la TLS-tavolo ne povas legi la ŝlosildosieron. Tiuj estas malsamaj etapoj kun malsamaj riparioj, kaj la nomoj estas sufiĉe similaj, ke homoj interŝanĝas ilin kaj poste postkuras la malĝustan protokolon. Notu, kiu invito aperis antaŭ ol vi ŝanĝos ajnan agordon, ĉar la vortigo de la invito estas la plej malmultekosta diagnozo, kiun vi havas.

Kiam la ŝlosila pasvorto vere necesas

La opcio havas sencon nur kiam estas ĉifrita ŝlosilo por malŝlosi. Se vi konektiĝas per uzantnomo kaj pasvorto kaj sen klienta atestilo, --key-password havas nenion sur kion agi, kaj aldoni ĝin ŝanĝas nenion. Se vi konektiĝas per --certificate kaj --sslkey, la propra formato de la ŝlosildosiero decidas ĉu pasfrazo entute estos petata.

Ambaŭ sekretoj en unu komando estas oftaj en administrataj medioj: aparata atestilo en ĉifrita ŝlosilo, plus ensaluto por ĉiu uzanto. La ĝusta sinsekvo estas lasi la klienton peti la ŝlosilan pasfrazon loke, fini la atestilan manpremadon, kaj poste trakti la kontan inviton de la pordego aparte. Provii antaŭplenigi ambaŭ per unu reuzata skripto estas kie la konfuzo kutime komenciĝas.

Utila diagnozo estas rigardi, kiam la malsukceso okazas. Se la kliento haltas antaŭ ol iu reta aŭtentikigo komenciĝas, suspektu la ŝlosildosieron, ĝian formaton aŭ la pasfrazon. Se la TLS-sesio establiĝas kaj la pordego poste rifuzas la uzanton, la ŝlosilo faris sian taskon kaj la problemo estas la konta interŝanĝo.

Tenu ambaŭ sekretojn ekster la ŝela historio

Komandliniaj argumentoj estas legeblaj de aliaj lokaj uzantoj tra la procesa tabelo kaj ofte kaptiĝas en ŝela historio, skriptoj kaj subtenaj transskriboj. OpenConnect povas legi la kontan pasvorton el la norma enigo per --passwd-on-stdin, kaj la ŝlosila pasfrazo povas veni el interaga invito aŭ agento anstataŭ el argumento. Neniu mekanismo mem faras la sekreton sekura, sed ambaŭ tenas ĝin ekster la plej elmetitaj lokoj.

Dosieroj meritas la saman zorgon. Skripto, kiu skribas pasfrazon al provizora dosiero, devus krei ĝin kun restriktaj permesoj, forigi ĝin ĉe eliro kaj eviti dosierujojn legeblajn de ĉiuj. Pasfrazo, kiu postvivas la sesion en provizora dosierujo, estas kopio, kiun vi forgesis fari. Ĉirkaŭaj variabloj estas videblaj al infanaj procezoj kaj ofte eĥitaj de sencimigaj iloj, do ili ne estas senpaga plibonigo super argumentoj.

Diagnoza eligo estas la silenta liko. Klientaj protokoloj ĉe pli alta detalo povas montri petajn korpojn aŭ opciajn valorojn, kaj kopiita terminala transskribo facile algluiĝas en bileto, do legu la eligon antaŭ ol dividi ĝin.

Malviva labortabla butono estas alia fuŝo

Labortabla VPN-ero, kiu montras turniĝantan indikilon kaj poste nenion, kutime tute ne estas aŭtentikiga problemo. La butono apartenas al retadministrilo, vendista apleto aŭ kromaĵo, kiu lanĉas OpenConnect nome de vi, kaj mankanta komponanto aŭ nelegebla profilo povas produkti ĝuste tiun simptonon. Trovu, kiun procezon la butono lanĉas, kaj legu ties eraron antaŭ ol tuŝi akreditaĵojn.

Estas tentate malfortigi atestilan kontrolon aŭ malŝalti kontrolon kiam la grafika fasado rifuzas konektiĝi. Tio transformas klientan integriĝan fuŝon en sekurecan malsupreniĝon kaj malofte riparias la lanĉan problemon. Tenu la servilan kontrolon sendifekta, konfirmu ke la profilo montras al la intencita pordego, kaj kontrolu ĉu la helpilo, kiun la grafika fasado atendas, estas vere instalita.

Mallonga kontrololisto disigas la kazojn. Loka malsukceso antaŭ ol iu ajn paketo forlasas montras al la ŝlosilo aŭ la klienta instalado. Pordega rifuzo post la TLS-sesio montras al la konta interŝanĝo. Butono, kiu neniam lanĉas la klienton, montras al la labortabla integriĝo. Tri malsamaj fuŝoj, unu el kiuj estas pasvorto, kiun vi estis preta alglui en la malĝustan kampon.