V NetworkManagerju manjka poziv TOTP za OpenConnect: štiri preverjanja

Prehod sprejme geslo, zahteva kodo in pogovorno okno ne ponudi nobenega polja zanjo. Nič ni bilo napačno vtipkano: vtičnik NetworkManagerja je zaključil izmenjavo skrivnosti, ne da bi zahteval šestmestno vrednost. Opravite štiri spodnja preverjanja po vrsti, ker le eno od njih spremeni odjemalca. Preostanek seznama izključi prehod, račun in gradnjo vtičnika.

Prvo preverjanje: preberite, kje se je preverjanje pristnosti ustavilo

Napačno geslo spodleti takoj. Manjkajoči drugi dejavnik spodleti po koraku poverilnic, običajno s ponovljeno zahtevo ali s potekom časa na strani prehoda. Čas in dnevnik prehoda pokažeta, kateri krog je ostal brez odgovora.

Preberite dnevnik povezave, preden se dotaknete profila. Če prehod poroča o nepopolni avtentikaciji ali poteklem izzivu, odjemalec kode nikoli ni poslal. Če poroča o neveljavnih poverilnicah, je težava v geslu in nobena nastavitev TOTP tega ne bo popravila.

Zapišite natančno zaporedje zahtev, ki jih prehod pričakuje: uporabniško ime, geslo, nato koda, ali uporabniško ime, koda, nato geslo. Nekateri prehodi prerazporedijo kroge in odjemalec, ki pozna le prvo zaporedje, se bo ustavil pri drugem.

Drugo preverjanje: uporabite odjemalca, ki ima izziv

OpenConnect sam izvede celoten pogovor, vključno s krogom izziva. Neposredno izvajanje je najbolj predvidljiv način za potrditev, da račun in prehod delujeta:

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

Odjemalec sprašuje v zaporedju, v katerem sprašuje prehod. Uporabniški agent je pomemben, ker nekateri prehodi prilagodijo tok prijave znanemu odjemalcu, generični niz pa lahko ustvari krajši tok, ki nikoli ne zahteva kode. Zaženite ga enkrat v ospredju, preden uredite katero koli storitev v ozadju.

Če ukazna vrstica sprašuje pravilno, so račun, prehod in drugi dejavnik v redu. Preostala težava je pogovorno okno vtičnika, ne storitev avtentikacije. To izolira okvarjeno komponento, ne da bi se dotaknilo strežnika. Shranite izhod ukaza skupaj z zapisom o incidentu.

Če tudi ukazna vrstica preskoči zahtevo, se ustavite in preverite konfiguracijo prehoda z njegovim lastnikom. Noben namizni odjemalec ne more odgovoriti na izziv, ki ga strežnik nikoli ne pošlje.

Tretje preverjanje: preverite, ali vaš vtičnik ponuja način TOTP

Nekatere gradnje NetworkManager OpenConnect ponujajo način žetona in polje uporabniškega agenta na zavihku Identity povezave. Nastavite uporabniškega agenta na vrednost, ki jo pričakuje prehod, izberite ročni vnos TOTP in shranite povezavo.

Ali ta polja obstajajo, je odvisno od različice vtičnika in od tega, kateri urejevalnik povezav uporablja namizje. Samostojen urejevalnik lahko prikaže možnosti, ki jih plošča GNOME skriva, ali obratno. Pred iskanjem skrite nastavitve preverite različico nameščenega paketa.

Če način žetona obstaja in se zahteva še vedno ne prikaže, gradnji manjka predaja izziva med vtičnikom in splošnim pogovornim oknom za skrivnosti. Ponovno tipkanje gesla, ponovna namestitev istega paketa ali čiščenje shrambe ključev ne bo ustvarilo polja, ki ga gradnja ne izvaja.

Četrto preverjanje: obravnavajte ustvarjeno kodo kot kompromis

Skript lahko pokliče oathtool za trenutno kodo in posreduje uporabniško ime, geslo in kodo v nmcli connection up --ask. Zaporedje deluje, vendar skupna skrivnost konča shranjena tam, kjer jo lahko prebere vsak, ki lahko odpre skript, in ta bralec lahko ustvarja kode za vedno. To je trajna razširitev površine poverilnic, ne popravek odjemalca.

Kdor to izbere, naj datoteko skrivnosti zaklene na root, obdrži ustvarjene vrednosti zunaj zgodovine lupine in skript obravnava kot material poverilnic. Ovoj, ki kodo odmeva v terminal, zavrže drugi dejavnik. Ovoj najprej preizkusite z enkratnim računom.

Skript mora upoštevati tudi zaporedje zahtev prehoda. Če strežnik zahteva kodo pred geslom, fiksno vnosno zaporedje pošlje napačno vrednost na napačno zahtevo in ustvari enako nepopolno avtentikacijo. Vadite s testnim računom, preden ga povežete z opravilom prijave.

Potrdite isti prehod in isti račun

Vsako obhodno rešitev preizkusite na istem prehodu, istem računu in isti skupini tunela. Prehod, ki zahteva tudi potrdilo naprave, lahko zavrne odjemalca ukazne vrstice iz razloga, ki ni povezan s TOTP, in zaporedje zahtev se lahko razlikuje od vadbenega.

Zapišite odjemalca, njegovo različico, uporabniškega agenta in zaporedje zahtev, ki je delovalo. Ta zapis pove naslednji osebi, ali je težava v gradnji vtičnika, toku prehoda ali politiki računa, brez še enega kroga ponastavitev gesel.

Zaključite z enim ponovnim povezovanjem po popolni odjavi. Shranjena skrivnost lahko povzroči, da je pokvarjen tok videti popravljen do naslednje seje, in prav pri drugi povezavi se manjkajoča zahteva običajno vrne.