Hiányzik az OpenConnect TOTP-kérése a NetworkManagerben: négy ellenőrzés

Az átjáró elfogadja a jelszót, kódot kér, és a párbeszédablak nem kínál mezőt hozzá. Semmit nem írt be rosszul: a NetworkManager beépülő modulja befejezte a titokcserét anélkül, hogy elkérte volna a hatjegyű értéket. Sorrendben végezze el az alábbi négy ellenőrzést, mert közülük csak egy változtatja meg a klienst. A lista többi része kizárja az átjárót, a fiókot és a beépülő modul buildjét.

Első ellenőrzés: olvassa el, hol állt meg a hitelesítés

A rossz jelszó azonnal meghiúsul. A hiányzó második tényező a hitelesítő adatok lépése után hiúsul meg, általában ismételt kéréssel vagy az átjáró oldalán lejárt idővel. Az időzítés és az átjárónapló megmondja, melyik kör maradt válasz nélkül.

Olvassa el a kapcsolati naplót, mielőtt hozzányúl a profilhoz. Ha az átjáró hiányos hitelesítésről vagy lejárt kihívásról számol be, a kliens soha nem küldte el a kódot. Ha érvénytelen hitelesítő adatokról számol be, a jelszó a probléma, és semmilyen TOTP-beállítás nem javítja meg.

Jegyezze fel a pontos kérési sorrendet, amelyet az átjáró elvár: felhasználónév, jelszó, majd kód, vagy felhasználónév, kód, majd jelszó. Egyes átjárók átrendezik a köröket, és a kliens, amely csak az első sorrendet ismeri, a másodiknál elakad.

Második ellenőrzés: használja azt a klienst, amelyiké a kihívás

Maga az OpenConnect valósítja meg a teljes beszélgetést, a kihívási kört is beleértve. A közvetlen futtatás a legkiszámíthatóbb módja annak igazolására, hogy a fiók és az átjáró működik:

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

A kliens abban a sorrendben kérdez, ahogy az átjáró kérdez. A felhasználói ügynök számít, mert egyes átjárók ismert klienshez szabják a bejelentkezési folyamatot, és egy általános karakterlánc rövidebb folyamatot eredményezhet, amely soha nem kéri a kódot. Futtassa egyszer előtérben, mielőtt bármilyen háttérszolgáltatást beállít.

Ha a parancssor helyesen kérdez, a fiók, az átjáró és a második tényező rendben van. A fennmaradó probléma a beépülő modul párbeszédablaka, nem a hitelesítési szolgáltatás. Ez elkülöníti a hibás összetevőt anélkül, hogy hozzányúlna a kiszolgálóhoz. Őrizze meg a parancs kimenetét az incidensfeljegyzéssel együtt.

Ha a parancssor is kihagyja a kérést, álljon meg, és ellenőrizze az átjáró konfigurációját a tulajdonosával. Egyetlen asztali kliens sem tud válaszolni olyan kihívásra, amelyet a kiszolgáló soha nem küld.

Harmadik ellenőrzés: nézze meg, kínál-e a beépülő modul TOTP-módot

Egyes NetworkManager OpenConnect buildek tokenmódot és felhasználóiügynök-mezőt kínálnak a kapcsolat Identity lapján. Állítsa a felhasználói ügynököt arra az értékre, amelyet az átjáró elvár, válassza a kézi TOTP-bevitelt, és mentse a kapcsolatot.

Hogy léteznek-e ezek a mezők, a beépülő modul verziójától és attól függ, melyik kapcsolatszerkesztőt használja az asztal. Egy önálló szerkesztő mutathat olyan beállításokat, amelyeket a GNOME panel elrejt, vagy fordítva. A rejtett beállítás keresése előtt ellenőrizze a telepített csomag verzióját.

Ha a tokenmód létezik, és a kérés mégsem jelenik meg, a buildből hiányzik a kihívás átadása a beépülő modul és az általános titokpárbeszéd között. A jelszó újragépelése, ugyanazon csomag újratelepítése vagy a kulcskarikák törlése nem hoz létre olyan mezőt, amelyet a build nem valósít meg.

Negyedik ellenőrzés: tekintse a generált kódot kompromisszumnak

Egy szkript meghívhatja az oathtool parancsot az aktuális kódhoz, és beírhatja a felhasználónevet, a jelszót és a kódot az nmcli connection up --ask parancsba. A sorrend működik, de a megosztott titok olyan helyre kerül, ahol bárki olvashatja, aki meg tudja nyitni a szkriptet, és az az olvasó örökre kódokat gyárthat. Ez a hitelesítő felület tartós bővítése, nem kliensjavítás.

Aki ezt választja, zárja a titokfájlt rootra, tartsa a generált értékeket a shell-előzményeken kívül, és kezelje a szkriptet hitelesítő anyagként. Az a burkoló, amely a kódot a terminálra visszhangozza, eldobja a második tényezőt. Először egy eldobható fiókkal tesztelje a burkolót.

A szkriptnek követnie kell az átjáró kérési sorrendjét is. Ha a kiszolgáló a jelszó előtt kéri a kódot, egy rögzített beviteli sorrend a rossz értéket a rossz kéréshez küldi, és ugyanazt a hiányos hitelesítést eredményezi. Gyakorolja egy tesztfiókkal, mielőtt bejelentkezési feladathoz kapcsolja.

Erősítse meg ugyanazt az átjárót és fiókot

Minden megkerülő megoldást ugyanazon átjáró, ugyanazon fiók és ugyanazon alagútcsoport ellen teszteljen. Az az átjáró, amely eszköztanúsítványt is megkövetel, a TOTP-tól független okból utasíthatja el a parancssori klienst, és a kérési sorrend eltérhet a gyakorolttól.

Jegyezze fel a klienst, annak verzióját, a felhasználói ügynököt és a működött kérési sorrendet. Ez a feljegyzés megmondja a következő embernek, hogy a beépülő modul buildjében, az átjáró folyamatában vagy a fiók szabályzatában van-e a probléma, egy újabb jelszó-visszaállítási kör nélkül.

Fejezze be egyetlen újracsatlakozással teljes kijelentkezés után. A gyorsítótárazott titok a következő munkamenetig javítottnak láttathatja a törött folyamatot, és a hiányzó kérés általában a második kapcsolódásnál tér vissza.