web-dev-qa-db-ja.com

同じSSHサーバーキーを持つ複数のデバイスがあることはどのくらい悪いですか？

FreeBSDとSSHを実行する組み込みデバイスに取り組んでいます。

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

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

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

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

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

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

複数のハードウェアデバイスで同じサーバーキーを使用すると、どのような影響がありますか？

PS誰かがモノのインターネットタグを作成してくれませんか？

[〜＃〜] edit [〜＃〜]：すべてのサーバー（デバイス）に同じホスト秘密鍵をインストールすることについて話している。ユーザーの公開鍵/秘密鍵に関する限り、現在のところ、鍵ベースのログインを使用する計画はありません。パスワードログインです。ここでも、すべてのサーバー（デバイス）で同じパスワードを使用します。

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

sshfreebsdembeddedinternet-of-things
22
NXT

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

27
Michael Hampton

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

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

参考までに、 man ssh(1) から：

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

12
dawud

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

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

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

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

SSHは転送の機密性も提供するため、攻撃者は偽のサーバーをセットアップして鍵を利用できるようにする必要があります。トラフィックを受動的にスニッフィングすると、復号化できなくなります。

5
jpa

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

見よ、私はあなたに本当のことを言う、1つのデバイスを危険にさらす彼はそれらすべてを危険にさらす。いったん入手したら、悪意のある人々が自由に次々とジャンプすることを期待し、セキュリティは薄い紙のようにロールバックします。

2
joshudson

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

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

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

1
Edders

ここにあなたが持っている制約に基づくサンプル攻撃シナリオがあります：

デバイスがそうである場合、たとえばRaspberry Piのデバイスと言います。私が歩いてSDカードを1つから取り出したら、SDカードを自分のコンピューターに貼り付け、sshdキーを見つけて、好きな場所にコピーできます。多分私は自分のRaspberry PiとUSBイーサネットカードを手に入れます。これで、ターゲットデバイスとどこに行くのかを把握し、ssh接続を監視できます。ターゲットデバイスがssh接続を確立しようとしていることを確認したら、次のようにします。

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

あ、あれ何？パスワードは「猫が好き」ですか？男の子、これはあなたがあなたの妻に送った興味深いメールです。あなたが隣人の隣人の妻に送ったこのメールを彼女が読んだらもっとおもしろいでしょう。

可能性はendlessです。また、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

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

1
Wayne Werner