Je --key-password v OpenConnectu heslo vašeho VPN účtu?

Přečtěte název volby doslova. Pojmenovává klíč a zmatení začíná, když se soubor, který se odemyká, zamění za účet, který se ověřuje. Vložte heslo účtu do této volby a klient se jím pokusí otevřít soubor s klíčem, což selže z důvodů, které s přihlášením k VPN nemají nic společného.

Zmatek je v tom, že jedno připojení může legitimně potřebovat obě tajemství. Ověřování klientským certifikátem může vyžadovat šifrovaný klíč a stejná brána může po přijetí certifikátu stále provést výměnu ověření uživatele. Ani jedno tajemství nesplňuje druhou fázi a selhání v jednom zvenčí vypadá velmi podobně jako selhání v druhém.

Dvě tajemství, dva různé úkoly

Čtěte role jako přístup k souboru proti povolení do sítě. Heslo klíče dešifruje soukromý klíč PEM uvedený v --sslkey, aby mohl být předložen klientský certifikát TLS. Toto dešifrování probíhá lokálně, uvnitř procesu klienta, a samotná přístupová fráze nikdy necestuje k bráně. Brána vidí certifikát a podpis vytvořený klíčem. Příručka OpenConnectu drží --key-password vedle --certificate a --sslkey, a v sestaveních, která mohou použít klíč v TPM, nese stejná volba místo toho heslo kořenového klíče úložiště.

Heslo účtu je jiného druhu. Vstupuje do výměny ověření: formulář s uživatelským jménem a heslem, token, kolo SAML nebo nějaká kombinace, kterou brána inzeruje. Některá nasazení ho vůbec nevyžadují, když je certifikát jediným faktorem, a některá ho žádají i po certifikátu, protože certifikát prokazuje zařízení, zatímco účet prokazuje osobu.

Míchání obojího vytváří zavádějící chyby. Brána odmítající přihlášení obvykle hlásí selhání ověření, zatímco špatná přístupová fráze klíče obvykle selže dříve, když vrstva TLS nemůže přečíst soubor s klíčem. To jsou různé fáze s různými opravami a názvy jsou dost podobné, aby si je lidé vyměnili a pak honili špatný záznam. Všimněte si, která výzva se objevila, než změníte jakékoli nastavení, protože znění výzvy je nejlevnější diagnostika, kterou máte.

Kdy je heslo klíče skutečně potřeba

Volba má smysl jen tehdy, když existuje šifrovaný klíč k odemčení. Pokud se připojujete uživatelským jménem a heslem a bez klientského certifikátu, --key-password nemá na co působit a jeho zařazení nic nemění. Pokud se připojujete s --certificate a --sslkey, rozhoduje vlastní formát souboru s klíčem, zda bude přístupová fráze vůbec vyžádána.

Obě tajemství v jednom příkazu jsou v řízených prostředích běžná: certifikát zařízení v šifrovaném klíči plus přihlášení pro každého uživatele. Správný postup je nechat klienta lokálně vyžádat přístupovou frázi klíče, dokončit certifikátový handshake a poté samostatně vyřídit výzvu brány k účtu. Pokus předvyplnit obojí jedním znovupoužitým skriptem je místo, kde zmatek obvykle začíná.

Užitečná diagnostika je podívat se, kdy k selhání dojde. Pokud se klient zastaví dřív, než začne jakékoli síťové ověřování, podezřívejte soubor s klíčem, jeho formát nebo přístupovou frázi. Pokud je relace TLS navázána a brána potom uživatele odmítne, klíč udělal svou práci a problém je ve výměně účtu.

Udržte obě tajemství mimo historii shellu

Argumenty příkazového řádku mohou jiní místní uživatelé číst přes tabulku procesů a často se zachytávají v historii shellu, skriptech a přepisech podpory. OpenConnect umí číst heslo účtu ze standardního vstupu pomocí --passwd-on-stdin a přístupová fráze klíče může přijít z interaktivní výzvy nebo agenta místo z argumentu. Ani jeden mechanismus sám o sobě tajemství nezabezpečí, ale oba ho drží mimo nejvíc vystavená místa.

Soubory si zaslouží stejnou péči. Skript, který zapisuje přístupovou frázi do dočasného souboru, by ho měl vytvořit s omezujícími oprávněními, při ukončení ho smazat a vyhýbat se adresářům čitelným pro všechny. Přístupová fráze, která přežije relaci v dočasném adresáři, je kopie, kterou jste zapomněli vytvořit. Proměnné prostředí jsou viditelné pro podřízené procesy a často je vypisují ladicí nástroje, takže nejsou bezplatným vylepšením oproti argumentům.

Diagnostický výstup je tichý únik. Klientské záznamy při vyšší podrobnosti mohou ukázat těla požadavků nebo hodnoty voleb a zkopírovaný přepis terminálu se snadno vloží do tiketu, takže si výstup přečtěte, než ho nasdílíte.

Mrtvé tlačítko na ploše je jiná závada

Záznam VPN na ploše, který ukáže točící se indikátor a pak nic, obvykle vůbec není problém ověřování. Tlačítko patří správci sítě, appletu výrobce nebo pluginu, který za vás spouští OpenConnect, a chybějící komponenta nebo nečitelný profil mohou vyvolat přesně tenhle příznak. Zjistěte, který proces tlačítko spouští, a přečtěte jeho chybu, než se dotknete přihlašovacích údajů.

Je lákavé zmírnit ověřování certifikátu nebo vypnout kontrolu, když se GUI odmítá připojit. To mění závadu integrace klienta ve snížení bezpečnosti a problém se spuštěním to málokdy vyřeší. Nechte ověřování serveru nedotčené, ověřte, že profil míří na zamýšlenou bránu, a zkontrolujte, že pomocník, kterého GUI očekává, je skutečně nainstalovaný.

Krátký kontrolní seznam odděluje případy. Místní selhání dřív, než vyjde jakýkoli paket, ukazuje na klíč nebo instalaci klienta. Odmítnutí bránou po relaci TLS ukazuje na výměnu účtu. Tlačítko, které klienta nikdy nespustí, ukazuje na integraci s plochou. Tři různé závady, z nichž jedna je heslo, které jste se právě chystali vložit do špatného pole.