Poprawka: OpenVPN nie mógł odczytać nazwy użytkownika Auth ze standardowego wejścia

could not read Auth username from stdin wygląda na problem z uwierzytelnianiem i nim nie jest. OpenVPN próbował zapytać o nazwę użytkownika na standardowym wejściu, nie znalazł nic czytelnego i zatrzymał się, zanim w ogóle skontaktował się z serwerem. Konto może być całkowicie ważne; proces po prostu nie ma kogo zapytać.

Dlatego pierwszym pożytecznym krokiem jest ustalenie, co czyta klient, a nie ponawianie połączenia ani zmienianie ustawień po stronie serwera. Przejdź poniższe kontrole po kolei i zatrzymaj się na pierwszej, która zawiedzie.

Czytaj błąd jako lokalną awarię wejścia

Gdy auth-user-pass pojawia się bez argumentu pliku, klient oczekuje zapytania. W interaktywnej powłoce to zapytanie działa, bo proces ma terminal. Pod systemd, zadaniem cron lub kontenerem standardowe wejście jest zwykle puste, a odczyt natychmiast wraca z błędem, który widzisz.

Komunikat nazywa też pole, które zawiodło, nazwę użytkownika lub hasło, co pokazuje, jak daleko doszedł odczyt. Brak nazwy użytkownika oznacza, że proces nie zdołał odczytać zupełnie niczego. Brak hasła po udanej nazwie użytkownika oznacza, że strumień wejścia zakończył się między dwoma odczytami, co jest typowe dla na wpół zapisanego pliku lub zamkniętej rury.

Potwierdź punkt widzenia samego klienta, zanim zmienisz cokolwiek innego. Uruchom go na pierwszym planie z tą samą konfiguracją i tym samym użytkownikiem i obserwuj, czy zapytanie się pojawia. Jeśli pojawia się w twojej powłoce, ale nie pod menedżerem usług, różnica tkwi w źródle wejścia, a nie w danych logowania. Szybkie porównanie pliku unit i środowiska powłoki zwykle pokazuje, które z nich dostarcza terminal.

Daj usłudze obsługiwane źródło danych logowania

Obsługiwanym źródłem pracy bez nadzoru jest plik danych logowania przekazany jako argument do auth-user-pass. Plik jest czytany jako zwykły tekst: pierwszy wiersz to nazwa użytkownika, drugi to hasło. Wskaż go ścieżką bezwzględną, na przykład /etc/openvpn/client/creds , aby katalog roboczy konta usługi nie mógł zmienić znaczenia dyrektywy.

Uprawnienia są równie ważne jak ścieżka. Plik musi być czytelny dla konta uruchamiającego klienta, a nie dla wszystkich innych, i powinien należeć do konta usługi lub do roota z grupą obejmującą usługę. Sprawdź czytelność jako to konto, bez wypisywania zawartości.

Ścieżka względna to cichy tryb awarii. Profil może leżeć w jednym katalogu, podczas gdy systemd uruchamia proces gdzie indziej, więc plik, który znajduje się w twojej powłoce, nie znajduje się dla usługi. Przenieś dane logowania w stałe miejsce i odnoś się do nich bezwzględnie. Następnie uruchom usługę raz i potwierdź, że używana jest ta sama ścieżka, zamiast ufać widokowi edytora profili.

Jeśli wdrożenie wymaga jednorazowego kodu lub innego interaktywnego wyzwania, zdecyduj, czy przepływ pracy klienta naprawdę obsługuje je bez nadzoru. Plik ze statycznym hasłem nie może odpowiedzieć na zmieniający się kod, a ponawianie zapytania bez odpowiedzi nie dodaje informacji.

Dlaczego script-security nie pomoże

script-security steruje tym, czy klient może uruchamiać skrypty i ile może im przekazać, w tym czy hasło można przekazać skryptowi przez zmienną środowiskową. Nie mówi nic o tym, skąd początkowo pochodzą nazwa użytkownika i hasło.

Podniesienie go na wyższy poziom to częsty odruch, bo komunikat wspomina Auth, ale zmienia uprawnienia skryptów, a nie źródło wejścia, i rozszerza to, co klient może wykonać. Jeśli skrypt pomocniczy jest częścią projektu, najpierw napraw źródło wejścia i utrzymuj poziom bezpieczeństwa na najniższej wartości, jakiej potrzebuje wdrożenie.

Interfejs zarządzania jest legalną alternatywą. Frontend może się z nim połączyć, odebrać żądanie danych logowania i odpowiedzieć nazwą użytkownika i hasłem, tak działają niektóre GUI. Jeśli go używasz, powiąż go z adresem lokalnym, zabezpiecz plikiem hasła zarządzania i ogranicz, kto może się połączyć, bo to kanał sterowania klientem.

Sprawdź następny etap po tym, jak klient odczyta plik

Gdy klient może odczytać dane logowania, następna awaria to prawdziwa wymiana z serwerem, a jej komunikat ma inne znaczenie. Awaria uwierzytelniania na tym etapie oznacza, że serwer odrzucił konto; odpowiedź wyzwania oznacza, że serwer chce innego czynnika. Traktuj je jako nowe problemy, a nie jako powtórzenie tego samego.

Przetestuj całą ścieżkę tak, jak uruchomi ją usługa: to samo konto, ten sam katalog roboczy, to samo środowisko unit. Połączenie, które działa tylko przy uruchomieniu z twojej powłoki, jest znakiem, że zmienna środowiskowa lub terminal nadal jest częścią przepływu.

Potem trzymaj sekrety tam, gdzie ich miejsce. Hasła w argumentach wiersza poleceń pojawiają się w tabeli procesów, a hasła w danych wyjściowych debugowania trafiają do zgłoszeń. Używaj chronionego pliku lub interfejsu zarządzania, trzymaj logi na poziomie, który nie powtarza danych logowania, i wymieniaj plik, gdy odchodzi ktokolwiek z dostępem.

Lista kontrolna: bezwzględna ścieżka danych logowania, czytelny jako konto usługi, terminal niepotrzebny, script-security pozostawiony na minimum, interfejs zarządzania tylko jeśli jest powiązany i uwierzytelniony, a wynikowa odpowiedź serwera traktowana jako osobne zdarzenie.