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

Les navnet på alternativet bokstavelig. Det navngir en nøkkel, og forvirringen starter når filen som låses opp forveksles med kontoen som autentiseres. Lim inn kontopassordet i det alternativet, og klienten vil prøve å åpne en nøkkelfil med det, noe som mislykkes av grunner som ikke har noe med VPN-innloggingen å gjøre.

Det forvirrende er at én enkelt tilkobling lovlig kan trenge begge hemmelighetene. Klientsertifikatautentisering kan kreve en kryptert nøkkel, og samme gateway kan fortsatt kjøre en brukerautentiseringsutveksling etter at sertifikatet er godtatt. Ingen av hemmelighetene oppfyller det andre trinnet, og en feil i det ene ser utenfra svært lik ut som en feil i det andre.

To hemmeligheter, to forskjellige jobber

Les rollene som filtilgang kontra nettverkstilgang. Nøkkelpassordet dekrypterer den private PEM-nøkkelen som er angitt i --sslkey, slik at TLS-klientsertifikatet kan presenteres. Dekrypteringen skjer lokalt, inne i klientprosessen, og selve passfrasen reiser aldri til gatewayen. Det gatewayen ser, er sertifikatet og en signatur laget med nøkkelen. OpenConnects håndbok holder --key-password ved siden av --certificate og --sslkey, og på bygg som kan bruke en nøkkel i en TPM bærer samme alternativ i stedet passordet til lagringens rotnøkkel.

Kontopassordet er av en annen type. Det går inn i autentiseringsutvekslingen: et skjema med brukernavn og passord, et token, en SAML-runde eller en eller annen kombinasjon som gatewayen annonserer. Noen utplasseringer spør ikke om det i det hele tatt når sertifikatet er den eneste faktoren, og noen spør selv etter et sertifikat, fordi sertifikatet beviser enheten mens kontoen beviser personen.

Å blande de to gir villedende feil. En gateway som avviser en innlogging, rapporterer vanligvis en autentiseringsfeil, mens en feil nøkkelpassfrase vanligvis mislykkes tidligere, når TLS-laget ikke kan lese nøkkelfilen. Det er forskjellige trinn med forskjellige rettelser, og navnene ligner nok til at folk bytter dem og deretter jager feil logg. Legg merke til hvilken forespørsel som dukket opp før du endrer noen innstilling, fordi ordlyden i forespørselen er den billigste diagnosen du har.

Når nøkkelpassordet faktisk trengs

Alternativet er bare meningsfullt når det finnes en kryptert nøkkel å låse opp. Hvis du kobler til med brukernavn og passord og uten klientsertifikat, har --key-password ingenting å virke på, og å ta det med endrer ingenting. Hvis du kobler til med --certificate og --sslkey, avgjør nøkkelfilens eget format om det i det hele tatt blir spurt om en passfrase.

Begge hemmelighetene i én kommando er vanlig i administrerte miljøer: et enhetssertifikat i en kryptert nøkkel, pluss en innlogging per bruker. Riktig rekkefølge er å la klienten spørre om nøkkelpassfrasen lokalt, fullføre sertifikathåndtrykket og deretter håndtere gatewayens kontoforespørsel separat. Forsøket på å forhåndsfylle begge gjennom ett gjenbrukt skript er der forvirringen vanligvis starter.

En nyttig diagnose er å se når feilen skjer. Hvis klienten stopper før noen nettverksautentisering begynner, mistenk nøkkelfilen, formatet eller passfrasen. Hvis TLS-økten er etablert og gatewayen deretter avviser brukeren, gjorde nøkkelen jobben sin, og problemet er kontoutvekslingen.

Hold begge hemmelighetene unna skallhistorikken

Kommandolinjeargumenter er lesbare for andre lokale brukere gjennom procestabellen og blir ofte fanget i skallhistorikk, skript og støttetranskripsjoner. OpenConnect kan lese kontopassordet fra standardinndata med --passwd-on-stdin, og nøkkelpassfrasen kan komme fra en interaktiv forespørsel eller en agent i stedet for et argument. Ingen av mekanismene gjør hemmeligheten trygg i seg selv, men begge holder den unna de mest utsatte stedene.

Filer fortjener samme omhu. Et skript som skriver en passfrase til en midlertidig fil, bør opprette den med strenge tillatelser, slette den ved avslutning og unngå kataloger som alle kan lese. En passfrase som overlever økten i en midlertidig katalog, er en kopi du glemte å lage. Miljøvariabler er synlige for barneprosesser og blir ofte gjengitt av feilsøkingsverktøy, så de er ikke en gratis oppgradering fremfor argumenter.

Diagnostisk utdata er den stille lekkasjen. Klientlogger med høyere detaljgrad kan vise forespørselstekster eller alternativverdier, og en kopiert terminaltranskripsjon er lett å lime inn i en sak, så les utdataene før du deler dem.

En død skrivebordsknapp er en annen feil

Et VPN-element på skrivebordet som viser en spinner og deretter ingenting, er vanligvis ikke et autentiseringsproblem i det hele tatt. Knappen tilhører en nettverksbehandler, et leverandørapplet eller en plugin som starter OpenConnect på dine vegne, og en manglende komponent eller uleselig profil kan gi nøyaktig det symptomet. Finn ut hvilken prosess knappen starter, og les feilen før du rører ved påloggingsinformasjon.

Det er fristende å lempe på sertifikatverifiseringen eller slå av en sjekk når GUI-et nekter å koble til. Det gjør en klientintegrasjonsfeil om til en sikkerhetsnedgradering og løser sjelden oppstartsproblemet. Hold serververifiseringen intakt, bekreft at profilen peker på den tiltenkte gatewayen, og sjekk at hjelperen GUI-et forventer faktisk er installert.

En kort sjekkliste skiller tilfellene. En lokal feil før noen pakke forlater maskinen, peker på nøkkelen eller klientinstallasjonen. En avvisning fra gatewayen etter TLS-økten peker på kontoutvekslingen. En knapp som aldri starter klienten, peker på skrivebordsintegrasjonen. Tre forskjellige feil, hvorav én er et passord du var i ferd med å lime inn i feil felt.