Az OpenVPN a terminálról olvassa a jelszót, nem a stdinről

OpenVPN felhasználónevet és jelszót kér a vezérlő terminálon, és a szabványos bemenetre átirányított fájl nem ez a terminál. Ez az egyetlen részlet magyarázza azt a szkriptet, amely úgy akad el, hogy a jelszó ott van a csőben. A kérést az ügyfél rajzolja, és az olvasás a termináleszközről történik, ezért a stdin átirányítása semmit nem változtat. Táplálja az ügyfelet valamelyik dokumentált bemenetén keresztül, és ugyanaz a szkript első próbálkozásra csatlakozik.

Három mód szinte minden esetet lefed, és mindegyik a maga módján bukik el. A kérés alapján válasszon, amelyet az ügyfél ténylegesen mutat, ne a legkönnyebben szkriptelhető opció alapján.

A kérés nem a stdinről jön

Amikor az OpenVPN-nak hitelesítő adatok kellenek, megnyitja a vezérlő terminált, és onnan olvas. Ezért néz ki jól az interaktív teszt, miközben ugyanaz a parancs cron vagy unit fájl alatt tétlenül áll, a kérés pedig olyan naplóba íródik, amelyet senki nem néz. Egyes buildek visszaesnek a szabványos bemenetre, ha nincs terminál, és ez az ellentmondás rosszabb a kemény hibánál, mert a telepítésig rejti a problémát.

Még bármilyen kód írása előtt vizsgálja meg a környezetet: futtassa az ügyfelet ugyanazon felhasználó alatt, ugyanazzal a stdin-nel, ahogy az ütemező vagy a szolgáltatáskezelő tenné. Ha a kérés soha nem jelenik meg a naplóban, és a folyamat nem halad, valami egy nem létező terminálra vár.

Első mód: kétsoros hitelesítő fájl

A hitelesítési opció egy útvonalat kap, a fájl pedig pontosan két sort tartalmaz, előbb a felhasználónevet, majd a jelszót, semmi mást. Adja meg az útvonalat kifejezetten, ahelyett hogy alapértelmezett fájlnévre hagyatkozna, mert a munkakönyvtárban kallódó hitelesítő fájl az, ahogy a rossz fiók használatba kerül. Állítsa a módot 0600-ra, és adja a tulajdonjogot az ügyfelet futtató fióknak.

Az ügyfél a fájlt induláskor egyszer olvassa be, így a jelszó cseréje a folyamat újraindítását jelenti. Általában ez a kívánt viselkedés, és a runbookba tartozik a cserélési eljárás mellé.

Második mód: askpass a kulcs jelmondatához

Egy jelmondattal védett titkos kulcs egy második, eltérő kérést vált ki, és annak saját fájlalapú válasza van: az askpass opció a jelmondatot egy fájl első sorából olvassa. Az SSH-alapú alagutaknál a megfelelő egy askpass program, amelyet az ügyfél futtat, és amelynek szabványos kimenete lesz a titok.

Egyik forma sem teszi a titkot az argumentumlistába, és mindkettő hagyja létezni fájlként vagy azt kiíró futtatható programként. A védelem a fájljogosultság és a folyamat tulajdonjoga, nem a homály. Az a segéd, amely egy kódba írt karakterláncot visszhangoz, extra lépésekkel védett titok.

Harmadik mód: a portálügyfél saját CLI-je

A vállalati ügyfelek általában adnak egy parancssori belépési pontot, amely ablak nélkül csatlakozik egy megnevezett portálhoz, és ez a támogatott út. Linuxon a GlobalProtect ügyfél a CLI-jén keresztül kínál csatlakozási és tanúsítványimportálási műveleteket, és a tanúsítvány-hitelesítést használó portáloknak szükségük van az importálási lépésre, mielőtt egy automatizált csatlakozás működhet. Részesítse előnyben a szintetizált billentyűleütésekkel szemben: valódi kilépési állapotot kap, nincs függés az ablakfókusztól, és túléli a zárolt képernyőt.

Ha az első csatlakozáshoz még ember kell a tanúsítvány elfogadásához, az automatizálás nincs kész. Az importálást a telepítés során végezze el, és rögzítse előfeltételként.

Amikor a folyamathoz pszeudoterminál kell

Annak a sorozatnak, amely jelszót, majd egyszer használatos kódot kér, nincs egyetlen olvasható fájlja. Az Expecthez hasonló terminálmeghajtó a megfelelő eszköz, mert sorban vár minden mintára, és szüksége van az elindított folyamatra, mielőtt egyáltalán bármit egyeztethetne.

Két hiba uralkodik. Az a szkript, amely az ügyfél elindítása nélkül vár egy kérésre, örökké vár, és a Tcl nem shell, ezért az expect blokkon belül írt shell-aritmetika nem úgy értékelődik ki, ahogy olvasódik. Tartsa bekapcsolva a hibakeresési kapcsolót, miközben a mintákat építi, aztán kapcsolja ki.

Kiszivárgó titkok, és ahol elrejtőznek

Minden, ami argumentumként átadódik, látszik a folyamatlistában, ezért a hitelesítő adatok fájlba vagy egy segéd mögé valók, soha nem a parancssorba. Az egyszer használatos kódok tervezés szerint elhasználódnak, és minden kísérlethez elő kell állítani őket. A hibanaplók gyakran hordozzák a felhasználónevet, és néha többet is, ezért szerkessze ki őket, mielőtt bárhová küldené, és tartsa a titkot magán a profilon kívül, mert a beágyazott jelszót tartalmazó konfigurációs fájl bekerül a ticketekbe és tárolókba. A fiók cseréje akkor minden másolat vadászatát jelenti, és pontosan ez az a költség, amelyet ez az elrendezés elkerül.

Auditálja a választott módokat, majd kösse be őket abba az unit fájlba vagy ütemezőbe, amely valóban futtatni fogja az ügyfelet. Az alagút pontosan addig él, ameddig az a folyamat.