Richiesta TOTP di OpenConnect assente in NetworkManager: quattro controlli

Il gateway accetta la password, chiede un codice e la finestra non offre alcun campo per inserirlo. Non è stato digitato nulla di sbagliato: il plugin di NetworkManager ha completato lo scambio del segreto senza richiedere il valore a sei cifre. Seguite i quattro controlli qui sotto nell’ordine, perché solo uno di essi cambia il client. Il resto dell’elenco esclude il gateway, l’account e la build del plugin.

Primo controllo: leggete dove si è fermata l’autenticazione

Una password errata fallisce subito. Un secondo fattore mancante fallisce dopo il passaggio delle credenziali, di solito con una richiesta ripetuta o un timeout sul lato del gateway. Il momento e il registro del gateway indicano quale turno è rimasto senza risposta.

Leggete il registro della connessione prima di toccare il profilo. Se il gateway segnala un’autenticazione incompleta o una sfida scaduta, il client non ha mai inviato il codice. Se segnala credenziali non valide, il problema è la password e nessuna impostazione TOTP lo risolverà.

Annotate l’esatta sequenza di richieste attesa dal gateway: nome utente, password, poi codice, oppure nome utente, codice, poi password. Alcuni gateway riordinano i turni e un client che conosce solo il primo ordine si bloccherà sul secondo.

Secondo controllo: usate il client che possiede la sfida

OpenConnect stesso implementa l’intera conversazione, incluso il turno della sfida. Eseguirlo direttamente è il modo più prevedibile per confermare che l’account e il gateway funzionano:

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

Il client chiede nell’ordine in cui chiede il gateway. L’agente utente conta perché alcuni gateway adattano il flusso di accesso a un client noto, e una stringa generica può produrre un flusso più breve che non chiede mai il codice. Eseguitelo una volta in primo piano prima di predisporre qualsiasi servizio in background.

Se la riga di comando chiede correttamente, l’account, il gateway e il secondo fattore sono a posto. Il problema rimasto è la finestra del plugin, non il servizio di autenticazione. Questo isola il componente guasto senza toccare il server. Conservate l’output del comando insieme al registro dell’incidente.

Se anche la riga di comando salta la richiesta, fermatevi e verificate la configurazione del gateway con il suo responsabile. Nessun client desktop può rispondere a una sfida che il server non invia mai.

Terzo controllo: verificate se il vostro plugin espone la modalità TOTP

Alcune build di NetworkManager OpenConnect espongono una modalità token e un campo agente utente nella scheda Identity della connessione. Impostate l’agente utente sul valore atteso dal gateway, scegliete l’inserimento manuale di TOTP e salvate la connessione.

L’esistenza di questi campi dipende dalla versione del plugin e da quale editor di connessioni usa il desktop. Un editor autonomo può mostrare opzioni che il pannello GNOME nasconde, o il contrario. Controllate la versione del pacchetto installato prima di cercare un’impostazione nascosta.

Se la modalità token è presente e la richiesta continua a non comparire, alla build manca il passaggio della sfida tra il plugin e la finestra generica dei segreti. Riscrivere la password, reinstallare lo stesso pacchetto o svuotare il portachiavi non creerà un campo che la build non implementa.

Quarto controllo: trattate un codice generato come un compromesso

Uno script può chiamare oathtool per il codice corrente e passare nome utente, password e codice a nmcli connection up --ask. La sequenza funziona, ma il segreto condiviso finisce salvato in un luogo leggibile da chiunque possa aprire lo script, e quel lettore può generare codici per sempre. È un’estensione permanente della superficie delle credenziali, non una correzione del client.

Chi lo sceglie dovrebbe bloccare il file del segreto su root, tenere i valori generati fuori dalla cronologia della shell e trattare lo script come materiale di credenziali. Un wrapper che rilancia il codice al terminale butta via il secondo fattore. Provate prima il wrapper con un account usa e getta.

Lo script deve anche seguire l’ordine delle richieste del gateway. Se il server chiede il codice prima della password, una sequenza di input fissa invia il valore sbagliato alla richiesta sbagliata e produce la stessa autenticazione incompleta. Esercitatelo con un account di prova prima di collegarlo a un’attività di accesso.

Confermate lo stesso gateway e lo stesso account

Provate ogni soluzione alternativa contro lo stesso gateway, lo stesso account e lo stesso gruppo di tunnel. Un gateway che richiede anche un certificato del dispositivo può rifiutare il client da riga di comando per un motivo estraneo a TOTP, e l’ordine delle richieste può differire da quello esercitato.

Annotate il client, la sua versione, l’agente utente e la sequenza di richieste che ha funzionato. Quel registro dice alla persona successiva se il problema è la build del plugin, il flusso del gateway o la policy dell’account, senza un altro giro di reimpostazioni delle password.

Concludete riconnettendovi una volta dopo un logout completo. Un segreto nella cache può far sembrare riparato un flusso rotto fino alla sessione successiva, ed è alla seconda connessione che la richiesta mancante di solito ritorna.