TOTP-anmodning i OpenConnect mangler i NetworkManager: fire kontroller

Gatewayen accepterer adgangskoden, beder om en kode, og dialogen tilbyder intet felt til den. Intet er tastet forkert: NetworkManager-pluginet gennemførte hemmelighedsudvekslingen uden at anmode om den sekscifrede værdi. Gå gennem de fire kontroller nedenfor i rækkefølge, fordi kun én af dem ændrer klienten. Resten af listen udelukker gatewayen, kontoen og pluginetes build.

Første kontrol: læs, hvor godkendelsen stoppede

En forkert adgangskode fejler med det samme. En manglende anden faktor fejler efter legitimationsstrinnet, normalt med en gentagen anmodning eller en timeout på gatewayens side. Tidspunktet og gatewayens log viser, hvilken runde der blev efterladt ubesvaret.

Læs forbindelsesloggen, før du rører profilen. Hvis gatewayen rapporterer ufuldstændig godkendelse eller en udløbet udfordring, sendte klienten aldrig koden. Hvis den rapporterer ugyldige legitimationsoplysninger, er adgangskoden problemet, og ingen TOTP-indstilling vil løse det.

Noter den præcise anmodningsrækkefølge, som gatewayen forventer: brugernavn, adgangskode, derefter kode, eller brugernavn, kode, derefter adgangskode. Nogle gateways omarrangerer runderne, og en klient, der kun kender den første rækkefølge, går i stå ved den anden.

Anden kontrol: brug den klient, der ejer udfordringen

OpenConnect selv implementerer hele samtalen, inklusive udfordringsrunden. At køre det direkte er den mest forudsigelige måde at bekræfte, at kontoen og gatewayen virker:

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

Klienten spørger i den rækkefølge, gatewayen spørger. User agenten betyder noget, fordi nogle gateways tilpasser loginforløbet til en kendt klient, og en generisk streng kan give et kortere forløb, der aldrig beder om koden. Kør det én gang i forgrunden, før du opsætter nogen baggrundstjeneste.

Hvis kommandolinjen spørger korrekt, er kontoen, gatewayen og den anden faktor i orden. Det resterende problem er pluginets dialog, ikke godkendelsestjenesten. Det isolerer den fejlende komponent uden at røre serveren. Gem kommandolinjens output sammen med hændelsesrapporten.

Hvis kommandolinjen også springer anmodningen over, skal du stoppe og kontrollere gatewayens konfiguration sammen med dens ejer. Ingen desktopklient kan besvare en udfordring, som serveren aldrig sender.

Tredje kontrol: se, om dit plugin viser TOTP-tilstand

Nogle NetworkManager OpenConnect-builds viser en tokentilstand og et user agent-felt på forbindelsens Identity-fane. Sæt user agenten til den værdi, gatewayen forventer, vælg manuel TOTP-indtastning, og gem forbindelsen.

Om disse felter findes afhænger af pluginets version og af, hvilken forbindelseseditor skrivebordet bruger. En selvstændig editor kan vise valgmuligheder, som GNOME-panelet skjuler, eller omvendt. Kontroller den installerede pakkes version, før du leder efter en skjult indstilling.

Hvis tokentilstanden findes, og anmodningen stadig ikke vises, mangler buildet udfordringsoverførslen mellem pluginet og den generiske hemmelighedsdialog. At skrive adgangskoden igen, geninstallere samme pakke eller rydde nøgleringen skaber ikke et felt, som buildet ikke implementerer.

Fjerde kontrol: betragt en genereret kode som en afvejning

Et script kan kalde oathtool for den aktuelle kode og sende brugernavn, adgangskode og kode ind i nmcli connection up --ask. Sekvensen virker, men den delte hemmelighed ender med at være gemt et sted, som enhver, der kan åbne scriptet, kan læse, og den læser kan generere koder for evigt. Det er en permanent udvidelse af legitimationsoverfladen, ikke en klientrettelse.

Enhver, der vælger det, bør låse hemmelighedsfilen til root, holde genererede værdier ude af shell-historikken og behandle scriptet som legitimationsmateriale. En wrapper, der ekkoer koden til terminalen, smider den anden faktor væk. Test wrapperen med en midlertidig konto først.

Scriptet skal også følge gatewayens anmodningsrækkefølge. Hvis serveren beder om koden før adgangskoden, sender en fast inputsekvens den forkerte værdi til den forkerte anmodning og giver samme ufuldstændige godkendelse. Øv det mod en testkonto, før du kobler det til et loginjob.

Bekræft samme gateway og konto

Test hver omvej mod samme gateway, samme konto og samme tunnelgruppe. En gateway, der også kræver et enhedscertifikat kan afvise kommandolinjeklienten af en grund, der intet har med TOTP at gøre, og anmodningsrækkefølgen kan afvige fra den, du øvede.

Noter klienten, dens version, user agenten og den anmodningsrækkefølge, der virkede. Den registrering fortæller den næste person, om problemet er pluginets build, gatewayens forløb eller kontoens politik, uden endnu en runde med nulstilling af adgangskoder.

Afslut med at genoprette forbindelsen én gang efter en fuld logud. En cachet hemmelighed kan få et brudt forløb til at se rettet ud indtil næste session, og det er ved den anden forbindelse, at den manglende anmodning normalt vender tilbage.