TOTP-förfrågan från OpenConnect saknas i NetworkManager: fyra kontroller

Gatewayen accepterar lösenordet, begär en kod, och dialogen erbjuder inget fält för den. Inget skrevs fel: NetworkManager-insticksprogrammet slutförde hemlighetsutbytet utan att begära det sexsiffriga värdet. Gå igenom de fyra kontrollerna nedan i ordning, eftersom bara en av dem ändrar klienten. Resten av listan utesluter gatewayen, kontot och insticksprogrammets bygge.

Första kontrollen: läs var autentiseringen stannade

Ett felaktigt lösenord misslyckas omedelbart. En saknad andra faktor misslyckas efter autentiseringssteget, vanligtvis med en upprepad begäran eller en timeout på gateway-sidan. Tidpunkten och gateway-loggen visar vilken omgång som lämnades obesvarad.

Läs anslutningsloggen innan du rör profilen. Om gatewayen rapporterar ofullständig autentisering eller en utgången utmaning skickade klienten aldrig koden. Om den rapporterar ogiltiga uppgifter är lösenordet problemet och ingen TOTP-inställning åtgärdar det.

Notera den exakta begäransordning som gatewayen förväntar sig: användarnamn, lösenord, sedan kod, eller användarnamn, kod, sedan lösenord. Vissa gatewayer ordnar om omgångarna, och en klient som bara känner till den första ordningen fastnar vid den andra.

Andra kontrollen: använd klienten som äger utmaningen

OpenConnect själv implementerar hela samtalet, inklusive utmaningsomgången. Att köra det direkt är det mest förutsägbara sättet att bekräfta att kontot och gatewayen fungerar:

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

Klienten frågar i den ordning gatewayen frågar. User agenten spelar roll eftersom vissa gatewayer anpassar inloggningsflödet till en känd klient, och en generisk sträng kan ge ett kortare flöde som aldrig begär koden. Kör det en gång i förgrunden innan du ordnar någon bakgrundstjänst.

Om kommandoraden frågar korrekt är kontot, gatewayen och den andra faktorn i ordning. Det återstående problemet är insticksprogrammets dialog, inte autentiseringstjänsten. Det isolerar den felande komponenten utan att röra servern. Spara kommandots utdata med incidentrapporten.

Om kommandoraden också hoppar över begäran, stanna och kontrollera gateway-konfigurationen med dess ägare. Ingen skrivbordsklient kan svara på en utmaning som servern aldrig skickar.

Tredje kontrollen: se om ditt insticksprogram erbjuder TOTP-läge

Vissa NetworkManager OpenConnect-byggen erbjuder ett tokenläge och ett user agent-fält på anslutningens Identity-flik. Ställ in user agenten på det värde gatewayen förväntar sig, välj manuell TOTP-inmatning och spara anslutningen.

Om dessa fält finns beror på insticksprogrammets version och på vilken anslutningsredigerare skrivbordet använder. En fristående redigerare kan visa alternativ som GNOME-panelen döljer, eller tvärtom. Kontrollera den installerade paketversionen innan du letar efter en dold inställning.

Om tokenläget finns och begäran fortfarande inte visas saknar bygget överlämningen av utmaningen mellan insticksprogrammet och den generiska hemlighetsdialogen. Att skriva lösenordet igen, installera om samma paket eller rensa nyckelringen skapar inte ett fält som bygget inte implementerar.

Fjärde kontrollen: behandla en genererad kod som en avvägning

Ett skript kan anropa oathtool för den aktuella koden och skicka användarnamn, lösenord och kod till nmcli connection up --ask. Sekvensen fungerar, men den delade hemligheten hamnar lagrad någonstans som alla som kan öppna skriptet kan läsa, och den läsaren kan skapa koder för alltid. Det är en permanent utökning av autentiseringsytan, inte en klienträttelse.

Den som väljer det bör låsa hemlighetsfilen till root, hålla genererade värden utanför skalhistoriken och behandla skriptet som autentiseringsmaterial. En wrapper som ekar koden till terminalen kastar bort den andra faktorn. Testa wrapperen med ett engångskonto först.

Skriptet måste också följa gatewayens begäransordning. Om servern begär koden före lösenordet skickar en fast inmatningssekvens fel värde till fel begäran och ger samma ofullständiga autentisering. Öva med ett testkonto innan du kopplar det till ett inloggningsjobb.

Bekräfta samma gateway och konto

Testa varje kringgående lösning mot samma gateway, samma konto och samma tunnelgrupp. En gateway som också kräver ett enhetscertifikat kan avvisa kommandorads-klienten av en anledning som inte har med TOTP att göra, och begäransordningen kan skilja sig från den du övat på.

Notera klienten, dess version, user agenten och begäransordningen som fungerade. Den anteckningen berättar för nästa person om problemet är insticksprogrammets bygge, gatewayens flöde eller kontots policy, utan ännu en omgång lösenordsåterställningar.

Avsluta med att ansluta igen en gång efter en fullständig utloggning. En cachad hemlighet kan få ett trasigt flöde att se reparerat ut till nästa session, och det är vid den andra anslutningen den saknade begäran vanligtvis återkommer.