Az OpenConnect --key-password beállítása a VPN-fiókod jelszava?

Olvasd el a beállítás nevét szó szerint. Egy kulcsot nevez meg, és a zavar akkor kezdődik, amikor a megnyitandó fájlt összetévesztik a hitelesítendő fiókkal. Illeszd be a fiók jelszavát abba a beállításba, és a kliens ezzel próbál meg megnyitni egy kulcsfájlt, ami olyan okokból hiúsul meg, amelyeknek semmi közük a VPN-bejelentkezéshez.

A zavaró rész az, hogy egyetlen kapcsolat jogosan igényelheti mindkét titkot. Az ügyféltanúsítványos hitelesítés titkosított kulcsot igényelhet, és ugyanaz az átjáró a tanúsítvány elfogadása után még lefolytathat felhasználói hitelesítési cserét. Egyik titok sem elégíti ki a másik szakaszt, és az egyik hibája kívülről nagyon hasonlít a másik hibájára.

Két titok, két különböző feladat

Olvasd a szerepeket fájlhozzáférésként szemben a hálózati beengedéssel. A kulcs jelszava visszafejti a --sslkey beállításban megnevezett PEM privát kulcsot, hogy bemutatható legyen a TLS-ügyféltanúsítvány. Ez a visszafejtés helyben, a kliens folyamatán belül történik, és maga a jelmondat soha nem utazik az átjáróhoz. Az átjáró a tanúsítványt és a kulccsal készült aláírást látja. Az OpenConnect kézikönyve a --key-password beállítást a --certificate és --sslkey mellett tartja, és a TPM-ben tárolt kulcsot használni tudó buildeken ugyanez a beállítás helyette a tárolási gyökérkulcs jelszavát hordozza.

A fiók jelszava másféle. A hitelesítési cserébe kerül: felhasználónév és jelszó űrlapja, token, SAML-kör vagy valamilyen kombináció, amelyet az átjáró hirdet. Egyes telepítések egyáltalán nem kérik, ha a tanúsítvány az egyetlen tényező, mások pedig tanúsítvány után is kérik, mert a tanúsítvány az eszközt bizonyítja, míg a fiók a személyt.

A kettő keverése félrevezető hibákat okoz. A bejelentkezést elutasító átjáró általában hitelesítési hibát jelent, míg a rossz kulcsjelmondat általában korábban hiúsul meg, amikor a TLS-réteg nem tudja olvasni a kulcsfájlt. Ezek különböző szakaszok különböző javításokkal, és a nevek elég hasonlóak ahhoz, hogy az emberek felcseréljék őket, majd a rossz napló után fussanak. Jegyezd meg, melyik kérés jelent meg, mielőtt bármilyen beállítást módosítasz, mert a kérés szövege a legolcsóbb diagnózis, amivel rendelkezel.

Mikor van valóban szükség a kulcs jelszavára

A beállításnak csak akkor van értelme, ha van megnyitandó titkosított kulcs. Ha felhasználónévvel és jelszóval kapcsolódsz, ügyféltanúsítvány nélkül, a --key-password beállításnak nincs min hatnia, és hozzáadása semmit nem változtat. Ha --certificate és --sslkey beállítással kapcsolódsz, a kulcsfájl saját formátuma dönti el, hogy egyáltalán kérnek-e jelmondatot.

Mindkét titok egy parancsban gyakori a kezelt környezetekben: eszköztanúsítvány titkosított kulcsban, plusz felhasználónkénti bejelentkezés. A helyes sorrend az, hogy a kliens helyben kérje a kulcs jelmondatát, befejeződjön a tanúsítvány kézfogása, majd az átjáró fiókkérését külön kezeljük. Az a kísérlet, hogy mindkettőt előre kitöltsük egy újrahasznált szkripttel, az a pont, ahol a zavar általában elkezdődik.

Hasznos diagnózis megnézni, mikor történik a hiba. Ha a kliens leáll, mielőtt bármilyen hálózati hitelesítés elkezdődne, gyanakodj a kulcsfájlra, annak formátumára vagy a jelmondatra. Ha a TLS-munkamenet létrejön, és utána az átjáró elutasítja a felhasználót, a kulcs megtette a dolgát, és a probléma a fiók cseréjében van.

Tartsd mindkét titkot a shell-előzményeken kívül

A parancssori argumentumokat más helyi felhasználók is olvashatják a folyamattáblán keresztül, és gyakran rögzülnek a shell-előzményekben, szkriptekben és támogatási átiratokban. Az OpenConnect a fiók jelszavát a szabványos bemenetről is olvashatja a --passwd-on-stdin beállítással, a kulcs jelmondata pedig érkezhet interaktív kérésből vagy ügynökből argumentum helyett. Egyik mechanizmus sem teszi önmagában biztonságossá a titkot, de mindkettő távol tartja a leginkább kitett helyektől.

A fájlok ugyanazt a gondosságot érdemlik. Egy szkript, amely jelmondatot ír egy ideiglenes fájlba, hozza létre szigorú jogosultságokkal, törölje kilépéskor, és kerülje a mindenki által olvasható könyvtárakat. Egy jelmondat, amely túléli a munkamenetet egy ideiglenes könyvtárban, egy másolat, amelyet elfelejtettél elkészíteni. A környezeti változók láthatók a gyermekfolyamatok számára, és gyakran megjelennek a hibakereső eszközök kimenetében, ezért nem ingyenes előrelépés az argumentumokhoz képest.

A diagnosztikai kimenet a csendes szivárgás. A kliens naplói nagyobb részletességnél mutathatnak kérési törzseket vagy beállítási értékeket, és egy másolt terminálátirat könnyen beilleszthető egy jegybe, ezért olvasd el a kimenetet, mielőtt megosztod.

Egy halott asztali gomb másik hiba

Egy asztali VPN-bejegyzés, amely pörgő ikont mutat, majd semmit, általában egyáltalán nem hitelesítési probléma. A gomb egy hálózatkezelőhöz, egy gyártói kisalkalmazáshoz vagy egy bővítményhez tartozik, amely a nevedben indítja az OpenConnectet, és egy hiányzó összetevő vagy olvashatatlan profil pontosan ezt a tünetet okozhatja. Keresd meg, melyik folyamatot indítja a gomb, és olvasd el a hibáját, mielőtt a hitelesítő adatokhoz nyúlsz.

Csábító a tanúsítvány-ellenőrzés lazítása vagy egy ellenőrzés kikapcsolása, amikor a grafikus felület nem hajlandó csatlakozni. Ez a kliensintegráció hibáját biztonsági visszalépéssé alakítja, és ritkán javítja az indítási problémát. Tartsd érintetlenül a szerverellenőrzést, igazold, hogy a profil a szándékolt átjáróra mutat, és ellenőrizd, hogy a felület által várt segédprogram valóban telepítve van-e.

Egy rövid ellenőrzőlista szétválasztja az eseteket. Egy helyi hiba, mielőtt bármely csomag elindul, a kulcsra vagy a kliens telepítésére utal. Az átjáró elutasítása a TLS-munkamenet után a fiók cseréjére utal. Egy gomb, amely soha nem indítja el a klienst, az asztali integrációra utal. Három különböző hiba, amelyek egyike egy jelszó, amelyet épp a rossz mezőbe készültél beilleszteni.