SSH公開鍵認証-常にユーザーに独自の鍵ペアを生成するように要求しますか？
今日はパートナーと協力していて、scpを使用してサーバーにファイルをアップロードする必要がありました。サーバーのSSH構成でパスワードをオフにしているので、公開鍵認証を使用するようにしました。サーバー上でそれらの鍵ペアを生成し、秘密鍵を与えて、適切なauthorized_keysファイルに公開鍵を配置しました。
彼らが仕事を設定する際に多くの問題を抱えた後、彼らはついに彼らの側でより経験豊富なシステム管理者を巻き込み、彼はこの方法でキー生成を処理したことで私を叱った。彼は、私のシステムで生成された秘密鍵を提供することで、同じサーバーで生成された他の鍵に対してブルートフォース攻撃を実行できるようにしたと述べました。
私も彼に尋ねました「サーバーにアカウントがあり、パスワードでログインできるが、何かを自動化し、そのシステムでキーペアを生成した場合、それは私に攻撃ベクトルを与えます他のユーザーのキーをブルートフォースするためですか？ "そして彼ははいと言いました。
私はこれを聞いたことがありません、それは本当ですか？誰かが私にこの攻撃の議論を指摘できますか？
ええと...いいえ、システム上で適切なランダム性が生成されるため、ほとんどの状況では正しくありません。ただし、理論的には、開発者（Linuxの場合はカーネル開発者）がランダム性のソースが「良好」であることを保証しない場合、サーバーがバイアスのあるランダム性を生成する可能性があります。ランダム性に偏りがある場合、攻撃はサーバーキーに対してブルートフォースよりも速い時間で実行される可能性があります。ただし、これは実際の問題よりも理論上の問題です。実際には、RNG（Random Number Generator）の弱点は、暗号化ソフトウェアへのサイドチャネル攻撃やサーバーへのアクセスの取得よりもはるかに少ない攻撃です。別の方法。
だから、短編小説、いや、彼は間違っている。基本的な暗号化の基盤（DSAキーはデフォルトで生成されますか？RSA？）を除いて、1つのsshキーには、同じシステムで生成された他のsshキーに関する情報は含まれていません。
秘密鍵の要点は、それがユーザーに対して秘密であり、ユーザーだけが知っているということです。ユーザーとして、他の人が私の秘密鍵を生成することを望まない。それは、他の誰かが私の秘密鍵にアクセスできることを意味し、したがって、その鍵の公開半分が有効な資格情報として設定されているシステムで私である場合に行動する機会がある。
あなたのPoVからあなたにももっと責任があります。不適切な公開鍵を場所にインストールできないようにシステムを安全に保つ必要があるだけでなく、生成した秘密鍵をライフサイクル全体を通して安全に保つ責任があります。特定のキーペアを認証として使用して望ましくないアクションが実行され、ユーザーが他の誰かがキーのコピーを持っている（または持っていた）ことを知っている場合、またはキーが完全に安全ではない方法で転送された場合、ユーザーは向きを変えることができます（正しくまたは間違って）そして、彼らは彼らのコピーを完全に安全に保っていたので、あなたの側または輸送中に侵害されたのはあなたのコピーでなければならないと言います。これは単なるお尻のカバーのように聞こえるかもしれませんが、これは次の理由によるものです。PoVとユーザーの両方から、適切にマークされたものの責任者を確認しています。
したがって、専門家によって提起された懸念が有効であるかどうか（私の理解では、そのような攻撃は理論的には可能ですが、私の知る限りでは遠い次世代で実際に実装できるか、新しい深刻な穴がない限り少数です数学または一般的な実装で見つかります（これはややありそうにありません））、ユーザーの帽子をかぶっているときと管理者の帽子をかぶっているときの両方で、ユーザーが自分の秘密鍵と管理者を完全に制御できるようにしますもちろん）それらの近くでは許可されません。
上記に同意できない場合でも、キー転送の問題は簡単ではありません。秘密キーが目的のユーザーに表示され、のみ目的のユーザーに表示され、表示されていないことを100％確認するにはどうすればよいですか。安全性に欠ける方法で（意図的または偶発的に）保存された（電子メールの受信トレイまたは一時ファイルに残された結果、メールから切り離されて暗号化されなかったなど）。ユーザーに認証を要求する安全な転送方法を使用する場合、thatシステムの認証の詳細をユーザーに安全に取得するにはどうすればよいですか？もちろん、ほとんどの用途でキー転送を「十分に安全」にする方法はありますが（「十分」は、キーがユーザーにアクセスできるものによって大きく異なります）、ユーザーがキーを生成して公開部分を配布する場合は、その意味で心配するキー配布の問題はまったくありません（ユーザーがプライベートパーツを安全に保つことを心配する必要がありますが、本当に不注意なユーザーがそこで安全でなくなるのを防ぐことはできないので、それは問題ですあなたが何をしても）。
最後の注意：秘密鍵がすべて同じ場所で生成された場合に問題になる可能性があるのは、昨年のDebian/LennyのOpenSSLパッケージで見つかった問題のように、後でその場所で鍵生成の設定が不適切であることが判明した場合です。 。このような場合、多くの秘密鍵を取り消して再生成する作業が必要になります。これは、この問題に関する外部の専門家の懸念の一部である可能性があります。
これはBSだと確信しています。プライベートはランダムに生成する必要があります。したがって、このランダム性に偏りがない限り、異なる秘密鍵間の接続はあり得ません。
ランダムシードは通常、 / dev/random から取得されます。何らかの方法でssh-keygenを変更して別のランダムシードを使用しない限り（使用したかどうかはわかります）、誰かがそのキーを叩いて新しいキーを生成してクラックする方法を理解できる可能性はほとんどありません。システム。