OpenConnect の --key-password は VPN アカウントのパスワードですか?
OpenConnect の --key-password はローカルの秘密鍵を解除します。アカウントのパスワードはゲートウェイに対して認証するもので、一方が他方の代わりになることはありません。
オプション名を文字どおりに読んでください。これは鍵の名前であり、解除されるファイルが認証されるアカウントと取り違えられたときに混乱が始まります。そのオプションにアカウントのパスワードを貼り付けると、クライアントはそれで鍵ファイルを開こうとし、VPN ログインとは何の関係もない理由で失敗します。
紛らわしいのは、一つの接続が両方の秘密を正当に必要とする場合があることです。クライアント証明書認証には暗号化された鍵が必要なことがあり、証明書が受け入れられた後も同じゲートウェイがユーザー認証のやり取りを行うことがあります。どちらの秘密も他方の段階を満たすことはなく、片方の失敗は外から見ると他方の失敗とよく似ています。
二つの秘密、二つの異なる役割
役割をファイルへのアクセスとネットワークへの入場という対比で読んでください。鍵のパスワードは --sslkey で指定された PEM 秘密鍵を復号し、TLS クライアント証明書を提示できるようにします。その復号はクライアントプロセスの中でローカルに行われ、パスフレーズ自体がゲートウェイへ渡ることはありません。ゲートウェイが見るのは証明書と、鍵で作られた署名です。OpenConnect のマニュアルは --key-password を --certificate と --sslkey の隣に置いており、TPM に保持した鍵を使えるビルドでは同じオプションが代わりにストレージのルート鍵のパスワードを担います。
アカウントのパスワードは種類が異なります。これは認証のやり取りに入り、ユーザー名とパスワードのフォーム、トークン、SAML の往復、あるいはゲートウェイが告知する何らかの組み合わせを取ります。証明書が唯一の要素である場合にまったく要求しない配備もあれば証明書の後でも要求する配備もありますが、それは証明書がデバイスを証明し、アカウントが人を証明するからです。
両者を混同すると誤解を招くエラーが生じます。ログインを拒否するゲートウェイは通常は認証失敗を報告しますが、誤った鍵のパスフレーズは通常はもっと早く、TLS 層が鍵ファイルを読めない段階で失敗します。これらは別の段階で対処法も異なりますが、名前が似ているため人は入れ替えてしまい、間違ったログを追いかけるので、設定を変える前にどのプロンプトが出たかを記録してください。プロンプトの文言が最も安価な診断手段です。
鍵のパスワードが本当に必要なとき
このオプションは、解除すべき暗号化された鍵がある場合にのみ意味を持ちます。ユーザー名とパスワードでクライアント証明書なしに接続するなら、--key-password は作用する対象がなく、含めても何も変わりません。--certificate と --sslkey で接続するなら、パスフレーズを求めるかどうかは鍵ファイル自身の形式が決めます。
一つのコマンドに二つの秘密を置くことは、管理された環境ではよくあり、暗号化された鍵の中のデバイス証明書に加えてユーザーごとのサインインを伴います。正しい順序は、クライアントに鍵のパスフレーズをローカルで尋ねさせ、証明書のハンドシェイクを完了し、その後にゲートウェイのアカウント用プロンプトを別に扱うことです。一つの使い回しスクリプトで両方を事前に入れようとするのが、混乱が始まる典型的な地点です。
有用な診断は、失敗がいつ起きるかを見ることです。ネットワーク認証が始まる前にクライアントが止まるなら、鍵ファイル、その形式、またはパスフレーズを疑ってください。TLS セッションが確立した後にゲートウェイがユーザーを拒否するなら、鍵は役目を果たしており、問題はアカウントのやり取りにあります。
二つの秘密をシェル履歴に残さない
コマンドライン引数はプロセステーブルを通じて他のローカルユーザーから読め、シェル履歴、スクリプト、サポートの記録に残りがちです。OpenConnect は --passwd-on-stdin で標準入力からアカウントのパスワードを読め、鍵のパスフレーズは引数ではなく対話的なプロンプトやエージェントから取得できます。どちらの仕組みも単独で秘密を安全にするわけではありませんが、どちらも最も露出した場所から遠ざけます。
ファイルにも同じ注意が必要です。パスフレーズを一時ファイルに書き出すスクリプトは、制限の厳しい権限で作成し、終了時に削除し、全員が読めるディレクトリを避けるべきです。セッション後に一時ディレクトリに残ったパスフレーズは、作り忘れた複製です。環境変数は子プロセスに見え、デバッグツールに出力されがちなので、引数に対する無料の改良ではありません。
診断出力は静かな漏えいです。詳細度を上げたクライアントログはリクエスト本文やオプション値を表示することがあり、コピーした端末の記録はチケットに貼り付けやすいので、共有する前に出力を読んでください。
デスクトップのボタンが無反応なのは別の障害です
スピナーを表示した後に何も起こらないデスクトップの VPN エントリは、通常は認証の問題ではまったくありません。ボタンはネットワークマネージャー、ベンダーのアプレット、またはあなたの代わりに OpenConnect を起動するプラグインのものであり、コンポーネントの欠落や読めないプロファイルがまさにその症状を生みます。ボタンがどのプロセスを起動するのかを突き止め、認証情報に触れる前にそのエラーを読んでください。
GUI が接続を拒否したときに、証明書の検証を緩めたりチェックを無効にしたりしたくなります。それはクライアント統合の不具合をセキュリティの後退に変えるだけで、起動の問題はほとんど直りません。サーバー検証はそのままにし、プロファイルが意図したゲートウェイを指していることを確認し、GUI が期待するヘルパーが実際にインストールされているかを確かめてください。
短いチェックリストがケースを分けます。パケットが出る前のローカルな失敗は鍵かクライアントのインストールを示します。TLS セッションの後のゲートウェイによる拒否はアカウントのやり取りを示します。クライアントをまったく起動しないボタンはデスクトップ統合を示します。三つの異なる障害であり、その一つは間違った欄に貼り付けようとしていたパスワードです。