NetworkManager に保存済み VPN パスワードを表示させない
毎回尋ねる、キーリングに渡す、root 専用のファイルに置く。どの選択も露出が異なり、パスワードのフラグもそれに合わせる必要があります。
NetworkManager は VPN パスワードを保持できるため、誰も入力しなくても接続が立ち上がり、またその値をエディターまたは nmcli --show-secrets から再表示できます。所有者モデルは三つあり、表示の挙動はどれを選んだかの症状にすぎません。まずモデルを選び、次に対応するフラグを設定し、次の担当者を混乱させるプレースホルダーでフィールドを隠すのは避けてください。
三つの所有者モデル
一つ目のモデルは毎回尋ねます。何も保存されず、秘密は有効化の間だけ存在し、接続を開始する人はパスワードを知っている必要があります。最も不便な選択肢であり、最も弁明しやすい選択肢です。
二つ目は秘密をユーザー所有のキーリングに渡し、エージェントはセッション開始時にロックを解除して要求に応じて値を提供します。これにより接続ファイルの外に保てますが、接続はそのユーザーのセッションに結び付きます。そこから、エージェントが動作していることと、ロックが解除されていることという二つの条件が導かれます。
三つ目はシステム接続用の保護された資格情報を保存し、再起動を越えて存続して誰かがログインする前から機能します。その代わり、値は暗号化ではなくファイル権限で守られてディスク上に置かれます。
どのモデルも適切な文脈では合理的です。誤りはそれらを混ぜることで、その結果ノート PC では秘密が二か所に残り、どちらが正式なのか明確な答えがなくなります。プロファイルがどのモデルを使うかを書き留めてください。チームの手順書に一行あれば、次の担当者が四つ目の確認場所を発明せずに済みます。
変更する前に現在の状態を読む
接続を管理するユーザーとして、プロファイルと秘密の状態を見ます。二つ目のコマンドが、値が実際に読めるかどうかを教えてくれます。
nmcli connection show "Office VPN"
nmcli --show-secrets connection show "Office VPN"
sudo stat -c '%U %a %n' /etc/NetworkManager/system-connections/*.nmconnectionそのディレクトリの鍵ファイルは通常 root 所有でモード 600 で、一般ユーザーは締め出されますが root は締め出されません。同じマシンを共有する場合や、バックアップが root として実行される場合に重要です。
ファイル権限は境界であり、暗号化ではありません。root としてファイルを読める人は、パスワードを平文で持っています。監視のないサーバーには許容できる取引で、共有のワークステーションには不適切です。一度書き留めておけば、値が保護されているかどうかをめぐる長い議論を避けられます。
各フラグ値の動作
VPN の秘密には flags というプロパティがあり、値は数字だけでは直感的に分かりません。
| Value | Meaning | Practical effect |
|---|---|---|
| 0 | No special flag | Secret is typically saved with the connection |
| 1 | Agent-owned | A keyring or secret agent supplies it |
| 2 | Not saved | Prompted at each activation |
| 4 | Not required | Connection proceeds without asking |
実際の挙動はプラグインとエージェントの稼働状況にも依存するため、表を契約とみなし、観察された挙動を検証対象と考えてください。あるデスクトップで動く値が、セッションのないサーバーでは別の挙動をとることがあります。混乱するチケットの多くはこの差に潜んでいます。
行を削除して期待するのではなく、プロパティを明示的に設定してください。フラグがないことはポリシーではなく、次のパッケージ更新が意図しない値で埋める可能性があります。
モデルを接続の開始時期に合わせる
接続がユーザーのログイン中にしか開始しないなら、エージェント所有がよく合い、秘密をファイルの外に保てます。起動時、セッションが存在する前に開始するなら、エージェントは役に立ちません。
ほとんどのマシンではこれが判断のすべてです。これは、接続が対話的には動作するのに再起動後に失敗するという紛らわしい報告の一群も説明します。フラグは変わっておらず、文脈が変わったのです。
監視のない場合は、root 所有の制限されたファイルか承認済みの資格情報ソースが実用的な答えです。そのプロファイルが将来エクスポートされたり別のマシンにコピーされたりするなら、接続プロファイルの外に置いてください。
値がすでに見えていたなら、交換する
フラグを変えてもパスワード自体はそのままです。スクリーンショット、シェル履歴、サポートに送ったバンドル、他のユーザーが開けたファイルに現れた値は、漏えいしたとみなすべきです。
サーバー側で変更し、次にクライアントを直し、古い値で認証したセッションをすべて終了させます。ローカルの接続を削除しても相手側では何も取り消されませんが、ここが見落とされがちな点です。
その後、パスワードをコマンドラインに置くのはやめましょう。シェル履歴に残りプロセス一覧に現れることもあるため、代わりに対話的なプロンプトかエージェントを使ってください。
再接続して確認する
秘密を表示したコマンドを繰り返し、フィールドがもう出力されないことを確認してから、切断して再接続し、接続が自動で開始するなら再起動してください。興味深い障害はセッションの文脈が変わったときにだけ現れます。
それでも秘密が表示されるなら、別のプロファイルか別のエージェントが提供しています。ファイルを削除するのではなく、症状が移るまでアクティブな接続とキーリングを調べてください。