Usługa OpenVPN zatrzymuje się na pytaniu o hasło klucza prywatnego: jak to naprawić

OpenVPN pyta o hasło klucza prywatnego na maszynie lokalnej, więc działający plik logowania nigdy na nie nie odpowiada. W usłudze nie ma terminala do wpisywania, a start albo się zawiesza, albo kończy niepowodzeniem z wpisem w journalu, który nazywa dane wejściowe, a nie przyczynę. W grę wchodzą dwa sekrety i każdy potrzebuje własnego czytelnego źródła przed ponownym uruchomieniem unitu. Poniższa droga je rozdziela, a następnie sprawdza tożsamość, która faktycznie otwiera każdy plik.

Rozróżnij oba pytania

Hasło klucza odszyfrowuje lokalny klucz prywatny; dane konta uwierzytelniają sesję na serwerze. Pochodzą z różnych miejsc, zawodzą w różnych momentach i dają różne komunikaty. Mylenie ich sprawia, że ludzie szukają resetu hasła, choć konto wcale nie brało udziału. Przeczytaj treść pytania, zanim zmienisz jakąkolwiek opcję, bo sformułowanie jest jedyną pewną wskazówką, którego sekretu brakuje.

W Community OpenVPN 2.x askpass wskazuje plik, który trzyma hasło klucza w pierwszym wierszu, a auth-user-pass wskazuje plik z nazwą użytkownika w jednym wierszu i hasłem w następnym. Żaden z plików nie zaspokaja drugiej opcji. Aplikacja desktopowa lub profil NetworkManagera może trzymać oba w swoim magazynie sekretów, którego klient wiersza poleceń nigdy nie czyta, więc zanotuj, który klient jest konfigurowany, zanim wpiszesz jakąkolwiek ścieżkę.

Skieruj obie opcje na czytelne pliki

Profil, który potrzebuje obu danych wejściowych, kończy z trzema odwołaniami do plików: zaszyfrowanym kluczem, hasłem, które go odblokowuje, i parą logowania. Dodaj je, nie ruszając CA ani kontroli tożsamości, bo one decydują, kim jest serwer, i nie należą do tego problemu. Jeśli wdrożenie w ogóle nie używa danych konta, dodanie auth-user-pass tworzy dane wejściowe, których nikt nie może dostarczyć.

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

Opcje bez argumentu zachowują się inaczej niż opcje ze ścieżką, a w usłudze ta różnica ma znaczenie. askpass bez argumentu nadal czyta konsolę, a plik auth-user-pass zawierający tylko nazwę użytkownika nadal zostawia oczekujące pytanie o hasło. Gdy klient przejdzie w tryb demona, nie może już w ogóle prosić terminala o dane, więc tak skonfigurowana usługa nie wstaje.

Ścieżki bezwzględne usuwają pytanie o katalog roboczy, ale nie dają dostępu. Dalej idą właściciel, uprawnienia i przechodzenie, a wszystkie trzy są sprawdzane wobec konta, pod którym działa proces.

Przeczytaj konfigurację unitu przed profilem

To unit, a nie edytowany plik, decyduje, którą konfigurację wczytuje instancja. Przeczytaj jego wiersz poleceń i wszystkie pliki drop-in, a potem podążaj katalogiem roboczym do profilu, który jest naprawdę używany. Odwołanie do hasła dodane do innego pliku .ovpn nic nie zmienia dla tej instancji.

Trzy polecenia tylko do czytania odpowiadają na większość. Pierwsze wypisuje unit i wszystkie pliki drop-in, drugie tożsamość i ustawienia sandboxa ograniczające proces, a trzecie to, na co naprawdę skarżył się ostatni start. Użyj nazwy instancji, która istnieje na hoście:

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

Zwróć uwagę na ProtectHome i na własne opcje profilu user, group i chroot. Plik w katalogu domowym może być czytelny w twojej powłoce i niewidoczny wewnątrz usługi, gdy katalogi domowe są ukryte. Konto, z którym startuje systemd, nie zawsze jest tym, które ostatecznie otwiera klucz.

Udowodnij, że tożsamość wykonawcza może otworzyć oba pliki

Odczyt uprawnień nie wystarcza, bo każdy katalog na ścieżce musi być przechodni dla tej samej tożsamości. Przejdź ścieżkę komponent po komponencie, a potem sprawdź otwarcie jako konto, którego używa proces. Plik z uprawnieniami 600 należący do roota działa tylko tak długo, jak proces jest rootem, co nie jest prawdą po obniżeniu uprawnień, które wykonuje wiele profili. Dwa polecenia obejmują przechodzenie i otwarcie:

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

Pierwsze polecenie wypisuje uprawnienia każdego komponentu i zawodzi tam, gdzie konto nie może przejść; drugie odpowiada na jedyne ważne pytanie, czy tożsamość wykonawcza może otworzyć plik do czytania. Żadne nie wypisuje zawartości pliku i właśnie o to chodzi, gdy plik zawiera hasło. Powtórz test dla pliku logowania, bo oba często są przechowywane z różnym właścicielem.

Jeśli proces używa chroota lub ograniczonego namespace, uruchom ten sam test od wewnątrz tego widoku, inaczej odpowiedź opisuje niewłaściwy system plików. Hasło przechowywane w ukrytym katalogu domowym to typowy przykład testu, który przechodzi poza unitem i zawodzi wewnątrz niego.

Sprawdź pierwszy start, potem ponowne połączenie

Uruchom instancję raz i czytaj pierwszy błąd, a nie ostatni. Brakujący plik wejściowy, nieudane odszyfrowanie klucza i AUTH_FAILED od serwera to trzy różne zdarzenia z trzema różnymi naprawami. Naprawa ostrzeżenia o uprawnieniach niczego nie dowodzi co do tego, czy klucz został odblokowany.

Wiersz w journalu mówi, który z trzech przypadków masz. Naprawa wynika z tego, które dane wejściowe zawiodły:

Potem przetestuj cykl życia, którego naprawdę potrzebujesz: start przy bootowaniu i każde obsługiwane ponowne połączenie, nie tylko ręczny start z powłoki. Z auth-nocache dane wejściowe są odrzucane po pierwszym użyciu, więc późniejsze ponowne połączenie nadal potrzebuje czytelnego źródła. Pęk kluczy odblokowywany przy logowaniu do pulpitu nie jest dostępny dla usługi, która wystartowała, zanim ktokolwiek się zalogował, i to jest zwykły powód, dla którego test ręczny przechodzi, a restart zawodzi. Jeśli pierwszy start się powiedzie, a późniejsze ponowne połączenie zawiedzie, przeczytaj journal pod kątem zdarzenia ponownego połączenia, zanim znowu zmienisz uprawnienia.

Trzymanie hasła obok klucza zmniejsza to, co daje szyfrowanie, więc ogranicz ten plik i jego kopie zapasowe. Usuwanie hasła klucza traktuj jako osobną decyzję o danych uwierzytelniających, a nie jako naprawę brakujących danych wejściowych. Wdrożenie zależne od ludzkiej zgody lub interaktywnej MFA potrzebuje wspieranego agenta lub integracji zarządzania; trwale zapisany kod jednorazowy nie jest równoważnym zamiennikiem.