Is OpenConnect --key-password jou VPN-rekeningwagwoord?

Lees die opsienaam letterlik. Dit noem 'n sleutel, en die verwarring begin wanneer die lêer wat ontsluit word, verwar word met die rekening wat verifieer word. Plak die rekeningwagwoord in daardie opsie en die kliënt sal probeer om 'n sleutellêer daarmee oop te maak, wat misluk om redes wat niks met die VPN-aanmelding te doen het nie.

Die verwarrende deel is dat 'n enkele verbinding wettig albei geheime kan nodig hê. Kliëntsertifikaat-verifikasie kan 'n geënkripteerde sleutel vereis, en dieselfde gateway kan steeds 'n gebruikersverifikasie-uitruiling uitvoer nadat die sertifikaat aanvaar is. Nie een geheim bevredig die ander stadium nie, en 'n fout in die een lyk van buite baie soos 'n fout in die ander.

Twee geheime, twee verskillende take

Lees die rolle as lêertoegang teenoor netwerktoelating. Die sleutelwagwoord ontsluit die PEM private sleutel wat deur --sslkey genoem word, sodat die TLS-kliëntsertifikaat aangebied kan word. Daardie ontsluiting gebeur plaaslik, binne die kliëntproses, en die wagfrase self reis nooit na die gateway nie. Wat die gateway sien, is die sertifikaat en 'n handtekening wat met die sleutel gemaak is. Die OpenConnect-handleiding hou --key-password langs --certificate en --sslkey, en op boue wat 'n sleutel in 'n TPM kan gebruik, dra dieselfde opsie eerder die wagwoord van die bergingswortelsleutel.

Die rekeningwagwoord is van 'n ander soort. Dit gaan in die verifikasie-uitruiling: 'n gebruikersnaam-en-wagwoord-vorm, 'n token, 'n SAML-rondte, of een of ander kombinasie wat die gateway adverteer. Sommige ontplooiings vra glad nie daarvoor as die sertifikaat die enigste faktor is nie, en sommige vra daarvoor selfs ná 'n sertifikaat, want die sertifikaat bewys die toestel terwyl die rekening die persoon bewys.

Die meng van die twee lewer misleidende foute. 'n Gateway wat 'n aanmelding verwerp, rapporteer gewoonlik 'n verifikasiefout, terwyl 'n verkeerde sleutelwagfrase gewoonlik vroeër misluk, wanneer die TLS-laag die sleutellêer nie kan lees nie. Dit is verskillende stadiums met verskillende regstellings, en die name is soortgelyk genoeg dat mense hulle omruil en dan die verkeerde log najag. Let op watter prompt verskyn het voordat jy enige instelling verander, want die bewoording van die prompt is die goedkoopste diagnose wat jy het.

Wanneer die sleutelwagwoord werklik nodig is

Die opsie het net betekenis wanneer daar 'n geënkripteerde sleutel is om te ontsluit. As jy met 'n gebruikersnaam en wagwoord en geen kliëntsertifikaat verbind, het --key-password niks om op te werk nie, en om dit in te sluit verander niks. As jy met --certificate en --sslkey verbind, besluit die sleutellêer se eie formaat of daar hoegenaamd 'n wagfrase gevra word.

Albei geheime in een opdrag is algemeen in bestuurde omgewings: 'n toestelsertifikaat in 'n geënkripteerde sleutel, plus 'n aanmelding per gebruiker. Die regte volgorde is om die kliënt plaaslik om die sleutelwagfrase te laat vra, die sertifikaathanddruk te voltooi, en dan die gateway se rekeningprompt afsonderlik te hanteer. Om albei vooraf deur een hergebruikte script te probeer invul, is waar die verwarring gewoonlik begin.

'n Nuttige diagnose is om te kyk wanneer die fout gebeur. As die kliënt stop voordat enige netwerkverifikasie begin, verdenk die sleutellêer, sy formaat of die wagfrase. As die TLS-sessie tot stand kom en die gateway die gebruiker dan verwerp, het die sleutel sy werk gedoen en is die rekeninguitruiling die probleem.

Hou albei geheime uit die shell-geskiedenis

Opdragreël-argumente is deur ander plaaslike gebruikers deur die prosestabel leesbaar en word dikwels in shell-geskiedenis, scripte en ondersteuningsgesprekke vasgevang. OpenConnect kan die rekeningwagwoord van standaardinvoer lees met --passwd-on-stdin, en die sleutelwagfrase kan van 'n interaktiewe prompt of 'n agent kom eerder as van 'n argument. Nie een meganisme maak die geheim op sigself veilig nie, maar albei hou dit uit die mees blootgestelde plekke.

Lêers verdien dieselfde sorg. 'n Script wat 'n wagfrase na 'n tydelike lêer skryf, moet dit met beperkende regte skep, dit by afsluiting verwyder en wêreldleesbare gidse vermy. 'n Wagfrase wat die sessie in 'n tydelike gids oorleef, is 'n kopie wat jy vergeet het om te maak. Omgewingsveranderlikes is sigbaar vir kindprosesse en word dikwels deur ontfoutingsgereedskap uitgestuur, so hulle is nie 'n gratis opgradering bo argumente nie.

Diagnostiese uitset is die stille lek. Kliëntlogs met hoër breedsprakigheid kan versoekliggame of opsiewaardes wys, en 'n gekopieerde terminalgesprek is maklik om in 'n kaartjie te plak, so lees die uitset voordat jy dit deel.

'n Dooie lessenaarknoppie is 'n ander fout

'n Lessenaar-VPN-inskrywing wat 'n spinner wys en dan niks, is gewoonlik glad nie 'n verifikasieprobleem nie. Die knoppie behoort aan 'n netwerkbestuurder, 'n verskaffer-applet of 'n inprop wat OpenConnect namens jou begin, en 'n ontbrekende komponent of onleesbare profiel kan presies daardie simptoom lewer. Vind watter proses die knoppie begin en lees sy fout voordat jy aan geloofsbriewe raak.

Dit is aanloklik om sertifikaatverifikasie te verslap of 'n kontrole af te skakel wanneer die GUI weier om te verbind. Dit verander 'n kliëntintegrasiefout in 'n sekuriteitsverlaging en regstel selde die bekendstellingsprobleem. Hou bedienerverifikasie ongeskonde, bevestig dat die profiel na die bedoelde gateway wys, en kyk dat die helper wat die GUI verwag, werklik geïnstalleer is.

'n Kort kontrollys skei die gevalle. 'n Plaaslike fout voordat enige pakket vertrek, wys na die sleutel of die kliëntinstallering. 'n Gateway-verwerping ná die TLS-sessie wys na die rekeninguitruiling. 'n Knoppie wat die kliënt nooit begin nie, wys na die lessenaarintegrasie. Drie verskillende foute, waarvan een 'n wagwoord is wat jy op die punt was om in die verkeerde blokkie te plak.