TOTP upit u OpenConnectu nedostaje u NetworkManageru: četiri provjere

Prolaz prihvata lozinku, traži kod, a dijalog ne nudi polje za njega. Ništa nije pogrešno otkucano: dodatak NetworkManagera završio je razmjenu tajne bez traženja šestocifrene vrijednosti. Prođite kroz četiri provjere ispod redom, jer samo jedna od njih mijenja klijenta. Ostatak liste isključuje prolaz, račun i build dodatka.

Prva provjera: pročitajte gdje je autentifikacija stala

Pogrešna lozinka pada odmah. Nedostajući drugi faktor pada nakon koraka s akreditivima, obično uz ponovljeni upit ili istek vremena na strani prolaza. Vrijeme i zapisnik prolaza govore koji je krug ostao bez odgovora.

Pročitajte zapisnik veze prije nego dirate profil. Ako prolaz javlja nepotpunu autentifikaciju ili istekao izazov, klijent nikad nije poslao kod. Ako javlja nevažeće akreditive, problem je u lozinci i nijedna TOTP postavka to neće popraviti.

Zabilježite tačan redoslijed upita koji prolaz očekuje: korisničko ime, lozinka, pa kod, ili korisničko ime, kod, pa lozinka. Neki prolazi preslažu krugove, a klijent koji zna samo prvi redoslijed zastat će na drugom.

Druga provjera: koristite klijenta koji posjeduje izazov

Sam OpenConnect provodi cijeli razgovor, uključujući krug izazova. Pokretanje izravno najpredvidljiviji je način da potvrdite da račun i prolaz rade:

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

Klijent pita redoslijedom kojim pita prolaz. Korisnički agent je važan jer neki prolazi prilagođavaju tok prijave poznatom klijentu, a generički niz može dati kraći tok koji nikad ne traži kod. Pokrenite ga jednom u prednjem planu prije nego uredite bilo koju pozadinsku uslugu.

Ako naredbeni redak ispravno pita, račun, prolaz i drugi faktor su u redu. Preostali problem je dijalog dodatka, a ne usluga autentifikacije. To izolira neispravnu komponentu bez diranja poslužitelja. Sačuvajte izlaz naredbe uz zapis o incidentu.

Ako i naredbeni redak preskoči upit, zaustavite se i provjerite konfiguraciju prolaza s njegovim vlasnikom. Nijedan stolni klijent ne može odgovoriti na izazov koji poslužitelj nikad ne pošalje.

Treća provjera: provjerite nudi li vaš dodatak TOTP način rada

Neki buildovi NetworkManager OpenConnecta nude način rada s tokenom i polje korisničkog agenta na kartici Identity veze. Postavite korisnički agent na vrijednost koju prolaz očekuje, odaberite ručni unos TOTP-a i sačuvajte vezu.

Postoje li ta polja zavisi od verzije dodatka i od toga koji uređivač veza koristi radna površina. Samostalni uređivač može prikazati opcije koje GNOME panel skriva, ili obrnuto. Provjerite verziju instaliranog paketa prije traženja skrivene postavke.

Ako način rada s tokenom postoji, a upit se ipak ne pojavljuje, buildu nedostaje predaja izazova između dodatka i generičkog dijaloga za tajne. Ponovno upisivanje lozinke, ponovna instalacija istog paketa ili čišćenje privjeska ključeva neće stvoriti polje koje build ne implementira.

Četvrta provjera: tretirajte generisani kod kao kompromis

Skripta može pozvati oathtool za trenutni kod i proslijediti korisničko ime, lozinku i kod u nmcli connection up --ask. Slijed radi, ali zajednička tajna završi pohranjena negdje što može pročitati svako ko otvori skriptu, a taj čitalac može stvarati kodove zauvijek. To je trajno proširenje površine akreditiva, a ne popravka klijenta.

Ko to odabere, treba da zaključa datoteku tajne na root, drži generisane vrijednosti izvan historije ljuske i tretira skriptu kao akreditivni materijal. Omotač koji ispisuje kod u terminal odbacuje drugi faktor. Prvo testirajte omotač s privremenim računom.

Skripta mora slijediti i redoslijed upita prolaza. Ako poslužitelj traži kod prije lozinke, fiksni slijed unosa šalje pogrešnu vrijednost na pogrešan upit i daje istu nepotpunu autentifikaciju. Uvježbajte to s testnim računom prije nego ga povežete sa zadatkom prijave.

Potvrdite isti prolaz i račun

Testirajte svaki zaobilazni put na istom prolazu, istom računu i istoj grupi tunela. Prolaz koji traži i certifikat uređaja može odbiti klijenta naredbenog retka iz razloga nepovezanog s TOTP-om, a redoslijed upita može se razlikovati od uvježbanog.

Zabilježite klijenta, njegovu verziju, korisnički agent i redoslijed upita koji je radio. Taj zapis govori sljedećoj osobi da li je problem u buildu dodatka, toku prolaza ili politici računa, bez još jednog kruga resetovanja lozinki.

Završite ponovnim spajanjem jednom nakon potpune odjave. Keširana tajna može učiniti da pokvaren tok izgleda popravljen do sljedeće sesije, a upravo se pri drugom spajanju nedostajući upit obično vraća.