Onko OpenConnectin --key-password VPN-tilisi salasana?

Lue valitsimen nimi kirjaimellisesti. Se nimeää avaimen, ja sekaannus alkaa, kun avattava tiedosto sekoitetaan todennettavaan tiliin. Liitä tilin salasana siihen valitsimeen, niin asiakasohjelma yrittää avata sillä avaintiedoston, mikä epäonnistuu syistä, joilla ei ole mitään tekemistä VPN-kirjautumisen kanssa.

Hämmentävää on, että yksi yhteys voi perustellusti tarvita molemmat salaisuudet. Asiakasvarmenteen todennus voi vaatia salatun avaimen, ja sama yhdyskäytävä voi silti suorittaa käyttäjän todennusvaihdon, kun varmenne on hyväksytty. Kumpikaan salaisuus ei täytä toista vaihetta, ja toisen epäonnistuminen näyttää ulkopuolelta hyvin paljon toisen epäonnistumiselta.

Kaksi salaisuutta, kaksi eri tehtävää

Lue roolit tiedostopääsynä vastaan verkon sisäänpääsynä. Avaimen salasana purkaa --sslkey-valitsimessa nimetyn PEM-yksityisavaimen salauksen, jotta TLS-asiakasvarmenne voidaan esittää. Purku tapahtuu paikallisesti asiakasohjelman prosessissa, eikä salalause koskaan matkusta yhdyskäytävälle. Yhdyskäytävä näkee varmenteen ja avaimella tehdyn allekirjoituksen. OpenConnectin käsikirja pitää --key-password-valitsinta --certificate- ja --sslkey-valitsinten vieressä, ja koosteissa, jotka voivat käyttää TPM:ään tallennettua avainta, sama valitsin kantaa sen sijaan tallennuksen juuriavaimen salasanan.

Tilin salasana on laadultaan toinen. Se menee todennusvaihtoon: käyttäjänimen ja salasanan lomake, token, SAML-kierros tai jokin yhdistelmä, jota yhdyskäytävä ilmoittaa. Jotkin käyttöönotot eivät kysy sitä lainkaan, kun varmenne on ainoa tekijä, ja jotkut kysyvät sitä jopa varmenteen jälkeen, koska varmenne todistaa laitteen ja tili henkilön.

Kahden sekoittaminen tuottaa harhaanjohtavia virheitä. Kirjautumisen hylkäävä yhdyskäytävä ilmoittaa yleensä todennusvirheestä, kun taas väärä avaimen salalause epäonnistuu yleensä aiemmin, kun TLS-kerros ei voi lukea avaintiedostoa. Ne ovat eri vaiheita eri korjauksin, ja nimet ovat riittävän samankaltaisia, että ihmiset vaihtavat ne ja jahtaavat sitten väärää lokia. Huomaa, mikä kehote ilmestyi ennen kuin muutat mitään asetusta, sillä kehotteen sanamuoto on halvin käytettävissä oleva diagnoosi.

Milloin avaimen salasanaa todella tarvitaan

Valitsimella on merkitystä vain, kun avattavana on salattu avain. Jos yhdistät käyttäjänimellä ja salasanalla ilman asiakasvarmennetta, --key-password-valitsimella ei ole mitään mihin vaikuttaa, eikä sen lisääminen muuta mitään. Jos yhdistät valitsimilla --certificate ja --sslkey, avaintiedoston oma muoto ratkaisee, kysytäänkö salalausetta lainkaan.

Molemmat salaisuudet yhdessä komennossa ovat tavallisia hallituissa ympäristöissä: laitevarmenne salatussa avaimessa sekä käyttäjäkohtainen kirjautuminen. Oikea järjestys on antaa asiakasohjelman kysyä avaimen salalause paikallisesti, suorittaa varmenteen kättely loppuun ja käsitellä sitten yhdyskäytävän tilikehote erikseen. Yritys täyttää molemmat etukäteen yhdellä uudelleenkäytetyllä skriptillä on se kohta, josta sekaannus yleensä alkaa.

Hyödyllinen diagnoosi on katsoa, milloin vika tapahtuu. Jos asiakasohjelma pysähtyy ennen kuin mikään verkkotodennus alkaa, epäile avaintiedostoa, sen muotoa tai salalausetta. Jos TLS-istunto muodostetaan ja yhdyskäytävä hylkää käyttäjän sen jälkeen, avain teki tehtävänsä ja ongelma on tilin vaihdossa.

Pidä molemmat salaisuudet poissa komentotulkin historiasta

Komentorivin argumentit ovat muiden paikallisten käyttäjien luettavissa prosessitaulukon kautta, ja ne jäävät usein komentotulkin historiaan, skripteihin ja tukitallenteisiin. OpenConnect voi lukea tilin salasanan standardisyötteestä --passwd-on-stdin-valitsimella, ja avaimen salalause voi tulla interaktiivisesta kehotteesta tai agentista argumentin sijaan. Kumpikaan mekanismi ei tee salaisuudesta itsessään turvallista, mutta molemmat pitävät sen poissa altistetuimmista paikoista.

Tiedostot ansaitsevat saman huolen. Skriptin, joka kirjoittaa salalauseen väliaikaistiedostoon, tulisi luoda se rajoittavin oikeuksin, poistaa se poistuessaan ja välttää hakemistoja, jotka kaikki voivat lukea. Salalause, joka jää istunnon jälkeen väliaikaishakemistoon, on kopio, jonka unohdit tehdä. Ympäristömuuttujat näkyvät aliprosesseille ja päätyvät usein virheenjäljitystyökalujen tulosteisiin, joten ne eivät ole ilmainen parannus argumentteihin verrattuna.

Diagnostinen tuloste on hiljainen vuoto. Asiakasohjelman lokit suuremmalla yksityiskohtaisuudella voivat näyttää pyyntöjen runkoja tai valitsinten arvoja, ja kopioitu päätetallenne on helppo liittää tikettiin, joten lue tuloste ennen sen jakamista.

Kuollut työpöytäpainike on eri vika

Työpöydän VPN-merkintä, joka näyttää pyörivän osoittimen ja sitten ei mitään, ei yleensä ole lainkaan todennusongelma. Painike kuuluu verkkohallinnalle, valmistajan sovelmalle tai liitännäiselle, joka käynnistää OpenConnectin puolestasi, ja puuttuva komponentti tai lukukelvoton profiili voivat tuottaa juuri tuon oireen. Selvitä, minkä prosessin painike käynnistää, ja lue sen virhe ennen kuin kosket tunnistetietoja.

On houkuttelevaa löysätä varmenteen varmennusta tai poistaa tarkistus käytöstä, kun graafinen käyttöliittymä kieltäytyy yhdistämästä. Se muuttaa asiakasohjelman integraatiovian tietoturvan heikennykseksi eikä juuri koskaan korjaa käynnistysongelmaa. Pidä palvelimen varmennus koskemattomana, varmista että profiili osoittaa aiottuun yhdyskäytävään ja tarkista, että käyttöliittymän odottama apuohjelma on todella asennettu.

Lyhyt tarkistuslista erottaa tapaukset. Paikallinen vika ennen kuin yksikään paketti lähtee viittaa avaimeen tai asiakasohjelman asennukseen. Yhdyskäytävän hylkäys TLS-istunnon jälkeen viittaa tilin vaihtoon. Painike, joka ei koskaan käynnistä asiakasohjelmaa, viittaa työpöytäintegraatioon. Kolme eri vikaa, joista yksi on salasana, jonka aioit juuri liittää väärään kenttään.