Brak monitu TOTP OpenConnect w NetworkManager: cztery kontrole

Brama przyjmuje hasło, prosi o kod, a okno nie oferuje żadnego pola dla niego. Nic nie zostało wpisane błędnie: wtyczka NetworkManager zakończyła wymianę sekretu, nie prosząc o sześciocyfrową wartość. Przejdź cztery kontrole poniżej po kolei, bo tylko jedna z nich zmienia klienta. Reszta listy wyklucza bramę, konto i kompilację wtyczki.

Pierwsza kontrola: przeczytaj, gdzie zatrzymało się uwierzytelnianie

Błędne hasło zawodzi od razu. Brak drugiego czynnika zawodzi po kroku poświadczeń, zwykle powtórzonym żądaniem lub przekroczeniem czasu po stronie bramy. Czas i log bramy pokazują, która runda pozostała bez odpowiedzi.

Przeczytaj log połączenia, zanim dotkniesz profilu. Jeśli brama zgłasza niepełne uwierzytelnienie lub wygasłe wyzwanie, klient nigdy nie wysłał kodu. Jeśli zgłasza nieprawidłowe poświadczenia, problemem jest hasło i żadne ustawienie TOTP tego nie naprawi.

Zanotuj dokładną kolejność żądań, której oczekuje brama: nazwa użytkownika, hasło, potem kod, albo nazwa użytkownika, kod, potem hasło. Niektóre bramy zmieniają kolejność rund, a klient znający tylko pierwszą kolejność zatrzyma się na drugiej.

Druga kontrola: użyj klienta, który posiada wyzwanie

Sam OpenConnect realizuje całą rozmowę, w tym rundę wyzwania. Uruchomienie go bezpośrednio to najbardziej przewidywalny sposób potwierdzenia, że konto i brama działają:

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

Klient pyta w kolejności, w jakiej pyta brama. User agent ma znaczenie, bo niektóre bramy dopasowują przepływ logowania do znanego klienta, a ogólny ciąg może dać krótszy przepływ, który nigdy nie prosi o kod. Uruchom go raz na pierwszym planie, zanim skonfigurujesz jakąkolwiek usługę w tle.

Jeśli wiersz poleceń pyta poprawnie, konto, brama i drugi czynnik są w porządku. Pozostałym problemem jest okno wtyczki, a nie usługa uwierzytelniania. To izoluje wadliwy komponent bez dotykania serwera. Zachowaj wynik polecenia wraz z zapisem incydentu.

Jeśli wiersz poleceń również pomija żądanie, zatrzymaj się i sprawdź konfigurację bramy z jej właścicielem. Żaden klient pulpitu nie odpowie na wyzwanie, którego serwer nigdy nie wysyła.

Trzecia kontrola: sprawdź, czy wtyczka oferuje tryb TOTP

Niektóre kompilacje NetworkManager OpenConnect oferują tryb tokenu i pole user agenta na karcie Identity połączenia. Ustaw user agenta na wartość oczekiwaną przez bramę, wybierz ręczne wprowadzanie TOTP i zapisz połączenie.

To, czy te pola istnieją, zależy od wersji wtyczki i od tego, którego edytora połączeń używa pulpit. Samodzielny edytor może pokazywać opcje, które panel GNOME ukrywa, albo odwrotnie. Sprawdź wersję zainstalowanego pakietu, zanim poszukasz ukrytego ustawienia.

Jeśli tryb tokenu istnieje, a żądanie nadal się nie pojawia, kompilacji brakuje przekazania wyzwania między wtyczką a ogólnym oknem sekretów. Ponowne wpisanie hasła, reinstalacja tego samego pakietu lub wyczyszczenie pęku kluczy nie stworzy pola, którego kompilacja nie implementuje.

Czwarta kontrola: traktuj wygenerowany kod jako kompromis

Skrypt może wywołać oathtool dla bieżącego kodu i przekazać nazwę użytkownika, hasło i kod do nmcli connection up --ask. Sekwencja działa, ale wspólny sekret trafia do miejsca czytelnego dla każdego, kto może otworzyć skrypt, a ten czytelnik może tworzyć kody na zawsze. To trwałe rozszerzenie powierzchni poświadczeń, a nie naprawa klienta.

Kto to wybierze, powinien zablokować plik sekretu na root, trzymać wygenerowane wartości poza historią powłoki i traktować skrypt jako materiał poświadczeń. Otoczka, która powtarza kod w terminalu, wyrzuca drugi czynnik. Najpierw przetestuj otoczkę na koncie jednorazowym.

Skrypt musi też przestrzegać kolejności żądań bramy. Jeśli serwer prosi o kod przed hasłem, stała sekwencja wejścia wysyła złą wartość do złego żądania i daje to samo niepełne uwierzytelnienie. Przećwicz to na koncie testowym, zanim podłączysz je do zadania logowania.

Potwierdź tę samą bramę i to samo konto

Testuj każde obejście na tej samej bramie, tym samym koncie i tej samej grupie tunelu. Brama, która wymaga też certyfikatu urządzenia, może odrzucić klienta wiersza poleceń z powodu niezwiązanego z TOTP, a kolejność żądań może się różnić od przećwiczonej.

Zanotuj klienta, jego wersję, user agenta i kolejność żądań, która zadziałała. Ten zapis mówi następnej osobie, czy problemem jest kompilacja wtyczki, przepływ bramy czy polityka konta, bez kolejnej rundy resetowania haseł.

Zakończ jednym ponownym połączeniem po pełnym wylogowaniu. Sekret w pamięci podręcznej może sprawić, że zepsuty przepływ będzie wyglądał na naprawiony do następnej sesji, a właśnie przy drugim połączeniu brakujący monit zwykle wraca.