Er OpenConnect sin --key-password VPN-kontopassordet ditt?

Les namnet på valet bokstaveleg. Det namngir ein nøkkel, og forvirringa startar når fila som blir låst opp blir forveksla med kontoen som blir autentisert. Lim inn kontopassordet i det valet, og klienten vil prøve å opne ei nøkkelfil med det, noko som mislukkast av grunnar som ikkje har noko med VPN-innlogginga å gjere.

Det forvirrande er at éi enkel tilkopling lovleg kan trengje begge hemmelegheitene. Klientsertifikatautentisering kan krevje ein kryptert nøkkel, og same gateway kan framleis køyre ei brukarautentiseringsutveksling etter at sertifikatet er godteke. Ingen av hemmelegheitene oppfyller det andre trinnet, og ein feil i den eine ser utanfrå svært lik ut som ein feil i den andre.

To hemmelegheiter, to ulike oppgåver

Les rollene som filtilgang kontra nettilgang. Nøkkelpassordet dekrypterer den private PEM-nøkkelen som er oppgjeven i --sslkey, slik at TLS-klientsertifikatet kan presenterast. Den dekrypteringa skjer lokalt, inne i klientprosessen, og sjølve passfrasa reiser aldri til gatewayen. Det gatewayen ser, er sertifikatet og ein signatur laga med nøkkelen. Handboka til OpenConnect held --key-password ved sida av --certificate og --sslkey, og på bygg som kan bruke ein nøkkel i ein TPM ber same valet i staden passordet til rotnøkkelen i lagringa.

Kontopassordet er av ein annan type. Det går inn i autentiseringsutvekslinga: eit skjema med brukarnamn og passord, eit token, ein SAML-runde eller ein eller annan kombinasjon som gatewayen annonserer. Nokre utplasseringar spør ikkje om det i det heile når sertifikatet er den einaste faktoren, og nokre spør sjølv etter eit sertifikat, fordi sertifikatet provar eininga medan kontoen provar personen.

Å blande dei to gir misvisande feil. Ein gateway som avviser ei innlogging, rapporterer vanlegvis ein autentiseringsfeil, medan ei feil nøkkelpassfrase vanlegvis mislukkast tidlegare, når TLS-laget ikkje kan lese nøkkelfila. Det er ulike trinn med ulike rettingar, og namna liknar nok til at folk byter dei og deretter jagar feil logg. Legg merke til kva førespurnad som dukka opp før du endrar noka innstilling, fordi ordlyden i førespurnaden er den billegaste diagnosen du har.

Når nøkkelpassordet faktisk trengst

Valet er berre meiningsfullt når det finst ein kryptert nøkkel å låse opp. Viss du koplar til med brukarnamn og passord og utan klientsertifikat, har --key-password ingenting å verke på, og å ta det med endrar ingenting. Viss du koplar til med --certificate og --sslkey, avgjer formatet til nøkkelfila sjølv om det i det heile blir spurt om ei passfrase.

Begge hemmelegheitene i éin kommando er vanleg i styrte miljø: eit einingssertifikat i ein kryptert nøkkel, pluss ei innlogging per brukar. Riktig rekkjefølgje er å la klienten spørje om nøkkelpassfrasa lokalt, fullføre sertifikathandtrykket og deretter handsame kontoførespurnaden frå gatewayen separat. Forsøket på å førehandsfylle begge gjennom eitt gjenbrukt skript er der forvirringa vanlegvis startar.

Ein nyttig diagnose er å sjå når feilen skjer. Viss klienten stoppar før noka nettverksautentisering byrjar, mistenk nøkkelfila, formatet eller passfrasa. Viss TLS-økta er etablert og gatewayen deretter avviser brukaren, gjorde nøkkelen jobben sin, og problemet er kontoutvekslinga.

Hald begge hemmelegheitene unna skalhistoria

Kommandolinjeargument er lesbare for andre lokale brukarar gjennom procestabellen og blir ofte fanga i skalhistorie, skript og støttetranskripsjonar. OpenConnect kan lese kontopassordet frå standardinndata med --passwd-on-stdin, og nøkkelpassfrasa kan kome frå ein interaktiv førespurnad eller ein agent i staden for eit argument. Ingen av mekanismane gjer hemmelegheita trygg i seg sjølv, men begge held ho unna dei mest utsette stadene.

Filer fortener same omhug. Eit skript som skriv ei passfrase til ei mellombels fil, bør opprette ho med strenge løyve, slette ho ved avslutning og unngå katalogar som alle kan lese. Ei passfrase som overlever økta i ein mellombels katalog, er ein kopi du gløymde å lage. Miljøvariablar er synlege for barneprosessar og blir ofte attgjevne av feilsøkingsverktøy, så dei er ikkje ei gratis oppgradering framfor argument.

Diagnostisk utdata er den stille lekkasjen. Klientloggar med høgare detaljgrad kan vise førespurnadstekstar eller valverdiar, og ein kopiert terminaltranskripsjon er lett å lime inn i ei sak, så les utdataene før du deler dei.

Ein daud skrivebordsknapp er ein annan feil

Eit VPN-element på skrivebordet som viser ein snurrar og deretter ingenting, er vanlegvis ikkje eit autentiseringsproblem i det heile. Knappen høyrer til ein nettverkshandsamar, eit leverandørapplet eller eit programtillegg som startar OpenConnect på dine vegner, og ein manglande komponent eller uleseleg profil kan gi nøyaktig det symptomet. Finn ut kva prosess knappen startar, og les feilen før du rører ved påloggingsinformasjon.

Det er freistande å lempe på sertifikatverifiseringa eller slå av ein sjekk når GUI-et nektar å kople til. Det gjer ein klientintegrasjonsfeil om til ei sikkerheitsnedgradering og løyser sjeldan oppstartsproblemet. Hald serververifiseringa intakt, stadfest at profilen peiker på den tiltenkte gatewayen, og sjekk at hjelparen GUI-et ventar faktisk er installert.

Ei kort sjekkliste skil tilfella. Ein lokal feil før nokon pakke forlèt maskina, peiker på nøkkelen eller klientinstallasjonen. Ei avvising frå gatewayen etter TLS-økta peiker på kontoutvekslinga. Ein knapp som aldri startar klienten, peiker på skrivebordsintegrasjonen. Tre ulike feil, der ein av dei er eit passord du var i ferd med å lime inn i feil felt.