OpenConnect-TOTP-vraag ontbreek in NetworkManager: vier kontroles

Die poort aanvaar die wagwoord, vra ’n kode, en die dialoog bied geen veld daarvoor nie. Niks is verkeerd getik nie: die NetworkManager-inprop het die geheime-uitruiling voltooi sonder om die sesyferwaarde te vra. Werk die vier kontroles hieronder in volgorde deur, want net een van hulle verander die kliënt. Die res van die lys sluit die poort, die rekening en die bou van die inprop uit.

Kontrole een: lees waar die verifikasie gestop het

’n Verkeerde wagwoord misluk onmiddellik. ’n Ontbrekende tweede faktor misluk ná die geloofwaardigheidstap, gewoonlik met ’n herhaalde vraag of ’n tydsverloop aan die poort se kant. Die tydsberekening en die poort se logboek wys watter ronde onbeantwoord gelaat is.

Lees die verbindingslogboek voordat jy aan die profiel raak. As die poort ’n onvolledige verifikasie of ’n uitgeteerde uitdaging rapporteer, het die kliënt nooit die kode gestuur nie. As dit ongeldige geloofsbriewe rapporteer, is die wagwoord die probleem en geen TOTP-instelling sal dit regstel nie.

Let op die presiese vraagvolgorde wat die poort verwag: gebruikersnaam, wagwoord, dan kode, of gebruikersnaam, kode, dan wagwoord. Sommige poorte herrangskik die rondtes, en ’n kliënt wat net die eerste volgorde ken, sal by die tweede vasval.

Kontrole twee: gebruik die kliënt wat die uitdaging besit

OpenConnect self voer die volle gesprek uit, insluitend die uitdagingsronde. Om dit direk te laat loop, is die mees voorspelbare manier om te bevestig dat die rekening en die poort werk:

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

Die kliënt vra in die volgorde wat die poort vra. Die gebruikersagent maak saak, want sommige poorte pas die aanmeldvloei aan vir ’n bekende kliënt, en ’n generiese string kan ’n korter vloei lewer wat nooit om die kode vra nie. Laat dit een keer in die voorgrond loop voordat jy enige agtergronddiens reël.

As die opdragreël korrek vra, is die rekening, die poort en die tweede faktor in orde. Die oorblywende probleem is die inprop se dialoog, nie die verifikasiediens nie. Dit isoleer die foutiewe komponent sonder om aan die bediener te raak. Hou die opdrag se uitset by die voorvalrekord.

As die opdragreël ook die vraag oorslaan, stop en kontroleer die poort se konfigurasie saam met die eienaar daarvan. Geen lessenaarkliënt kan ’n uitdaging beantwoord wat die bediener nooit stuur nie.

Kontrole drie: kyk of jou inprop TOTP-modus bied

Sommige NetworkManager OpenConnect-boude bied ’n tokenmodus en ’n gebruikersagentveld in die verbinding se Identity-oortjie. Stel die gebruikersagent op die waarde wat die poort verwag, kies handmatige TOTP-invoer en stoor die verbinding.

Of daardie velde bestaan, hang af van die inprop se weergawe en van watter verbindingredigeerder die lessenaar gebruik. ’n Selfstandige redigeerder kan opsies wys wat die GNOME-paneel wegsteek, of omgekeerd. Kontroleer die geïnstalleerde pakket se weergawe voordat jy na ’n verborge instelling soek.

As die tokenmodus daar is en die vraag steeds nie verskyn nie, kort die bou die uitdagings-oordrag tussen die inprop en die generiese geheime-dialoog. Om die wagwoord oor te tik, dieselfde pakket te herinstalleer of die sleutelring skoon te maak, sal nie ’n veld skep wat die bou nie implementeer nie.

Kontrole vier: beskou ’n gegenereerde kode as ’n kompromie

’n Skrip kan oathtool roep vir die huidige kode en gebruikersnaam, wagwoord en kode in nmcli connection up --ask inlei. Die reeks werk, maar die gedeelde geheim beland op ’n plek wat leesbaar is vir elkeen wat die skrip kan oopmaak, en daardie leser kan vir ewig kodes maak. Dit is ’n permanente uitbreiding van die geloofwaardigheidsoppervlak, nie ’n kliëntregstelling nie.

Enigiemand wat dit kies, moet die geheime lêer tot root beperk, gegenereerde waardes uit die skulpgeskiedenis hou en die skrip as geloofwaardigheidsmateriaal behandel. ’n Omhulsel wat die kode na die terminaal eggo, gooi die tweede faktor weg. Toets die omhulsel eers met ’n weggooirekening.

Die skrip moet ook die poort se vraagvolgorde volg. As die bediener voor die wagwoord om die kode vra, stuur ’n vaste invoervolgorde die verkeerde waarde na die verkeerde vraag en lewer dieselfde onvolledige verifikasie. Oefen dit teen ’n toetsrekening voordat jy dit aan ’n aanmeldtaak koppel.

Bevestig dieselfde poort en rekening

Toets elke omweg teen dieselfde poort, dieselfde rekening en dieselfde tonnelligroep. ’n Poort wat ook ’n toestelsertifikaat vereis kan die opdragreëlkliënt om ’n rede verwerp wat nie met TOTP verband hou nie, en die vraagvolgorde kan verskil van die een wat jy geoefen het.

Teken die kliënt, sy weergawe, die gebruikersagent en die vraagvolgorde aan wat gewerk het. Daardie rekord vertel die volgende persoon of die kwessie die inprop se bou, die poort se vloei of die rekening se beleid is, sonder nog ’n ronde wagwoordherstellings.

Maak klaar deur een keer weer te koppel ná ’n volledige afmelding. ’n Gekasde geheim kan ’n stukkende vloei laat lyk asof dit reg is tot die volgende sessie, en dit is by die tweede koppeling waar die ontbrekende vraag gewoonlik terugkeer.