Služba OpenVPN se zasekne u výzvy k heslu soukromého klíče: jak to opravit

OpenVPN se ptá na heslo soukromého klíče na místním stroji, takže funkční přihlašovací soubor na něj nikdy neodpoví. Ve službě není terminál pro zadávání a start buď visí, nebo selže se záznamem v journalu, který pojmenuje vstup, ne příčinu. Jsou tu dvě tajemství a každé potřebuje vlastní čitelný zdroj, než se unit restartuje. Postup níže je odděluje a pak ověří identitu, která každý soubor skutečně otevírá.

Rozlište obě výzvy

Heslo klíče dešifruje místní soukromý klíč; přihlašovací údaje účtu ověřují relaci vůči serveru. Přicházejí z různých míst, selhávají v jiných okamžicích a dávají jiné zprávy. Jejich záměna posílá lidi hledat reset hesla, i když účet vůbec nefiguroval. Přečtěte si text výzvy, než změníte kteroukoli volbu, protože formulace je jediná spolehlivá stopa, které tajemství chybí.

V Community OpenVPN 2.x určuje askpass soubor, který drží heslo klíče na prvním řádku, a auth-user-pass soubor s uživatelským jménem na jednom řádku a heslem na dalším. Ani jeden soubor nemůže uspokojit druhou volbu. Desktopová aplikace nebo profil NetworkManageru mohou obojí držet ve vlastním úložišti tajemství, které klient z příkazové řádky nikdy nečte, tak si poznamenejte, který klient se konfiguruje, než napíšete jakoukoli cestu.

Namiřte obě volby na čitelné soubory

Profil, který potřebuje oba vstupy, skončí se třemi odkazy na soubory: šifrovaný klíč, heslo, které ho odemyká, a přihlašovací dvojice. Přidejte je, aniž byste sáhli na CA nebo kontroly identity, protože ty rozhodují, kdo je server, a nejsou součástí tohoto problému. Pokud nasazení přihlašovací údaje účtu vůbec nepoužívá, auth-user-pass vytvoří vstup, který nikdo nemůže dodat.

key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth

Volby bez argumentu se chovají jinak než volby s cestou a na službě na tom záleží. askpass bez argumentu stále čte konzolu a soubor auth-user-pass jen s uživatelským jménem stále nechává výzvu k heslu čekat. Jakmile klient přejde do démona, nemůže už vůbec žádat terminál o vstup, takže služba takto nastavená nenaběhne.

Absolutní cesty odstraňují otázku pracovního adresáře, ale nepřidělují přístup. Následuje vlastnictví, režim a průchod, a všechny tři se kontrolují proti účtu, pod kterým proces běží.

Přečtěte konfiguraci unitu dřív než profil

Kterou konfiguraci instance načte, rozhoduje unit, ne soubor, který jste editovali. Přečtěte jeho příkazový řádek a všechny drop-in soubory, pak sledujte pracovní adresář k profilu, který se skutečně používá. Odkaz na heslo přidaný do jiného souboru .ovpn pro tuto instanci nic nemění.

Tři příkazy jen pro čtení odpoví na většinu. První vypíše unit a všechny drop-in soubory, druhý vypíše identitu a nastavení sandboxu, která proces omezují, a třetí vypíše, na co si poslední start skutečně stěžoval. Použijte název instance, který na hostiteli existuje:

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -b

Všímejte si ProtectHome a vlastních voleb profilu user, group a chroot. Soubor v domovském adresáři může být ve vašem shellu čitelný a uvnitř služby neviditelný, jakmile se domovské adresáře skryjí. Účet, se kterým systemd startuje, není vždy ten, který klíč nakonec otevře.

Dokažte, že běhová identita umí otevřít oba soubory

Čtení režimu nestačí, protože každý adresář na cestě musí být pro stejnou identitu průchodný. Projděte cestu komponentu po komponentě a pak vyzkoušejte otevření jako účet, který proces používá. Soubor s režimem 600 vlastněný rootem funguje jen dokud je proces root, což po snížení oprávnění, které mnoho profilů dělá, neplatí. Dva příkazy pokrývají průchod i otevření:

namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable

První příkaz vypíše režim každé komponenty a selže tam, kde účet nemůže projít; druhý odpovídá na jedinou důležitou otázku, zda běhová identita může soubor otevřít pro čtení. Ani jeden nevypisuje obsah souboru, a to je právě pointa, když soubor drží heslo. Test zopakujte pro přihlašovací soubor, protože oba se často ukládají s jiným vlastníkem.

Pokud proces používá chroot nebo omezený namespace, spusťte stejný test zevnitř tohoto pohledu, jinak odpověď popisuje špatný souborový systém. Heslo uložené ve skrytém domovském adresáři je obvyklý příklad testu, který projde mimo unit a selže uvnitř něj.

Zkontrolujte první start, pak opětovné připojení

Spusťte instanci jednou a čtěte první selhání, ne poslední. Chybějící vstupní soubor, neúspěšné dešifrování klíče a AUTH_FAILED ze strany serveru jsou tři různé události se třemi různými opravami. Oprava varování o oprávněních nic nedokazuje o tom, zda byl klíč odemčen.

Řádek v journalu říká, který ze tří případů máte. Oprava vyplývá z toho, který vstup selhal:

Pak otestujte životní cyklus, který skutečně potřebujete: start při bootu a jakékoli podporované opětovné připojení, ne jen ruční start ze shellu. S auth-nocache se vstupy po prvním použití zahodí, takže pozdější opětovné připojení stále potřebuje čitelný zdroj. Klíčenka odemčená při přihlášení k desktopu není dostupná službě, která nastartovala dřív, než se někdo přihlásil, a to je obvyklý důvod, proč ruční test projde a restart selže. Pokud první start uspěje a pozdější opětovné připojení selže, přečtěte si journal kvůli události opětovného připojení, než znovu změníte oprávnění.

Ukládat heslo vedle klíče snižuje, co vám šifrování dává, takže ten soubor a jeho zálohy omezte. Odebrání hesla klíče berte jako samostatné rozhodnutí o přihlašovacích údajích, ne jako opravu chybějícího vstupu. Nasazení, které závisí na lidském schválení nebo interaktivní MFA, potřebuje podporovaného agenta nebo integraci správy; trvale uložený jednorázový kód není rovnocenná náhrada.