Czy --key-password w OpenConnect to hasło Twojego konta VPN?

Przeczytaj nazwę opcji dosłownie. Nazywa klucz, a zamieszanie zaczyna się, gdy odblokowywany plik jest mylony z kontem, które ma zostać uwierzytelnione. Wklej hasło konta do tej opcji, a klient spróbuje otworzyć nim plik klucza, co kończy się niepowodzeniem z powodów, które nie mają nic wspólnego z logowaniem VPN.

Mylące jest to, że jedno połączenie może zgodnie z prawem wymagać obu sekretów. Uwierzytelnianie certyfikatem klienta może wymagać zaszyfrowanego klucza, a ta sama brama może po zaakceptowaniu certyfikatu nadal przeprowadzić wymianę uwierzytelniania użytkownika. Żaden z sekretów nie spełnia drugiego etapu, a awaria jednego z zewnątrz wygląda bardzo podobnie do awarii drugiego.

Dwa sekrety, dwa różne zadania

Czytaj role jako dostęp do pliku w przeciwieństwie do wpuszczenia do sieci. Hasło klucza odszyfrowuje klucz prywatny PEM wskazany w --sslkey, aby można było przedstawić certyfikat klienta TLS. To odszyfrowanie odbywa się lokalnie, w procesie klienta, a sama fraza hasła nigdy nie trafia do bramy. Brama widzi certyfikat i podpis wykonany kluczem. Podręcznik OpenConnect trzyma --key-password obok --certificate i --sslkey, a w kompilacjach, które mogą użyć klucza w TPM, ta sama opcja niesie zamiast tego hasło głównego klucza magazynu.

Hasło konta jest innego rodzaju. Wchodzi do wymiany uwierzytelniania: formularz z nazwą użytkownika i hasłem, token, runda SAML albo jakaś kombinacja ogłaszana przez bramę. Niektóre wdrożenia w ogóle o nie nie proszą, gdy certyfikat jest jedynym czynnikiem, a inne proszą nawet po certyfikacie, ponieważ certyfikat dowodzi urządzenia, a konto dowodzi osoby.

Mieszanie obu daje mylące błędy. Brama odrzucająca logowanie zwykle zgłasza błąd uwierzytelniania, podczas gdy błędna fraza hasła klucza zwykle zawodzi wcześniej, gdy warstwa TLS nie może odczytać pliku klucza. To różne etapy z różnymi poprawkami, a nazwy są wystarczająco podobne, że ludzie je zamieniają i potem ścigają niewłaściwy dziennik. Zanotuj, który komunikat się pojawił, zanim zmienisz jakiekolwiek ustawienie, bo brzmienie komunikatu to najtańsza dostępna diagnoza.

Kiedy hasło klucza jest naprawdę potrzebne

Opcja ma sens tylko wtedy, gdy istnieje zaszyfrowany klucz do odblokowania. Jeśli łączysz się nazwą użytkownika i hasłem oraz bez certyfikatu klienta, --key-password nie ma na czym działać i dodanie go niczego nie zmienia. Jeśli łączysz się z --certificate i --sslkey, o tym, czy fraza hasła zostanie w ogóle poproszona, decyduje format samego pliku klucza.

Oba sekrety w jednym poleceniu są częste w zarządzanych środowiskach: certyfikat urządzenia w zaszyfrowanym kluczu plus logowanie dla każdego użytkownika. Właściwa kolejność to pozwolić klientowi lokalnie zapytać o frazę hasła klucza, dokończyć uścisk dłoni certyfikatu, a następnie osobno obsłużyć komunikat konta z bramy. Próba wcześniejszego wypełnienia obu przez jeden wielokrotnie używany skrypt to miejsce, w którym zamieszanie zwykle się zaczyna.

Przydatna diagnoza to sprawdzenie, kiedy występuje awaria. Jeśli klient zatrzymuje się przed rozpoczęciem jakiegokolwiek uwierzytelniania sieciowego, podejrzewaj plik klucza, jego format lub frazę hasła. Jeśli sesja TLS zostanie nawiązana, a brama odrzuci użytkownika, klucz zrobił swoje, a problemem jest wymiana konta.

Trzymaj oba sekrety poza historią powłoki

Argumenty wiersza poleceń mogą odczytać inni lokalni użytkownicy przez tablicę procesów i często trafiają do historii powłoki, skryptów oraz transkrypcji wsparcia. OpenConnect potrafi odczytać hasło konta ze standardowego wejścia za pomocą --passwd-on-stdin, a fraza hasła klucza może pochodzić z interaktywnego pytania lub agenta, a nie z argumentu. Żaden mechanizm sam nie czyni sekretu bezpiecznym, ale oba trzymają go z dala od najbardziej eksponowanych miejsc.

Pliki zasługują na taką samą troskę. Skrypt, który zapisuje frazę hasła do pliku tymczasowego, powinien utworzyć go z restrykcyjnymi uprawnieniami, usunąć przy wyjściu i unikać katalogów czytelnych dla wszystkich. Fraza hasła, która przetrwa sesję w katalogu tymczasowym, to kopia, której zapomniałeś zrobić. Zmienne środowiskowe są widoczne dla procesów potomnych i często trafiają do wydruków narzędzi debugowania, więc nie są darmowym ulepszeniem względem argumentów.

Dane wyjściowe diagnostyki to cichy wyciek. Dzienniki klienta przy większej szczegółowości mogą pokazać treść żądań lub wartości opcji, a skopiowana transkrypcja terminala łatwo trafia do zgłoszenia, więc przeczytaj dane wyjściowe, zanim je udostępnisz.

Martwy przycisk na pulpicie to inna usterka

Wpis VPN na pulpicie, który pokazuje wirujące kółko, a potem nic, zwykle wcale nie jest problemem z uwierzytelnianiem. Przycisk należy do menedżera sieci, apletu producenta lub wtyczki, która uruchamia OpenConnect w Twoim imieniu, a brakujący komponent lub nieczytelny profil mogą wywołać dokładnie taki objaw. Ustal, który proces uruchamia przycisk, i przeczytaj jego błąd, zanim dotkniesz poświadczeń.

Kuszące jest poluzowanie weryfikacji certyfikatu lub wyłączenie sprawdzania, gdy GUI odmawia połączenia. To zamienia usterkę integracji klienta w obniżenie bezpieczeństwa i rzadko naprawia problem z uruchomieniem. Zachowaj weryfikację serwera nietkniętą, potwierdź, że profil wskazuje zamierzoną bramę, i sprawdź, czy pomocnik oczekiwany przez GUI jest rzeczywiście zainstalowany.

Krótka lista kontrolna rozdziela przypadki. Awaria lokalna, zanim wyruszy jakikolwiek pakiet, wskazuje na klucz lub instalację klienta. Odrzucenie przez bramę po sesji TLS wskazuje na wymianę konta. Przycisk, który nigdy nie uruchamia klienta, wskazuje na integrację z pulpitem. Trzy różne usterki, z których jedna to hasło, które właśnie miałeś wkleić w złe pole.