Oprava: OpenVPN nemohl přečíst uživatelské jméno Auth ze standardního vstupu

could not read Auth username from stdin vypadá jako problém s ověřováním, ale není. OpenVPN se pokusil vyžádat uživatelské jméno ze standardního vstupu, nenašel nic čitelného a zastavil se, dřív než se vůbec spojil se serverem. Účet může být zcela platný; proces prostě nemá koho se zeptat.

Proto je prvním užitečným krokem ověřit, co klient čte, ne zkoušet znovu připojení nebo měnit nastavení na straně serveru. Projděte níže uvedené kontroly v pořadí a zastavte se u první, která selže.

Čtěte chybu jako místní selhání vstupu

Když se auth-user-pass objeví bez argumentu souboru, klient očekává výzvu. V interaktivním shellu tato výzva funguje, protože proces vlastní terminál. Pod systemd, úlohou cron nebo kontejnerem bývá standardní vstup prázdný a čtení se okamžitě vrátí s chybou, kterou vidíte.

Zpráva také uvádí, které pole selhalo, uživatelské jméno nebo heslo, což prozrazuje, jak daleko čtení došlo. Chybějící uživatelské jméno znamená, že proces nepřečetl vůbec nic. Chybějící heslo po úspěšném uživatelském jménu znamená, že vstupní proud skončil mezi oběma čteními, což je typické pro napůl zapsaný soubor nebo uzavřenou rouru.

Než změníte cokoli dalšího, ověřte pohled samotného klienta. Spusťte ho v popředí se stejnou konfigurací a stejným uživatelem a sledujte, zda se výzva objeví. Pokud se objeví ve vašem shellu, ale ne pod správcem služeb, rozdíl je ve zdroji vstupu, ne v přihlašovacích údajích. Rychlé srovnání unit souboru a prostředí shellu obvykle ukáže, který z nich poskytuje terminál.

Dejte službě podporovaný zdroj přihlašovacích údajů

Podporovaným zdrojem pro bezobslužný provoz je soubor s přihlašovacími údaji předaný jako argument parametru auth-user-pass. Soubor se čte jako prostý text: první řádek je uživatelské jméno, druhý je heslo. Odkažte na něj absolutní cestou, například /etc/openvpn/client/creds , aby pracovní adresář servisního účtu nemohl změnit význam direktivy.

Oprávnění jsou stejně důležitá jako cesta. Soubor musí být čitelný pro účet, který klienta spouští, a ne pro všechny ostatní, a měl by patřit servisnímu účtu nebo rootovi se skupinou, která službu zahrnuje. Ověřte čitelnost jako tento účet, aniž byste vypisovali obsah.

Relativní cesta je tichý režim selhání. Profil může ležet v jednom adresáři, zatímco systemd spouští proces jinde, takže soubor, který se vyřeší ve vašem shellu, se pro službu nevyřeší. Přesuňte přihlašovací údaje na pevné místo a odkazujte na ně absolutně. Potom službu jednou spusťte a potvrďte, že se používá stejná cesta, místo abyste věřili pohledu editoru profilů.

Pokud nasazení vyžaduje jednorázový kód nebo jinou interaktivní výzvu, rozhodněte, zda to pracovní postup klienta skutečně zvládne bez obsluhy. Soubor se statickým heslem nemůže odpovědět na rotující kód a opakování nezodpověditelné výzvy nepřináší žádnou informaci.

Proč script-security nepomůže

script-security řídí, zda klient smí spouštět skripty a kolik jim smí předat, včetně toho, zda lze heslo předat skriptu přes proměnnou prostředí. O tom, odkud se uživatelské jméno a heslo berou, neříká nic.

Zvyšovat ho na vyšší úroveň je běžný reflex, protože zpráva zmiňuje Auth, ale mění oprávnění skriptů, nikoli zdroj vstupu, a rozšiřuje, co klient smí spustit. Pokud je pomocný skript součástí návrhu, nejprve opravte zdroj vstupu a udržujte úroveň zabezpečení na nejnižší hodnotě, kterou nasazení potřebuje.

Rozhraní pro správu je legitimní alternativa. Frontend se k němu může připojit, převzít žádost o přihlašovací údaje a odpovědět uživatelským jménem a heslem, tak fungují některá GUI. Pokud je používáte, svažte je s místní adresou, chraňte je souborem hesla pro správu a omezte, kdo se může připojit, protože je to řídicí kanál klienta.

Ověřte další fázi poté, co klient soubor přečte

Jakmile klient dokáže přečíst přihlašovací údaje, další selhání je skutečná výměna se serverem a jeho zpráva má jiný význam. Selhání ověření v této fázi znamená, že server účet odmítl; odpověď s výzvou znamená, že server chce jiný faktor. Berte je jako nové problémy, ne jako opakování téhož.

Otestujte celou cestu tak, jak ji bude služba spouštět: stejný účet, stejný pracovní adresář, stejné prostředí unit. Připojení, které funguje jen při spuštění z vašeho shellu, je známkou toho, že proměnná prostředí nebo terminál jsou stále součástí toku.

Pak držte tajemství tam, kam patří. Hesla v argumentech příkazového řádku se objevují v tabulce procesů a hesla v ladicím výstupu končí v tikketech. Používejte chráněný soubor nebo rozhraní pro správu, udržujte protokoly na úrovni, která neopakuje přihlašovací údaje, a při odchodu kohokoli s přístupem soubor vyměňte.

Kontrolní seznam: absolutní cesta k přihlašovacím údajům, čitelná jako servisní účet, není nutný terminál, script-security na minimu, rozhraní pro správu jen pokud je svázané a ověřené, a výsledná odpověď serveru se bere jako samostatná událost.