回答:
あなたの理解は正しいです。他のすべての条件が同じであれば、問題ではありません。しかし、しわがあります。
問題のサーバーでそれらを生成する利点の1つは、転送中にキーが侵害される可能性を最小限に抑えることです。安全なマシンを使用してそれらを生成し、安全な方法（MITM攻撃に耐性がある）を使用してサーバーに移動する限り、それをエスケープします。意図的にコピーを保持することを意図していない限り、生成システムで安全に消去することを忘れないでください。
別のマシンで生成することの1つの利点：通常、これはデスクトップになります。デスクトップマシンのエントロピープールは、キーボードとマウスのケーブル（つまり！）を介して接続されたデスクトップのランダム性の大きなソースがあるため、ほとんどの場合、無人サーバーよりも深くなります。エントロピーが不足すると/dev/urandom、生成ツールの偏執狂性に応じて、キーの生成に時間がかかるか、代わりにPRNG出力が使用され、キーが弱くなる可能性があります。デスクトップマシンにはこの問題がない傾向があります。
後の編集：ここにリンクしている他の場所での議論に従って、2つのポイントが提起されました。まず、あなたが生成することで、途中の家のために行くことができるエントロピーを例にデスクトップ上にdd if=/dev/random bs=1k count=10 of=/tmp/entropy.dat、コピーしていることをリモートサーバに、そして直接またはリモートサーバーのエントロピープールを深めることで、あなたの鍵生成プロセスにそれを供給する。前者を行う方法をまだ見つけていませんが、後者を行うには一般に特権を行使する必要があります-あなたとリモートサーバー間のチャネルが安全でない場合、これはむしろ反対全体のポイントです-また安全ではありません。
第二に、推定可能なmjg59は、ハードウェアセキュリティモジュールの問題を引き起こします。つまり、秘密鍵を配置するデバイス、または秘密鍵を内部に作成するデバイスで、鍵を解放することなく鍵操作を実行します。これは素晴らしい点ですが、この質問の範囲外です。
しかし、スレッドのより一般的な結果-正確な脅威モデルを用意し、適切に応答を選択する必要がある-は良い結果です。私の脅威モデルでは、通信チャネルは安全ですが、エンドポイントはインテリジェントな攻撃を受けています。つまり、エントロピー的に強力なSSLキーペアをローカルで生成して配布します。私のモデルが不正確で、通信が脆弱であることが判明した場合、すべてのSSLキーペアが危険にさらされているとすぐにわかるでしょう。 脅威モデルが異なる場合は、それに応じてプラクティスを調整する必要があります。