Błąd nieprawidłowego sekretu pochodzi z pojemnika, nie z reguły hasła
To samo hasło jest dostarczane przez pole graficzne i plik danych logowania, a zawodzi w różnych miejscach. Porównaj pojemniki, zanim uprościsz hasło, które przez cały czas było dobre.
Zobaczenie komunikatu o nieprawidłowym sekrecie zwykle prowadzi do jednego wniosku: VPN nie lubi znaków interpunkcyjnych. Ten wniosek jest zwykle błędny, ponieważ komunikat często pochodzi z lokalnej obsługi, zanim jakakolwiek brama spojrzała na konto. Dwie konstrukcje dostarczają to samo hasło, pole graficzne i plik danych logowania, i zawodzą w różnych miejscach. Porównaj pojemniki, zanim uprościsz hasło, które przez cały czas było dobre.
Błąd pojawia się przed bramą
Lokalna walidacja, zablokowany magazyn sekretów, brakujący agent i źle sformatowany plik danych logowania dają błędy, które użytkownik odbiera jako jedno odrzucenie. Żaden z nich nie dotyczy serwera uwierzytelniania. Odrzucenie przez samą bramę jest osobnym zdarzeniem i zwykle przychodzi z innym komunikatem i innym czasem. Następuje po utworzeniu tunelu i przesłaniu danych logowania.
Pierwsze pytanie nie brzmi więc, które znaki są dozwolone, ale gdzie próba się zatrzymała. Klient, który nigdy nie otworzył połączenia, nie został przez nikogo odrzucony. Zapisz zaobserwowany etap, ponieważ każdy kolejny krok zależy od tej klasyfikacji.
Rozróżnienie zmienia też to, kto to naprawia. Problem pojemnika należy do urządzenia i jego właściciela, a odrzucenie konta do osoby prowadzącej backend uwierzytelniania.
Porównaj pojemniki, a nie znaki
Pole hasła w interfejsie graficznym, wpis w pęku kluczy, dwuwierszowy plik danych logowania i sekret automatyzacji przenoszą tę samą wartość w innej kopercie. Koperta ma własne zasady i to one zwykle zawodzą. Wartość rzadko jest problemem; problemem jest transport wartości. Trzymaj te dwie idee osobno, a diagnoza będzie krótsza.
| Gdzie wartość się zatrzymuje | Co widzisz | Co sprawdzasz | Kto odpowiada za naprawę |
|---|---|---|---|
| Pole interfejsu lub profil zarządzany | Komunikat walidacji przed otwarciem jakiegokolwiek połączenia | Wybrany tryb uwierzytelniania i to, czy pole zawiera sekret, czy nazwę użytkownika | Właściciel urządzenia lub autor profilu |
| Pęk kluczy lub agent sekretów | Monit, który ciągle powraca, albo błąd agenta | Czy agent jest odblokowany i czy ma wpis dla tego profilu | Użytkownik, który jest właścicielem pęku kluczy |
| Dwuwierszowy plik danych logowania | Monit o hasło, które już podano | Liczba wierszy, kolejność wierszy i to, czy na końcu jest znak nowego wiersza | Kto wygenerował plik |
| Argument powłoki lub środowisko | Działa interaktywnie, ale zawodzi w automatyzacji | Czy powłoka rozwinęła, przycięła lub zapisała wartość w logu | Kto napisał automatyzację |
Opcje klienta Community OpenVPN 2.6 opisują ten dwuwierszowy plik dla auth-user-pass, w tym zachowanie, gdy brakuje wiersza hasła: klient pyta zamiast tego. Ten jeden szczegół wyjaśnia klasę raportów o tym, że pyta o hasło, które już podano. Mówi też, że pusty drugi wiersz jest znaczącym stanem, a nie nieszkodliwym wyborem formatowania.
Cytowanie to znowu osobna warstwa: cudzysłowy wewnątrz zwykłego pliku danych logowania są przechowywane jako dane, a powłoka usuwa je, zanim program cokolwiek zobaczy. Ten sam znak jest nieszkodliwy w jednym miejscu, a strukturalny w drugim. Tabela nie powie ci, którego pojemnika użył klient, więc przeczytaj własną konfigurację klienta, zanim wybierzesz wiersz.
Podziały wierszy też są strukturalne. Plik z polami rozdzielonymi wierszami nie może przenieść wartości zawierającej nowy wiersz, i jest to ograniczenie formatu, a nie ocena siły hasła. Użyj mechanizmu dostarczania obsługiwanego przez wdrożenie, zamiast przycinać sekret, aby pasował do doraźnego pliku.
Zbuduj plik danych logowania bez szkody ze strony powłoki
Najbezpieczniejsza lokalna droga trzyma sekret poza historią powłoki i poza listą argumentów procesu. Odczytaj oba pola interaktywnie, a następnie zapisz dwa wiersze, których oczekuje klient. Wszystko inne może zostać w pliku konfiguracyjnym, który łatwo przejrzeć.
read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/credsPierwsze dwie komendy czytają nazwę użytkownika, a potem hasło bez jego echa, trzecia zapisuje oba wiersze, czwarta ogranicza dostęp do pliku, a ostatnia uruchamia klienta z tym plikiem. Zauważ, że read -r zachowuje ukośniki wsteczne, co jest dokładnie tym rodzajem szczegółu, który zamienia działające hasło w niedziałające, gdy zostanie pominięty.
Unikaj budowania pliku za pomocą niecytowanej zmiennej lub dokumentu wielowierszowego z rozwinięciami powłoki. Oba mogą przekształcić znaki, zanim dotrą do pliku, a wynikowy błąd wygląda jak odrzucenie przez VPN, ponieważ hasło na dysku naprawdę różni się od hasła, które znasz. Porównaj długość pliku w bajtach z oczekiwaną wartością, jeśli to podejrzewasz, bez wypisywania samego sekretu. Różnica jednego lub dwóch bajtów jest sygnaturą wypadku z cytowaniem.
Odczytaj etap z pierwszego błędu
Zachowaj pierwszy konkretny komunikat z jednej próby, a potem go sklasyfikuj. Lokalny błąd walidacji, brakujący klucz prywatny, niedostępny agent sekretów i błąd uwierzytelniania bramy to cztery różne wyniki z czterema różnymi właścicielami. Tylko jeden z nich dotyczy konta.
Jeśli brama naprawdę odrzuca poprawnie dostarczone dane logowania, sprawdź konto, backend uwierzytelniania i wszelkie wymagane wyzwanie z administratorem. Ogólny błąd uwierzytelniania nie wskazuje zabronionego znaku.
Przywróć zatwierdzoną wartość właściwym mechanizmem, zamiast redukować ją do liter i cyfr. Polityka haseł należy do operatora, a obejście, które po cichu ją omija, nie jest naprawą. Ukrywa też prawdziwy defekt przed następną osobą, która spotka ten sam błąd ze słabszym hasłem i bez lepszego pomysłu.