OpenVPN サービスが秘密鍵のパスワード入力で止まる：修正手順
サービスには端末がないため、暗号化された鍵には askpass と読み取り可能なファイルが必要です。鍵のパスフレーズとサーバーログインを分け、unit を確認します。
OpenVPN はローカルマシン上で秘密鍵のパスフレーズを尋ねるため、動作するログインファイルがそれに答えることはありません。サービスには入力する端末がなく、起動はハングするか、原因ではなく入力を名指しする journal エントリとともに失敗します。ここには二つの秘密が関わり、unit を再起動する前にそれぞれが読み取り可能な供給源を必要とします。以下の手順は両者を切り分け、実際に各ファイルを開く ID を確認します。
二つのプロンプトを見分ける
鍵のパスフレーズはローカルの秘密鍵を復号し、アカウントの資格情報はサーバーへのセッションを認証します。両者は別の場所から来て、別の時点で失敗し、別のメッセージを出します。混同すると、アカウントが関与していないのにパスワード再設定を探すことになります。どの秘密が欠けているかを示す信頼できる手掛かりは文言だけなので、オプションを変える前にプロンプトの文面を読んでください。
Community OpenVPN 2.x では、askpass は 一行目に鍵のパスフレーズを持つファイルを指し、auth-user-pass は 一行目にユーザー名、次の行にパスワードを持つファイルを指します。どちらのファイルも相手のオプションを満たせません。デスクトップアプリや NetworkManager のプロファイルは両方を独自のシークレットストアに保持することがあり、コマンドラインのクライアントはそれを読みません。パスを書く前に、どのクライアントを設定しているかを確認してください。
両方のオプションを読み取り可能なファイルに向ける
両方の入力が必要なプロファイルは、最終的に 三つのファイル参照 を持ちます。暗号化された鍵、それを解錠するパスフレーズ、ログインの組です。CA や ID 検証には触れずに追加してください。それらはサーバーが誰かを決めるもので、この問題の範囲外です。配備がアカウント資格情報をまったく使わないなら、auth-user-pass を足すと誰も提供できない入力が生まれます。
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth引数なしのオプションはパス付きのオプションと挙動が異なり、サービスではこの違いが重要です。引数なしの askpass は今もコンソールを読み、ユーザー名だけを持つ auth-user-pass ファイルは今もパスワード入力待ちを残します。クライアントがデーモン化すると端末から入力を求められないため、こう設定されたサービスは起動しません。
絶対パスは作業ディレクトリの疑問を消しますが、アクセス権は与えません。次に所有者、モード、通過可能性が来て、三つともプロセスが動くアカウントに対して確認されます。
プロファイルより先に unit の設定を読む
どの設定をインスタンスが読み込むかは、編集していたファイルではなく unit が決めます。そのコマンドラインとすべての drop-in を読み、作業ディレクトリをたどって実際に使われているプロファイルに到達してください。別の .ovpn ファイルに足したパスフレーズ参照は、このインスタンスには何も変えません。
三つの読み取り専用コマンドで大半が分かります。一つ目は unit とすべての drop-in を、二つ目はプロセスを縛る ID とサンドボックス設定を、三つ目は直前の起動が実際に何を訴えたかを表示します。ホストに存在するインスタンス名を使ってください。
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bProtectHome と、プロファイル自身の user、group、chroot オプションに注意してください。ホームディレクトリ配下のファイルはシェルでは読めても、ホームが隠されるとサービス内部では見えません。systemd が起動に使うアカウントは、最後に鍵を開くアカウントと同じとは限りません。
実行時の ID が両方のファイルを開けることを証明する
モードを読むだけでは足りません。経路上のすべてのディレクトリが同じ ID で通過できなければならないからです。経路を構成要素ごとにたどり、次にプロセスが使うアカウントで開くことを試します。root 所有でモード 600 のファイルは、プロセスがまだ root の間だけ機能します。多くのプロファイルが行う権限降下の後では成り立ちません。二つのコマンドが通過と開示を覆います。
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable一つ目のコマンドは各構成要素のモードを表示し、アカウントが通過できない箇所で失敗します。二つ目は唯一重要な問い、実行時の ID がそのファイルを読み取り用に開けるかに答えます。どちらもファイル内容を表示しません。ファイルがパスフレーズを持つ場合、それが要点です。ログインファイルでも同じ試験を繰り返してください。二つはしばしば別の所有者で保存されます。
プロセスが chroot や制限付き namespace を使うなら、同じ試験をそのビューの中から実行してください。そうでなければ答えは誤ったファイルシステムを説明します。隠されたホームディレクトリ配下に置いたパスフレーズは、unit の外では通り中では失敗する試験の典型例です。
最初の起動を確認し、次に再接続を確認する
インスタンスを一度起動し、最後ではなく最初の失敗を読んでください。入力ファイルの欠落、鍵の復号失敗、サーバー側の AUTH_FAILED は三つの別の事象で、修理も三つに分かれます。権限警告を直しても、鍵が解錠されたかは何も証明しません。
journal の行が三つのどれかを教えます。修理はどの入力が失敗したかから決まります。
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
次に 実際に必要なライフサイクル を試します。起動時の開始とサポートされる再接続であり、シェルからの手動起動だけではありません。auth-nocache では入力は最初の使用後に捨てられるため、後の再接続にも読み取り可能な供給源が要ります。デスクトップのログインで解錠されるキーリングは、誰かがログインする前に起動したサービスには使えません。手動試験は通り再起動で失敗するのは、たいていこれが理由です。最初の起動が成功し、後の再接続が失敗するなら、権限を再び変える前に再接続イベントの journal を読んでください。
パスフレーズを鍵の隣に置くと暗号化の利点が減るので、そのファイルとバックアップを制限してください。鍵のパスフレーズを外すのは、欠けた入力の修理ではなく、資格情報に関する別の判断です。人手の承認や対話型 MFA に依存する配備には、対応するエージェントや管理連携が必要です。恒久的に保存したワンタイムコードは同等の代替ではありません。