Cererea TOTP a OpenConnect lipsește în NetworkManager: patru verificări

Gateway-ul acceptă parola, cere un cod, iar dialogul nu oferă niciun câmp pentru el. Nimic nu a fost tastat greșit: pluginul NetworkManager a finalizat schimbul de secrete fără să ceară valoarea de șase cifre. Parcurgeți cele patru verificări de mai jos în ordine, pentru că doar una dintre ele schimbă clientul. Restul listei exclude gateway-ul, contul și build-ul pluginului.

Prima verificare: citiți unde s-a oprit autentificarea

O parolă greșită eșuează imediat. Un al doilea factor lipsă eșuează după pasul acreditărilor, de obicei cu o cerere repetată sau cu un timeout pe partea gateway-ului. Momentul și jurnalul gateway-ului arată care rundă a rămas fără răspuns.

Citiți jurnalul conexiunii înainte de a atinge profilul. Dacă gateway-ul raportează o autentificare incompletă sau o provocare expirată, clientul nu a trimis niciodată codul. Dacă raportează acreditări invalide, problema este parola și nicio setare TOTP nu o va rezolva.

Notați ordinea exactă a cererilor pe care o așteaptă gateway-ul: nume de utilizator, parolă, apoi cod, sau nume de utilizator, cod, apoi parolă. Unele gateway-uri reordonează rundele, iar un client care știe doar prima ordine se va bloca la a doua.

A doua verificare: folosiți clientul care deține provocarea

OpenConnect însuși implementează întreaga conversație, inclusiv runda de provocare. Rularea lui direct este cea mai previzibilă cale de a confirma că contul și gateway-ul funcționează:

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

Clientul întreabă în ordinea în care întreabă gateway-ul. Agentul de utilizator contează pentru că unele gateway-uri adaptează fluxul de autentificare la un client cunoscut, iar un șir generic poate produce un flux mai scurt care nu cere niciodată codul. Rulați-l o dată în prim-plan înainte de a aranja orice serviciu în fundal.

Dacă linia de comandă întreabă corect, contul, gateway-ul și al doilea factor sunt în regulă. Problema rămasă este dialogul pluginului, nu serviciul de autentificare. Asta izolează componenta defectă fără a atinge serverul. Păstrați ieșirea comenzii împreună cu înregistrarea incidentului.

Dacă și linia de comandă sare peste cerere, opriți-vă și verificați configurația gateway-ului împreună cu proprietarul acestuia. Niciun client desktop nu poate răspunde la o provocare pe care serverul nu o trimite niciodată.

A treia verificare: vedeți dacă pluginul oferă modul TOTP

Unele build-uri NetworkManager OpenConnect oferă un mod token și un câmp de agent de utilizator în fila Identity a conexiunii. Setați agentul de utilizator la valoarea așteptată de gateway, alegeți introducerea manuală a TOTP și salvați conexiunea.

Dacă acele câmpuri există depinde de versiunea pluginului și de editorul de conexiuni folosit de desktop. Un editor independent poate arăta opțiuni pe care panoul GNOME le ascunde, sau invers. Verificați versiunea pachetului instalat înainte de a căuta o setare ascunsă.

Dacă modul token există și cererea tot nu apare, build-ului îi lipsește predarea provocării între plugin și dialogul generic de secrete. Rescrierea parolei, reinstalarea aceluiași pachet sau golirea portcheilor nu vor crea un câmp pe care build-ul nu îl implementează.

A patra verificare: tratați un cod generat ca pe un compromis

Un script poate apela oathtool pentru codul curent și poate trimite numele de utilizator, parola și codul în nmcli connection up --ask. Secvența funcționează, dar secretul comun ajunge stocat undeva lizibil pentru oricine poate deschide scriptul, iar acel cititor poate fabrica coduri pentru totdeauna. Este o extindere permanentă a suprafeței de acreditări, nu o corectare a clientului.

Cine alege asta ar trebui să blocheze fișierul secret pe root, să țină valorile generate în afara istoricului shell-ului și să trateze scriptul ca material de acreditări. Un wrapper care afișează codul în terminal aruncă al doilea factor. Testați mai întâi wrapper-ul cu un cont de unică folosință.

Scriptul trebuie să urmeze și ordinea cererilor gateway-ului. Dacă serverul cere codul înainte de parolă, o secvență fixă de intrare trimite valoarea greșită la cererea greșită și produce aceeași autentificare incompletă. Exersați cu un cont de test înainte de a-l conecta la o sarcină de autentificare.

Confirmați același gateway și același cont

Testați fiecare soluție alternativă pe același gateway, același cont și același grup de tunel. Un gateway care cere și un certificat de dispozitiv poate respinge clientul din linia de comandă dintr-un motiv fără legătură cu TOTP, iar ordinea cererilor poate diferi de cea exersată.

Notați clientul, versiunea lui, agentul de utilizator și ordinea cererilor care a funcționat. Acea înregistrare îi spune următoarei persoane dacă problema este build-ul pluginului, fluxul gateway-ului sau politica contului, fără încă o rundă de resetări de parolă.

Încheiați reconectându-vă o dată după o deconectare completă. Un secret din cache poate face un flux defect să pară reparat până la sesiunea următoare, iar la a doua conectare cererea lipsă revine de obicei.