Falta el aviso de TOTP de OpenConnect en NetworkManager: cuatro comprobaciones

La puerta de enlace acepta la contraseña, pide un código y el diálogo no ofrece ningún campo para él. No se escribió nada mal: el complemento de NetworkManager completó el intercambio de secretos sin solicitar el valor de seis dígitos. Haga las cuatro comprobaciones siguientes en orden, porque solo una de ellas cambia el cliente. El resto de la lista descarta la puerta de enlace, la cuenta y la compilación del complemento.

Primera comprobación: lea dónde se detuvo la autenticación

Una contraseña incorrecta falla de inmediato. Un segundo factor ausente falla después del paso de credenciales, normalmente con una petición repetida o un tiempo de espera agotado en el lado de la puerta de enlace. El momento y el registro de la puerta de enlace indican qué ronda quedó sin respuesta.

Lea el registro de la conexión antes de tocar el perfil. Si la puerta de enlace informa de una autenticación incompleta o de un desafío caducado, el cliente nunca envió el código. Si informa de credenciales no válidas, el problema es la contraseña y ningún ajuste de TOTP lo arreglará.

Anote la secuencia exacta de peticiones que espera la puerta de enlace: nombre de usuario, contraseña y luego código, o nombre de usuario, código y luego contraseña. Algunas puertas de enlace reordenan las rondas, y un cliente que solo conoce el primer orden se atascará en el segundo.

Segunda comprobación: use el cliente que posee el desafío

El propio OpenConnect implementa toda la conversación, incluida la ronda de desafío. Ejecutarlo directamente es la forma más predecible de confirmar que la cuenta y la puerta de enlace funcionan:

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

El cliente pregunta en el orden en que pregunta la puerta de enlace. El agente de usuario importa porque algunas puertas de enlace adaptan el flujo de inicio de sesión a un cliente conocido, y una cadena genérica puede producir un flujo más corto que nunca pida el código. Ejecútelo una vez en primer plano antes de preparar cualquier servicio en segundo plano.

Si la línea de comandos pregunta correctamente, la cuenta, la puerta de enlace y el segundo factor están bien. El problema restante es el diálogo del complemento, no el servicio de autenticación. Eso aísla el componente que falla sin tocar el servidor. Guarde la salida del comando junto con el registro del incidente.

Si la línea de comandos también omite la petición, deténgase y compruebe la configuración de la puerta de enlace con su responsable. Ningún cliente de escritorio puede responder a un desafío que el servidor nunca envía.

Tercera comprobación: vea si su complemento expone el modo TOTP

Algunas compilaciones de NetworkManager OpenConnect exponen un modo de token y un campo de agente de usuario en la pestaña Identity de la conexión. Ajuste el agente de usuario al valor que espera la puerta de enlace, seleccione la entrada manual de TOTP y guarde la conexión.

Que esos campos existan depende de la versión del complemento y de qué editor de conexiones use el escritorio. Un editor independiente puede mostrar opciones que el panel de GNOME oculta, o al revés. Compruebe la versión del paquete instalado antes de buscar un ajuste oculto.

Si el modo de token existe y la petición sigue sin aparecer, la compilación carece del traspaso de desafío entre el complemento y el diálogo genérico de secretos. Reescribir la contraseña, reinstalar el mismo paquete o limpiar el llavero no creará un campo que la compilación no implemente.

Cuarta comprobación: trate un código generado como un compromiso

Un script puede llamar a oathtool para el código actual y pasar el nombre de usuario, la contraseña y el código a nmcli connection up --ask. La secuencia funciona, pero el secreto compartido acaba almacenado en un lugar legible por cualquiera que pueda abrir el script, y ese lector puede fabricar códigos para siempre. Eso es una extensión permanente de la superficie de credenciales, no una solución del cliente.

Quien lo elija debe restringir el archivo de secretos a root, mantener los valores generados fuera del historial del shell y tratar el script como material de credenciales. Un envoltorio que muestra el código en la terminal tira el segundo factor. Pruebe primero el envoltorio con una cuenta desechable.

El script también debe seguir el orden de peticiones de la puerta de enlace. Si el servidor pide el código antes de la contraseña, una secuencia de entrada fija envía el valor equivocado a la petición equivocada y produce la misma autenticación incompleta. Ensáyelo con una cuenta de prueba antes de conectarlo a una tarea de inicio de sesión.

Confirme la misma puerta de enlace y la misma cuenta

Pruebe cada solución alternativa contra la misma puerta de enlace, la misma cuenta y el mismo grupo de túnel. Una puerta de enlace que también exige un certificado de dispositivo puede rechazar el cliente de línea de comandos por un motivo ajeno a TOTP, y el orden de las peticiones puede diferir del que ensayó.

Anote el cliente, su versión, el agente de usuario y la secuencia de peticiones que funcionó. Ese registro dice a la siguiente persona si el problema es la compilación del complemento, el flujo de la puerta de enlace o la política de la cuenta, sin otra ronda de restablecimientos de contraseña.

Termine reconectando una vez tras un cierre de sesión completo. Un secreto en caché puede hacer que un flujo roto parezca arreglado hasta la sesión siguiente, y es en la segunda conexión donde la petición ausente suele volver.