Är OpenConnects --key-password ditt VPN-kontolösenord?

Läs alternativets namn bokstavligt. Det namnger en nyckel, och förvirringen börjar när filen som låses upp förväxlas med kontot som autentiseras. Klistra in kontolösenordet i det alternativet och klienten försöker öppna en nyckelfil med det, vilket misslyckas av skäl som inte har något med VPN-inloggningen att göra.

Det förvirrande är att en enda anslutning legitimt kan behöva båda hemligheterna. Klientcertifikatautentisering kan kräva en krypterad nyckel, och samma gateway kan fortfarande genomföra ett användarautentiseringsutbyte efter att certifikatet accepterats. Ingen av hemligheterna uppfyller det andra steget, och ett fel i den ena ser utifrån mycket likt ett fel i den andra.

Två hemligheter, två olika uppgifter

Läs rollerna som filåtkomst kontra nätverkstillträde. Nyckellösenordet dekrypterar den privata PEM-nyckeln som anges i --sslkey så att TLS-klientcertifikatet kan presenteras. Den dekrypteringen sker lokalt, inne i klientprocessen, och själva lösenfrasen reser aldrig till gatewayen. Det gatewayen ser är certifikatet och en signatur skapad med nyckeln. OpenConnects handbok håller --key-password bredvid --certificate och --sslkey, och i byggen som kan använda en nyckel i en TPM bär samma alternativ i stället lösenordet för lagringens rotnyckel.

Kontolösenordet är av ett annat slag. Det går in i autentiseringsutbytet: ett formulär med användarnamn och lösenord, en token, en SAML-omgång eller någon kombination som gatewayen annonserar. Vissa driftsättningar frågar inte alls efter det när certifikatet är den enda faktorn, och andra frågar även efter ett certifikat, eftersom certifikatet bevisar enheten medan kontot bevisar personen.

Att blanda de två ger vilseledande fel. En gateway som avvisar en inloggning rapporterar vanligtvis ett autentiseringsfel, medan en felaktig nyckellösenfras vanligtvis misslyckas tidigare, när TLS-lagret inte kan läsa nyckelfilen. Det är olika steg med olika åtgärder, och namnen liknar varandra nog att folk byter dem och sedan jagar fel logg. Notera vilken uppmaning som dök upp innan du ändrar någon inställning, eftersom uppmaningens formulering är den billigaste diagnosen du har.

När nyckellösenordet verkligen behövs

Alternativet är bara meningsfullt när det finns en krypterad nyckel att låsa upp. Om du ansluter med användarnamn och lösenord och utan klientcertifikat har --key-password inget att verka på, och att ta med det ändrar ingenting. Om du ansluter med --certificate och --sslkey avgör nyckelfilens eget format om det överhuvudtaget frågas efter en lösenfras.

Båda hemligheterna i ett kommando är vanligt i hanterade miljöer: ett enhetscertifikat i en krypterad nyckel, plus en inloggning per användare. Rätt ordning är att låta klienten fråga efter nyckelns lösenfras lokalt, slutföra certifikathandskakningen och sedan hantera gatewayens kontouppmaning separat. Försöket att förfylla båda genom ett återanvänt skript är där förvirringen brukar börja.

En användbar diagnos är att titta på när felet inträffar. Om klienten stannar innan någon nätverksautentisering börjar, misstänk nyckelfilen, dess format eller lösenfrasen. Om TLS-sessionen upprättas och gatewayen därefter avvisar användaren har nyckeln gjort sitt, och problemet är kontoutbytet.

Håll båda hemligheterna borta från skallhistoriken

Kommandoradsargument kan läsas av andra lokala användare via processtabellen och fångas ofta i skallhistorik, skript och supporttranskript. OpenConnect kan läsa kontolösenordet från standardinmatning med --passwd-on-stdin, och nyckelns lösenfras kan komma från en interaktiv uppmaning eller en agent i stället för ett argument. Ingen mekanism gör hemligheten säker i sig, men båda håller den borta från de mest utsatta platserna.

Filer förtjänar samma omsorg. Ett skript som skriver en lösenfras till en tillfällig fil bör skapa den med restriktiva behörigheter, ta bort den vid avslut och undvika kataloger som alla kan läsa. En lösenfras som överlever sessionen i en tillfällig katalog är en kopia du glömde göra. Miljövariabler är synliga för barnprocesser och skrivs ofta ut av felsökningsverktyg, så de är ingen gratis uppgradering jämfört med argument.

Diagnostikutdata är den tysta läckan. Klientloggar med högre detaljgrad kan visa förfrågningskroppar eller alternativvärden, och ett kopierat terminaltranskript är lätt att klistra in i ett ärende, så läs utdata innan du delar den.

En död skrivbordsknapp är ett annat fel

En skrivbordspost för VPN som visar en snurra och sedan ingenting är oftast inte ett autentiseringsproblem alls. Knappen tillhör en nätverkshanterare, en leverantörsapplet eller ett plugin som startar OpenConnect åt dig, och en saknad komponent eller oläsbar profil kan ge exakt det symptomet. Ta reda på vilken process knappen startar och läs dess fel innan du rör inloggningsuppgifterna.

Det är frestande att lätta på certifikatverifieringen eller stänga av en kontroll när gränssnittet vägrar ansluta. Det förvandlar ett klientintegrationsfel till en säkerhetsnedsättning och löser sällan startproblemet. Håll serververifieringen intakt, bekräfta att profilen pekar på den avsedda gatewayen och kontrollera att hjälparen som gränssnittet förväntar sig faktiskt är installerad.

En kort checklista skiljer fallen. Ett lokalt fel innan något paket lämnar maskinen pekar på nyckeln eller klientinstallationen. Ett avvisande från gatewayen efter TLS-sessionen pekar på kontoutbytet. En knapp som aldrig startar klienten pekar på skrivbordsintegrationen. Tre olika fel, varav ett är ett lösenord du var på väg att klistra in i fel fält.