Pedido TOTP do OpenConnect ausente no NetworkManager: quatro verificações

O gateway aceita a senha, pede um código e a caixa de diálogo não oferece nenhum campo para ele. Nada foi digitado errado: o plug-in do NetworkManager concluiu a troca do segredo sem solicitar o valor de seis dígitos. Faça as quatro verificações abaixo em ordem, porque apenas uma delas altera o cliente. O resto da lista descarta o gateway, a conta e a compilação do plug-in.

Primeira verificação: leia onde a autenticação parou

Uma senha errada falha imediatamente. Um segundo fator ausente falha após a etapa das credenciais, normalmente com um pedido repetido ou um tempo limite do lado do gateway. O momento e o registro do gateway indicam qual rodada ficou sem resposta.

Leia o registro da conexão antes de tocar no perfil. Se o gateway relatar uma autenticação incompleta ou um desafio expirado, o cliente nunca enviou o código. Se relatar credenciais inválidas, o problema é a senha e nenhuma configuração de TOTP o corrigirá.

Anote a sequência exata de pedidos que o gateway espera: nome de usuário, senha e depois código, ou nome de usuário, código e depois senha. Alguns gateways reordenam as rodadas, e um cliente que só conhece a primeira ordem vai travar na segunda.

Segunda verificação: use o cliente que possui o desafio

O próprio OpenConnect implementa toda a conversa, incluindo a rodada do desafio. Executá-lo diretamente é a forma mais previsível de confirmar que a conta e o gateway funcionam:

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

O cliente pergunta na ordem em que o gateway pergunta. O agente de usuário importa porque alguns gateways adaptam o fluxo de login a um cliente conhecido, e uma cadeia genérica pode produzir um fluxo mais curto que nunca pede o código. Execute-o uma vez em primeiro plano antes de preparar qualquer serviço em segundo plano.

Se a linha de comando perguntar corretamente, a conta, o gateway e o segundo fator estão bem. O problema restante é a caixa de diálogo do plug-in, não o serviço de autenticação. Isso isola o componente com falha sem tocar no servidor. Guarde a saída do comando com o registro do incidente.

Se a linha de comando também ignorar o pedido, pare e verifique a configuração do gateway com o responsável. Nenhum cliente de desktop pode responder a um desafio que o servidor nunca envia.

Terceira verificação: veja se o seu plug-in expõe o modo TOTP

Algumas compilações do NetworkManager OpenConnect expõem um modo de token e um campo de agente de usuário na aba Identity da conexão. Defina o agente de usuário no valor que o gateway espera, selecione a entrada manual de TOTP e guarde a conexão.

A existência desses campos depende da versão do plug-in e de qual editor de conexões o desktop usa. Um editor autônomo pode mostrar opções que o painel do GNOME oculta, ou o contrário. Verifique a versão do pacote instalado antes de procurar uma configuração escondida.

Se o modo de token existir e o pedido continuar a não aparecer, a compilação não tem a passagem do desafio entre o plug-in e a caixa de diálogo genérica de segredos. Reescrever a senha, reinstalar o mesmo pacote ou limpar o chaveiro não criará um campo que a compilação não implementa.

Quarta verificação: trate um código gerado como um compromisso

Um script pode chamar oathtool para o código atual e passar o nome de usuário, a senha e o código para nmcli connection up --ask. A sequência funciona, mas o segredo compartilhado acaba guardado num local legível por qualquer um que consiga abrir o script, e esse leitor pode fabricar códigos para sempre. É uma extensão permanente da superfície de credenciais, não uma correção do cliente.

Quem o escolher deve restringir o arquivo de segredo a root, manter os valores gerados fora do histórico da shell e tratar o script como material de credenciais. Um wrapper que mostra o código no terminal descarta o segundo fator. Teste primeiro o wrapper com uma conta descartável.

O script também deve seguir a ordem de pedidos do gateway. Se o servidor pedir o código antes da senha, uma sequência de entrada fixa envia o valor errado para o pedido errado e produz a mesma autenticação incompleta. Treine com uma conta de teste antes de o ligar a uma tarefa de login.

Confirme o mesmo gateway e a mesma conta

Teste cada solução alternativa contra o mesmo gateway, a mesma conta e o mesmo grupo de túnel. Um gateway que também exige um certificado de dispositivo pode rejeitar o cliente de linha de comando por um motivo alheio ao TOTP, e a ordem dos pedidos pode diferir da treinada.

Anote o cliente, a versão, o agente de usuário e a sequência de pedidos que funcionou. Esse registro diz à pessoa seguinte se o problema é a compilação do plug-in, o fluxo do gateway ou a política da conta, sem mais uma rodada de reposições de senha.

Termine reconectando uma vez após um encerramento de sessão completo. Um segredo em cache pode fazer um fluxo quebrado parecer corrigido até à sessão seguinte, e é na segunda ligação que o pedido ausente costuma voltar.