NetworkManager で OpenConnect の TOTP 入力欄が出ない：四つの確認

ゲートウェイはパスワードを受け入れ、コードを要求しますが、ダイアログにはその入力欄がありません。入力ミスではなく、NetworkManager プラグインが六桁の値を要求せずにシークレット交換を完了しています。以下の四つの確認を順に行ってください。クライアントを変えるのはそのうち一つだけで、残りの項目はゲートウェイ、アカウント、プラグインのビルドを除外します。

一つ目の確認：認証がどこで止まったかを読む

間違ったパスワードはすぐに失敗します。二要素目が欠けている場合は資格情報の段階の後に失敗し、通常は要求が繰り返されるか、ゲートウェイ側でタイムアウトします。タイミングとゲートウェイのログを見れば、どのラウンドが無回答のまま残ったか分かります。

プロファイルに触れる前に接続ログを読んでください。ゲートウェイが認証の未完了やチャレンジの期限切れを報告しているなら、クライアントはコードを送っていません。資格情報が無効だと報告しているなら、問題はパスワードであり、TOTP の設定では直りません。

ゲートウェイが期待する正確な要求順は、ユーザー名、パスワード、その後にコードか、ユーザー名、コード、その後にパスワードです。ラウンドの順序を入れ替えるゲートウェイもあり、最初の順序しか知らないクライアントは二番目で止まります。

二つ目の確認：チャレンジを持つクライアントを使う

OpenConnect 自体がチャレンジのラウンドを含むやり取り全体を実装しており、直接実行することが、アカウントとゲートウェイが機能しているかを確かめる最も予測可能な方法です。

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

クライアントはゲートウェイが要求する順に問い合わせます。ユーザーエージェントが重要なのは、ゲートウェイによってはログインの流れを既知のクライアント向けに調整するためで、汎用的な文字列ではコードを一度も要求しない短い流れになることがあります。バックグラウンドサービスを整える前に、一度だけ前面で実行してください。

コマンドラインが正しく要求するなら、アカウント、ゲートウェイ、二要素目は問題ありません。残る問題はプラグインのダイアログであり、認証サービスではありません。これによりサーバーに触れずに故障した構成要素を切り分けられます。コマンドの出力はインシデント記録と一緒に保管してください。

コマンドラインも要求を飛ばすなら、作業を止めてゲートウェイの設定をその管理者と確認してください。サーバーが決して送らないチャレンジに、デスクトップクライアントは答えられません。

三つ目の確認：プラグインが TOTP モードを公開しているか見る

NetworkManager OpenConnect のビルドによっては、接続の Identity タブにトークンモードとユーザーエージェントの欄があります。ユーザーエージェントをゲートウェイが期待する値に設定し、手動の TOTP 入力を選び、接続を保存してください。

これらの欄があるかどうかは、プラグインのバージョンと、デスクトップがどの接続エディターを使うかによって変わります。単体のエディターでは GNOME パネルが隠している選択肢が見えることも、その逆もあります。隠れた設定を探す前に、インストール済みパッケージのバージョンを確認してください。

トークンモードがあるのに要求が表示されないなら、そのビルドにはプラグインと汎用のシークレットダイアログの間でチャレンジを引き渡す処理がありません。パスワードを打ち直したり、同じパッケージを再インストールしたり、キーリングを消去したりしても、ビルドが実装していない欄は作られません。

四つ目の確認：生成したコードはトレードオフとみなす

スクリプトは現在のコードのために oathtool を呼び、ユーザー名、パスワード、コードを nmcli connection up --ask に渡せます。この手順は動きますが、共有シークレットはスクリプトを開ける者なら誰でも読める場所に保存され、その読み手は永久にコードを作れます。これは資格情報の露出面の恒久的な拡大であり、クライアントの修正ではありません。

これを選ぶ人は、シークレットファイルを root だけに制限し、生成した値をシェル履歴に残さず、スクリプトを資格情報そのものとして扱うべきです。コードを端末に表示するラッパーは二要素目を捨てることになります。まず使い捨てのアカウントでラッパーを試してください。

スクリプトはゲートウェイの要求順にも従う必要があります。サーバーがパスワードより先にコードを求める場合、固定の入力順では誤った値を誤った要求に送り、同じ未完了の認証を生みます。ログイン処理に組み込む前に、テスト用アカウントで練習してください。

同じゲートウェイと同じアカウントを確認する

すべての回避策を、同じゲートウェイ、同じアカウント、同じトンネルグループに対して試してください。端末証明書も要求するゲートウェイは TOTP と無関係な理由でコマンドラインクライアントを拒否することがあり、要求順も練習したものと異なる場合があります。

動作したクライアント、そのバージョン、ユーザーエージェント、要求順を記録してください。その記録があれば、次に担当する人は、もう一度パスワードをリセットしなくても、問題がプラグインのビルド、ゲートウェイの流れ、アカウントの方針のどれかを判断できます。

完全にログアウトした後、一度だけ再接続して終えてください。キャッシュされたシークレットのせいで、壊れた流れが次のセッションまで直ったように見えることがあり、不足した要求はたいてい二度目の接続で戻ってきます。