Služba OpenVPN sa zasekne pri výzve na heslo súkromného kľúča: ako to opraviť

OpenVPN sa pýta na heslo súkromného kľúča na lokálnom stroji, takže funkčný prihlasovací súbor naň nikdy neodpovie. V službe nie je terminál na zadávanie a štart buď visí, alebo zlyhá so záznamom v journale, ktorý pomenuje vstup, nie príčinu. Ide o dve tajomstvá a každé potrebuje vlastný čitateľný zdroj pred reštartom unitu. Postup nižšie ich oddeľuje a potom overí identitu, ktorá každý súbor skutočne otvára.

Rozlíšte obe výzvy

Heslo kľúča dešifruje lokálny súkromný kľúč; prihlasovacie údaje účtu overujú reláciu voči serveru. Prichádzajú z rôznych miest, zlyhávajú v rôznych okamihoch a dávajú rôzne správy. Ich zámena posiela ľudí hľadať reset hesla, hoci účet vôbec nefiguroval. Prečítajte si text výzvy, kým zmeníte akúkoľvek voľbu, pretože formulácia je jediná spoľahlivá stopa, ktoré tajomstvo chýba.

V Community OpenVPN 2.x určuje askpass súbor, ktorý drží heslo kľúča na prvom riadku, a auth-user-pass súbor s používateľským menom na jednom riadku a heslom na ďalšom. Ani jeden súbor nemôže uspokojiť druhú voľbu. Desktopová aplikácia alebo profil NetworkManageru môžu oboje držať vo vlastnom úložišti tajomstiev, ktoré klient z príkazového riadka nikdy nečíta, tak si poznačte, ktorého klienta konfigurujete, kým napíšete akúkoľvek cestu.

Nasmerujte obe voľby na čitateľné súbory

Profil, ktorý potrebuje oba vstupy, skončí s tromi odkazmi na súbory: šifrovaný kľúč, heslo, ktoré ho odomyká, a prihlasovacia dvojica. Pridajte ich bez toho, aby ste siahli na CA alebo kontroly identity, pretože tie rozhodujú, kto je server, a nie sú súčasťou tohto problému. Ak nasadenie vôbec nepoužíva prihlasovacie údaje účtu, auth-user-pass vytvorí vstup, ktorý nikto nemôže dodať.

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

Voľby bez argumentu sa správajú inak ako voľby s cestou a v službe na tom záleží. askpass bez argumentu stále číta konzolu a súbor auth-user-pass len s používateľským menom stále necháva výzvu na heslo čakať. Keď klient prejde do démona, nemôže už vôbec žiadať terminál o vstup, takže služba takto nastavená nenabehne.

Absolútne cesty odstraňujú otázku pracovného adresára, ale neprideľujú prístup. Nasleduje vlastníctvo, režim a priechod, a všetky tri sa kontrolujú voči účtu, pod ktorým proces beží.

Prečítajte konfiguráciu unitu skôr než profil

Ktorú konfiguráciu instancia načíta, rozhoduje unit, nie súbor, ktorý ste upravovali. Prečítajte jeho príkazový riadok a všetky drop-in súbory, potom sledujte pracovný adresár k profilu, ktorý sa skutočne používa. Odkaz na heslo pridaný do iného súboru .ovpn pre túto instanciu nič nemení.

Tri príkazy len na čítanie odpovedajú na väčšinu. Prvý vypíše unit a všetky drop-in súbory, druhý identitu a nastavenia sandboxu, ktoré proces obmedzujú, a tretí to, na čo si posledný štart skutočne sťažoval. Použite názov instancie, ktorý na hostiteľovi existuje:

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

Všímajte si ProtectHome a vlastné voľby profilu user, group a chroot. Súbor v domovskom adresári môže byť v shelli čitateľný a vo vnútri služby neviditeľný, keď sa domovské adresáre skryjú. Účet, s ktorým systemd štartuje, nie je vždy ten, ktorý kľúč nakoniec otvorí.

Dokážte, že behová identita dokáže otvoriť oba súbory

Čítanie režimu nestačí, pretože každý adresár na ceste musí byť pre tú istú identitu prechodný. Prejdite cestu komponent po komponente a potom vyskúšajte otvorenie ako účet, ktorý proces používa. Súbor s režimom 600 vo vlastníctve root funguje len dovtedy, kým je proces root, čo po znížení oprávnení, ktoré robí veľa profilov, už neplatí. Dva príkazy pokrývajú priechod aj otvorenie:

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

Prvý príkaz vypíše režim každého komponentu a zlyhá tam, kde účet nemôže prejsť; druhý odpovedá na jedinú dôležitú otázku, či behová identita dokáže súbor otvoriť na čítanie. Ani jeden nevypisuje obsah súboru, a to je práve podstatné, keď súbor drží heslo. Test zopakujte pre prihlasovací súbor, pretože oba sa často ukladajú s iným vlastníkom.

Ak proces používa chroot alebo obmedzený namespace, spustite ten istý test zvnútra tohto pohľadu, inak odpoveď opisuje nesprávny súborový systém. Heslo uložené v skrytom domovskom adresári je obvyklý príklad testu, ktorý prejde mimo unitu a zlyhá v ňom.

Skontrolujte prvý štart, potom opätovné pripojenie

Spustite instanciu raz a čítajte prvé zlyhanie, nie posledné. Chýbajúci vstupný súbor, neúspešné dešifrovanie kľúča a AUTH_FAILED zo strany servera sú tri rôzne udalosti s tromi rôznymi opravami. Oprava varovania o oprávneniach nič nedokazuje o tom, či bol kľúč odomknutý.

Riadok v journale hovorí, ktorý z troch prípadov máte. Oprava vyplýva z toho, ktorý vstup zlyhal:

Potom otestujte životný cyklus, ktorý skutočne potrebujete: štart pri boote a akékoľvek podporované opätovné pripojenie, nie len ručný štart zo shellu. S auth-nocache sa vstupy po prvom použití zahodia, takže neskoršie opätovné pripojenie stále potrebuje čitateľný zdroj. Kľúčenka odomknutá pri prihlásení do desktopu nie je dostupná službe, ktorá štartovala skôr, než sa niekto prihlásil, a to je obvyklý dôvod, prečo ručný test prejde a reštart zlyhá. Ak prvý štart uspeje a neskoršie opätovné pripojenie zlyhá, prečítajte si journal kvôli udalosti opätovného pripojenia, kým znova zmeníte oprávnenia.

Ukladanie hesla vedľa kľúča znižuje, čo vám šifrovanie dáva, takže ten súbor a jeho zálohy obmedzte. Odstránenie hesla kľúča berte ako samostatné rozhodnutie o prihlasovacích údajoch, nie ako opravu chýbajúceho vstupu. Nasadenie, ktoré závisí od ľudského schválenia alebo interaktívnej MFA, potrebuje podporovaného agenta alebo integráciu správy; trvalo uložený jednorazový kód nie je rovnocenná náhrada.