Linux は VPN パスワードをどこに保存すべきか?プロファイルではない
NetworkManager のシークレットフラグは、パスワードをプロファイル、キーリングエージェント、あるいは誰も保持しないかを決める。答えは接続がいつ始まるかで変わる。
VPN パスワードは、接続プロファイルの中、デスクトップが解錠するキーリングの中、あるいは文字通りどこにもない、のいずれかに存在しなければならない。NetworkManager はその選択をシークレットフラグと呼び、間違ったものを選ぶと、ログイン後は動くのにサービスとしては失敗する。フラグは設定一行であり、三つの結果のどれになるかを決める。
三つのフラグでほぼすべてのケースをまかない、判断は接続がいつ始まるかによる。
三つのシークレットフラグ、三つの挙動
フラグ 0 は、シークレットが接続とともに保存されることを意味し、プロファイルを保持するどのストアに置かれても同じだ。フラグ 1 はエージェント所有にし、シークレットはデスクトップのキーリングのようなシークレットエージェントから供給され、NetworkManager は有効化のときにそれを要求する。フラグ 2 は未保存であり、シークレットは決して書き込まれず、毎回与えなければならない。フラグ 4 はシークレットを不要として扱い、本当に何も必要としない接続向けである。
| Flag | Where it lives | Works unattended |
|---|---|---|
| 0 saved | Connection profile | Yes, if the store is readable |
| 1 agent-owned | Secret agent or keyring | Only if that agent is available |
| 2 not-saved | Nowhere | No |
フラグは接続ごとではなくシークレットごとに設定する。一つの接続に、エージェント所有のパスワードと保存済みの秘密鍵パスフレーズを併存させられる。
接続がいつ始まるかで決める
ログイン済みのユーザーが接続を始めるならエージェント所有が妥当な既定であり、キーリングはログインで解錠され、シークレットがファイルに残ることはなく、誰かがログインする前に接続を立ち上げる必要があるならエージェント所有は誤った選択だ。なぜなら 解錠すべきセッションのキーリングが存在しないからだ。
判断はこれだけである。残りはすべてその変種だ。
ログイン前のサービスには、システム規模のストアか保護された鍵ファイルが対応するパターンであり、ファイルの権限が保護になる。起動時に走るシェルスクリプトにパスワードを貼り付けて解決してはいけない。
キーリングが与えるもの、与えないもの
キーリングはシークレットを接続プロファイルの外に保ち、ユーザーセッションに結びつける。セッションのないサービスにシークレットを使えるようにはせず、回線上で何も暗号化しない。これは人がよく混同する別々の性質だ。実際に得られるのは、プロファイルファイルが漏れたときの被害範囲が小さくなることである。
プロファイルが参照する秘密鍵には、パスワードがどこに存在するかとは無関係に、独自の権限が要る。
シークレットを吐き出さない診断
接続名、UUID、フラグで通常は障害を説明できる。 nmcli connection show プロファイルを一覧し、シークレットフラグはパスワードがどこから来るはずだったかを教える。
次のものを避けよ --show-secrets チケットやチャットでの使用を。一度貼られれば、それは記録に残る資格情報である。
保存は失効ではない
一つのキーリングからシークレットを消しても、遠隔の運用者がすでに受け入れた資格情報は無効にならない。アカウントの失効はサーバー側の操作であり、ローカル保存は別の所有者を持つ別の関心事だ。
どちらもインシデントの前に決めるべきで、最中ではない。対話的なユーザー接続とログイン前のサービスは別の答えを必要とし、共有のシェルスクリプトはどちらでもない。NetworkManager の シークレットフラグの文書 は値をすべて列挙している。