誰もプロファイルに触れていないのに、同じクライアントが起動のたびに秘密鍵のパスフレーズを要求するようになりました。この変化がディストリビューションのアップグレードから数日以内に起きたなら、原因はアップグレードである可能性が高く、OpenSSL 3 がアルゴリズム対応を再編成したため、以前のライブラリが問題なく読めていた鍵が バイト単位も変わらないまま読めなくなることがあります。プロンプトだけを見るとそのうち二つは同じに見えるため、確認は順番どおりに進めてください。

最初の問いは鍵が暗号化されているかどうか、二つ目はこのビルドがそれを復号できるかどうかです。設定の変更は、両方の答えが分かってから初めて意味を持ちます。

鍵が暗号化されているか確認する

ファイル名は何の証明にもならないため、ファイルの先頭行を読み、その後はライブラリに解析させてください。ラベルが ENCRYPTED PRIVATE KEY の PEM ブロックは暗号化された PKCS#8 で、より古い RSA PRIVATE KEY ブロックで Proc-Type: 4,ENCRYPTED を持つものは従来形式であり、どちらもパスフレーズを想定しています。暗号化されていない PRIVATE KEY ブロックはパスフレーズを求めるはずがありません。権限の問題は別のはるかに退屈なエラーを返すため、ファイルを所有するアカウントで解析を実行してください。

鍵が本当に暗号化されておらず、それでもクライアントが要求するなら、暗号技術から目を離し、プロファイルがサービスからまだ読める askpass ファイルを指定していないか確認してください。

このビルドが復号できるか確認する

OpenSSL 3 はアルゴリズム対応をプロバイダーに分割し、古い暗号の一群はデフォルトのプロバイダーではなく legacy プロバイダーに置かれるようになりました。その暗号で暗号化された鍵は有効なままですが、legacy プロバイダーなしで読み込まれたライブラリはそれを復号できません。クライアントによっては要求が繰り返される形で現れ、別のクライアントではパスフレーズの直後に明確な失敗として現れます。

同じ鍵を、まずデフォルトのプロバイダーだけで、次に legacy とデフォルトの両方をコマンドラインで要求して、同じバイナリで二度解析してください。二度目が一度目に失敗した場所で成功すれば、診断はアップグレードの時期ではなく証拠に基づきます。両方が同じように失敗するなら、パスフレーズが違うかファイルが壊れているのであり、どのプロバイダー設定でもどちらも直りません。

利用できる最も狭い修正を確認する

システム全体の変更より、クライアントに限定した変更を優先してください。一部の 2.6 ビルドは、そのデーモンのプロセスに両方のプロバイダーを読み込むプロファイルオプションを受け付けるので、それに頼る前に正確なバージョンのマニュアルでディレクティブを確認してください。代わりにシステムの openssl.cnf を編集するとホスト上のすべての OpenSSL プログラムに影響しますが、狭い設定のほうが鍵を再エンコードした後に戻すのもはるかに簡単です。

プロンプトを消すためにパスフレーズを削除しないでください。それは保護された資格情報を平文ファイルに変え、それが現れるすべてのバックアップ、コピー、サポートバンドルのリスクを静かに変えます。重要な区別は、パスフレーズを必要とする鍵と、このライブラリが復号できない鍵の違いです。

サービスの状況を確認し、それから再エンコードする

鍵を開けられるようになったら、現在のアルゴリズムで再暗号化して依存関係をなくしてください。新しいファイルは現代的な暗号で書き、解析できることを確認し、プロファイルを更新し、古いコピーは接続が成功するまでだけ残してください。パスフレーズは決してコマンドラインに置かず、プロセス一覧から誰でも読めてしまうようにしないでください。古いファイルは、自分のシェルからではなく、新しいファイルがサービスアカウントから接続してから削除してください。

次に、実際にクライアントを動かしているユニットを確認してください。自分のシェルで読める鍵でも、別のアカウントや強化されたホームディレクトリ設定で動くサービスには読めないことがあります。

プロバイダー設定をプロファイルのそばに記録し、二つのコマンドからなる試験も一緒に残してください。後のアップグレードで legacy プロバイダーが外れたら、その試験を再実行し、鍵にまだそれが必要か、プロファイルをこの回避策から外せるかを確認してください。

プロンプトは少なくとも三つの原因を持つ症状であり、そのうち一つだけがパスフレーズの欠落です。

関連記事