同じSSHサーバーキーを持つ複数のデバイスを使用するのはどれほど悪いですか？

FreeBSDとSSHを実行する組み込みデバイスで作業しています。

ご存じのとおり、sshdは最初の起動時にサーバーキーのセットをランダムに生成することを好みます。問題は、読み取り専用のsdカードファイルシステム（交渉不可）で製品を出荷することです。

私が見るように私の2つのオプションは次のとおりです。

• すべてのデバイスで同じsshdサーバーキーを出荷する
• メモリファイルシステムをマウントし、各起動時にサーバーキーを生成します（遅い...）

すべてのデバイスに同じサーバーキーを出荷することは重大なセキュリティ上の問題ですか？これらのアイテムはインターネット上に直接ありません。同じ人が同じネットワーク上に所有する複数のデバイスが存在する場合があります。

ほとんどの場合、デバイスはインターネットに接続されません。

SSHを使用したログインは、通常の操作の一部ではありません。それは主にプログラマーと技術者の便宜のためです。お客様は、SSHを使用してデバイスにログインすることはありません。

複数のハードウェアデバイスで同じサーバーキーを使用することの影響は何ですか？

PS誰かがモノのインターネットタグを作成してください。

編集：私はすべてのサーバー（デバイス）に同じホスト秘密鍵をインストールすることについて話している。ユーザーの公開鍵/秘密鍵に関しては、現在、鍵ベースのログインを使用する予定はありません-パスワードログインになります。繰り返しますが、すべてのサーバー（デバイス）で同じパスワードを使用します。

これはおそらく悪い考えであることを知っています。トレードオフを理解できるように、なぜそれが悪いアイデアなのかを正確に知りたいのですが。

sshホストキーなどのホスト固有のデータをSDカードまたはその他の読み取り専用メディアに保存するのではなく、これをNVRAMに保存することができます。これは、組み込みシステムでの目的です。起動時にキーを保存および取得するには、カスタムスクリプトを実行する必要がありますが、スクリプトはすべてのデバイスでまったく同じになります。

すべてのデバイスで同じキーペアを出荷することの影響は、それらに接続しているクライアントのセキュリティに直接関連しています。これは、（SSHクライアントから）接続先のデバイスを一意に識別する方法がないことを意味します。キーペアが漏洩した場合、MITM攻撃に使用される可能性があります。

一方、各ブートでキーを再生成すると、クライアントでアラートがトリガーされます。

参照用man ssh(1)：

sshこれまでに使用されたすべてのホストのIDを含むデータベースを自動的に維持およびチェックします。ホストキーは~/.ssh/known_hostsユーザーのホームディレクトリに保存されます。さらに、ファイル/etc/ssh/ssh_known_hostsは既知のホストについて自動的にチェックされます。新しいホストはユーザーのファイルに自動的に追加されます。ホストのIDが変更された場合、これsshについて警告し、パスワード認証を無効にして、サーバーのなりすましや中間者攻撃を防ぎます。そうでなければ、暗号化を回避するために使用できます。このStrictHostKeyCheckingオプションを使用して、ホストキーが不明または変更されたマシンへのログインを制御できます。

最初のオプションでは、SSHキーがSDカードで利用できるようです。したがって、どのユーザーでもカードを取り、それらを読み取ることができます。したがって、基本的にあなたの秘密鍵は（ほとんど）公開されています。

これにより、次のような中間者攻撃が可能になります。

1. ユーザーは、デバイスから取得した秘密キーを使用してSSHサーバーをセットアップし、そのIPアドレスを技術者に渡します。
2. 技術者がSSH接続を介してルートパスワードを入力します。
3. これで、ユーザーはすべてのデバイスで有効なルートパスワードを知っています。

ただし、そもそもrootパスワードを使用しないでください。代わりに認証にsshキーを使用してください。LANからのみログオンする場合、共有サーバーキーの影響はごくわずかです。

SSHは前方秘匿性も提供するため、攻撃者はキーを利用するために偽のサーバーをセットアップできる必要があります。トラフィックを受動的にスニッフィングしても、復号化は許可されません。

私はこれを恐怖で読んだ！同じsshホストキーを使用して同じクラスター内で複数のマシンを実行したことがある私は、決してこれを行うことはありません。どのような状況でも、異なる管理者セットを持つマシンがsshホストキーを共有することを許可しないでください。その方法は、セキュリティ不足のために投稿されたときの狂気と悲鳴の恐怖にあります。

実を言うと、1台のデバイスを侵害した人がすべてのデバイスを侵害しています。一度入手すると、悪意のある人が自由に別の人にジャンプし、セキュリティが薄い紙のようにロールバックすることを期待してください。

SSHアクセスはエンドユーザー/顧客によって使用されないことに言及しているため、SSHアクセスをデフォルトでオフにし、デバイスが「デバッグ」モードになったときに一時的にのみ有効にすることができます。

その後、デバイスをハッキングしようとする誰かがリモートでトリガーできないように「デバッグ」モードを保護していると仮定して、すべてのデバイスを同じキーで出荷できます。

または、デバイスが「デバッグ」モードになったときに新しいキーが生成されるため、デバイスの電源を入れるたびにキーを生成するブート時間を無駄にする必要がありません。

制約に基づいた攻撃シナリオの例を次に示します。

デバイスがあれば、たとえばRaspberry Piのように言います。立ち上がってSDカードを1つからヤンクすると、SDカードを自分のコンピューターに貼り付けてsshdキーを見つけ、それを好きな場所にコピーできます。たぶん、私は自分のラズベリーパイとUSBイーサネットカードをつかみます。これで、ターゲットデバイスとそれらが行く先の間にそれを貼り付けて、ssh接続を監視できます。ターゲットデバイスがssh接続を確立しようとしていることがわかったら、次のようにします。

(target) <---> (my evil sshd <--> decrypted traffic <--> ssh) <---> (real server)
                                       |
                                       V
                                    log file

あ、あれは何？パスワードは「猫が好き」ですか？ボーイ、これはあなたがあなたの妻に送った面白いメールです。彼女があなたがあなたの隣の隣人の妻に送ったこの電子メールを読むなら、それはさらに面白いだろうと思う。

可能性は無限です。sshdキーは実サーバーで見つかったものと同一であるため、ターゲットは決して知ることはありません。デバイスを受け取っている施設の物理的なセキュリティによっては、これは非常に簡単な場合があります。これをしないでください。

代わりに、あなたがすでに提案していることを行いますが、それを修正します。イメージを作成する前に、次のように実行します。

ssh-keygen -f some-new-server
cp some-new-server /path/to/the/mounted/image/sshd/key
cp some-new-server.pub /path/to/the/mounted/image/sshd/key.pub

そして今、すべてのサーバーに新しいキーがあります。あなたは本当に、本当にキーのコピーを配布したくないので。正直なところ、少なくとも家の鍵の写真を撮って、自宅の住所でインターネットにアップロードするのと同じくらい悪いことです。