Is --key-password fan OpenConnect dyn VPN-accountwachtwurd?

Lês de namme fan 'e opsje letterlik. Hy neamt in kaaai, en de betizing begjint as it bestân dat ûntsletten wurdt ferwiksele wurdt mei it account dat autentisearre wurdt. Plak it accountwachtwurd yn dy opsje en de klant sil besykje dêrmei in kaaibestân te iepenjen, wat mislearret om redenen dy't neat mei de VPN-oanmelding te meitsjen hawwe.

It betiizjende is dat ien ferbining legitym beide geheimen nedich wêze kin. Autentikaasje mei in kliïntsertifikaat kin in fersifere kaaai easkje, en deselde gateway kin nei it akseptearjen fan it sertifikaat noch in brûkersautentikaasje-útwikseling útfiere. Gjin fan beide geheimen foldocht oan 'e oare stap, en in mislearring yn 'e iene liket fan bûten tige op in mislearring yn 'e oare.

Twa geheimen, twa ferskillende taken

Lês de rollen as bestânstoegong tsjin netwurk tagong. It kaaaiwachtwurd ûntsiferet de PEM-priveekaaai dy't yn --sslkey neamd wurdt, sadat it TLS-kliïntsertifikaat presintearre wurde kin. Dy ûntsifering bart pleatslik, binnen it klantproses, en de wachtwurdsin reizget sels nea nei de gateway. Wat de gateway sjocht, binne it sertifikaat en in hantekening makke mei de kaaai. De hânlieding fan OpenConnect hâldt --key-password njonken --certificate en --sslkey, en op builds dy't in kaaai yn in TPM brûke kinne, draacht deselde opsje ynstee it wachtwurd fan 'e opslachrootkaaai.

It accountwachtwurd is oars fan aard. It giet yn 'e autentikaasje-útwikseling: in formulier mei brûkersnamme en wachtwurd, in token, in SAML-rûn of in kombinaasje dy't de gateway oankundiget. Guon ynsetten freegje der hielendal net om as it sertifikaat de iennige faktor is, en guon freegje der sels nei in sertifikaat om, om't it sertifikaat it apparaat bewiist wylst it account de persoan bewiist.

It mingjen fan 'e beide soarget foar misliedende flaters. In gateway dy't in oanmelding wegeret, meldt meastentiids in autentikaasjeflater, wylst in ferkearde kaaaiwachtwurdsin meastentiids earder mislearret, as de TLS-laach it kaaibestân net lêze kin. Dat binne ferskillende stappen mei ferskillende oplossingen, en de nammen lykje genôch op inoar dat minsken se omwikselje en dan efter it ferkearde logboek oan gean. Merk op hokker fregetoanstân ferskynde foardat jo in ynstelling feroarje, want de wurden fan 'e fregetoanstân binne de goedkeapste diagnostyk dy't jo hawwe.

Wannear't it kaaaiwachtwurd echt nedich is

De opsje hat allinnich sin as der in fersifere kaaai is om te ûntsluten. As jo ferbine mei brûkersnamme en wachtwurd en sûnder kliïntsertifikaat, hat --key-password neat om op te wurkjen, en it tafoegjen feroaret neat. As jo ferbine mei --certificate en --sslkey, beslút it eigen formaat fan it kaaibestân oft der al of net in wachtwurdsin frege wurdt.

Beide geheimen yn ien opdracht binne gewoan yn behearde omjouwings: in apparaatsertifikaat yn in fersifere kaaai, plus in oanmelding per brûker. De goede folchoarder is de klant pleatslik om 'e kaaaiwachtwurdsin freegje te litten, de sertifikaathânskodding te foltôgjen en dan it accountfregetoanstân fan 'e gateway apart te behanneljen. Besykje beide foarôf te foljen fia ien werbrûkt skript is wêr't de betizing meastentiids begjint.

In nuttige diagnostyk is sjen wannear't de flater bart. As de klant stopt foardat hokker netwurkautentikaasje dan ek begjint, fertink dan it kaaibestân, syn formaat of de wachtwurdsin. As de TLS-sesje ta stân komt en de gateway de brûker dêrnei wegeret, hat de kaaai syn wurk dien en is de account-útwikseling it probleem.

Hâld beide geheimen bûten de shell-skiednis

Opdrachtrigel-arguminten binne troch oare pleatslike brûkers lêsber fia de prosestabel en wurde faak fêstlein yn shell-skiednis, skripts en stipe-transkripsjes. OpenConnect kin it accountwachtwurd fan standertynfier lêze mei --passwd-on-stdin, en de kaaaiwachtwurdsin kin fan in ynteraktive fregetoanstân of in agent komme ynstee fan in argumint. Gjin meganisme makket it geheim op himsels feilich, mar beide hâlde it bûten de meast bleatstelde plakken.

Bestannen fertsjinje deselde soarch. In skript dat in wachtwurdsin nei in tydlik bestân skriuwt, moat it mei beheinde rjochten oanmeitsje, it by it ôfsluten wiskje en mappen mije dy't foar elkenien lêsber binne. In wachtwurdsin dy't de sesje yn in tydlike map oerlibbet, is in kopy dy't jo fergetten te meitsjen. Omjouwingsfariabelen binne sichtber foar bernprosessen en wurde faak troch debug-ark werjûn, dat se binne gjin fergees upgrade boppe arguminten.

Diagnostyske útfier is it stille lek. Klantlogboeken by hegere wiidweidichheit kinne oanfraachlichems of opsjewearden sjen litte, en in kopyearre terminaltranskripsje is maklik yn in ticket te plakken, dat lês de útfier foardat jo dy diele.

In deade buroblêdknop is in oare flater

In VPN-ynfier op it buroblêd dy't in draaiend yndikator sjen lit en dan neat, is meastentiids hielendal gjin autentikaasjeprobleem. De knop heart by in netwurkbehearder, in applet fan 'e leveransier of in plugin dy't OpenConnect foar jo start, en in ûntbrekkende komponint of unlêsber profyl kinne krekt dat symptoom jouwe. Fyn út hokker proses de knop start en lês syn flater foardat jo oan legitimaasjes komme.

It is ferliedlik om sertifikaatferifikaasje te fersachtjen of in kontrôle út te skeakeljen as de GUI wegeret te ferbinen. Dat feroaret in klantyntergraasjeflater yn in feiligensferleging en reparearret it startprobleem selden. Hâld serverferifikaasje yntakt, befêstigje dat it profyl nei de bedoelde gateway wiist, en kontrolearje oft de helper dy't de GUI ferwachtet echt ynstallearre is.

In koarte kontrôlelijst skiedt de gefallen. In pleatslike flater foardat der in pakket fuortgiet wiist op 'e kaaai of de klantynstallaasje. In wegering troch de gateway nei de TLS-sesje wiist op 'e account-útwikseling. In knop dy't de klant nea start, wiist op 'e buroblêdyntergraasje. Trije ferskillende flaters, wêrfan ien in wachtwurd is dat jo op it punt stiene yn it ferkearde fak te plakken.