複数のコンピューター/サービス間で秘密鍵ファイルを共有しても大丈夫ですか?


110

したがって、SSHなどを使用して公開キー/秘密キーを使用する方法を知っています。しかし、それらを使用/再利用する最良の方法は何ですか?いつまでも安全な場所に保管すべきですか?つまり、GitHubにアクセスするにはキーのペアが必要でした。ペアをゼロから作成し、それをしばらく使用してGitHubにアクセスしました。その後、HDDをフォーマットし、そのペアを失いました。大したことですが、新しいペアを作成し、新しいペアを使用するようにGitHubを構成しました。それとも私が失いたくないものですか?

会社のシステムにアクセスするには、公開キー/秘密キーのペアも必要でした。管理者が公開鍵を要求し、新しいペアを生成して彼に渡しました。一般に、異なるシステムにアクセスするための新しいペアを作成する方が良いでしょうか、それとも1つのペアを持ち、それを異なるシステムにアクセスするために再利用する方が良いでしょうか?同様に、2つの異なるペアを作成し、1つを使用して自宅から会社のシステムにアクセスし、もう1つを職場からシステムにアクセスする方が良いでしょうか?


これは質問に対する直接的な回答ではありませんが、各キーにもパスフレーズを付けることをお勧めします。理想的には、キーごとにパスフレーズを分離します(パスワードマネージャーを使用します)。その理由は次のとおりです:秘密キーが侵害された場合(ラップトップが盗まれ、コンピューターがハッキングされた場合)、キーがブルートフォースされる可能性があり、それを所有するすべてのマシンで公開キーを置き換えることができます、攻撃者ができる前に。出典:help.ubuntu.com/community/SSH/OpenSSH/…–
Xandor Schiefer

回答:


86

必ず、オリジンごとに個別の秘密鍵を用意する必要があります。基本的に、これは一般に各秘密鍵の単一のコピーがあることを意味します(バックアップはカウントしません)。基本的に、一方に侵入すると他方にアクセスできるような状況(たとえば、お互いのマシンにいる場合)で、密接に関連するマシンから同じ秘密鍵を使用しても構いませんshosts.equiv。異なる領域(たとえば、自宅と職場)のマシンで同じ秘密キーを使用しないでください。2人のユーザー間で秘密キーを共有したり、ラップトップと他のマシン間で秘密キーを共有したりしないでください。

ほとんどの場合、宛先ごとに異なる秘密鍵を持つことの意味はわかりません。秘密鍵が危険にさらされた場合、同じディレクトリに保存されている他のすべての秘密鍵も確実に危険にさらされるため、セキュリティ上のメリットがないため、複雑さが増します。

これらの原則に従う場合、各キーペアは1つの(マシン、ユーザー)ペアを識別するため、認証管理が容易になります。

発信元ごとに1つの秘密キーを使用するという一般的な規則には、2つの例外が考えられます。

  • 特定のマシン上の特定のコマンド(自動バックアップまたは通知メカニズムなど)のみにアクセスできるパスワードなしのキーがある場合、そのキーは一般的なシェルアクセスキーとは異なる必要があります。
  • 一部のマシンが断続的に接続されている場合、新しい秘密キーの展開が完了するまで、古い秘密キーと新しい秘密キーが存在する可能性があります。

5
これが、私がいつもキーペアを使用してきた方法です。GitHubがセットアップ手順で新しいキーペアを生成することを主張していた理由がわかりませんでした。私はそれを無視し、標準のキーペアを使用しました。彼らは保守的だと思います。
toolbear74

では、「異なるレルムのマシンで同じ秘密鍵を使用しないでください」と言いますが、DNSが場所に応じて特定のホスト名をいずれかのマシンに解決したらどうなるでしょうか。秘密キーを共有しないと、sshが同じホスト名に2つの別々のキーを持つことで混乱するため、そのホスト名にsshまたはrsyncしようとすると警告または失敗します。
マイケル

@Michael あなたが説明するシナリオでユーザーキーにどのような問題があるのか​​理解できません。これがこのスレッドの目的です。SSHはホストキーについて混乱しますが、ユーザーとして表示されるのはホストのプライベートキーではなくホストのパブリックキーであり、ホストのプライベートキーを共有することは危険です。ホストが完全に同等(冗長性そのうちの1つが失敗した場合)、おそらくそうではありません。
ジル

ああ、わかった。両者の間に明確な区別はあまりないようで、どちらについて話しているかを知っていることが前提になっています。
マイケル

1
@JSBachレルムごとに個別のキーを使用すると、より詳細なアクセス許可を定義できます(セキュリティの低いレルムAに格納されたキーはAのマシン間で使用できますが、Bにログインするにはより強力な認証要素が必要です)。個別に(レルムAが侵害されましたが、BからCにログインできます)。SSOは、最もセキュリティの高いシステムにログインして、他の場所からログインできる場合です。ユーザーごとに複数のキーを使用することでどのようなリスクが生じるかわかりません。これは、情報セキュリティのトピックになります。
ジル

4

最善の方法はわかりませんが、自分のやり方はわかります。

システム管理者として、異なるキーを使用して各サーバー/サービスにルートとしてアクセスします。このように、キーが失われたり侵害されたりした場合、リスクを1つのサーバーに限定し、すべてのサービスを新しいキーで更新する必要はありません。

ユーザーといえば、ユーザーごとに異なるキーを使用します。そのキーを使用して、ユーザーは非特権ユーザーとして必要なサービスにアクセスできます。このようにして、各ユーザーに単一のサービスへのアクセスを簡単に許可または取り消すことができます。ユーザーがキーを紛失した場合、すべてのサービスからキーを削除し、不正アクセスのリスクを制限できます。


+1新しいキー使用ポリシーについて上司と話をします;-)サーバー/サービスごとに、ネットワークごとよりもさらに安全に聞こえる
Diskilla

1

秘密鍵は、パスフレーズを付ける限りどこでも使用できると考えています。つまり、秘密鍵を少数のマシンで共有したい場合は、ラップトップ1、2、デスクトップ1、2で十分です。

私の経験から、メインマシンはデスクトップであり、強力なプロセッサを使用してほとんどの仕事をしていますが、モバイルでラップトップを使用したり、データセンターなどでトラブルシューティングを行う必要があるため、どのホストにもログインできます私の公開鍵がある場所


1
ここでベストアンサーをお読みください。あなたは間違っています。あなたはそのようにできないわけではありませんが、そうすべきではありません。
PhilT

2
すべてのダウン投票の理由がわかりません。大学のネットワーク(たとえば)には、ネットワーク化されたホームディレクトリが含まれていることが多いため、ユーザーは、与えられたラップトップでも同じ秘密キーをどこでも使用します。インターネット上で暗号化されていない状態でコピーしない限り、リスクを理解していれば問題ないと思います。この方法でも、Bloodyの方が便利です。別のマシンにログインしたからといって、2,000か所に公開鍵を追加する必要はありません。
Asfand Qazi

この回答の担当者を失うべきではないため、賛成です。個人的な好みであり、明らかにサービスとマシンごとに別々のキーを使用すると最終的にはより多くの制御が可能になりますが、ユースケースによっては時間の浪費にすぎないこともあります。
ダニエルデューハースト

0

私の会社では、ユーザー固有のこれらのキーを使用しています。それはケース2を意味します。ユーザーは自分のキーを持ち、このキーは会社のシステムに接続するために使用するすべてのマシンで使用されます。私の意見では、1つのシステムに1つのキーを使用します。つまり、特定のネットワークに接続する必要があるすべてのマシンでこのキーを使用します。あなたの場合、それはGitHubの1つのキーと会社のシステムの1つのキーになります。そのため、管理者からもう一度尋ねられた場合は、前回と同じキーを彼に渡します。新しいものではありません。しかし、これらのキーに共通の使用ポリシーがあるかどうかはわかりませんが、それ以降は間違っています。それは確かに可能です;-)


0

生成した公開鍵はすべての人向けです。a)信頼性を確認するb)暗号化する

秘密キーは秘密です。それはあなただけです。そして、それは安全な場所のどこかにバックアップすべきキーです。USBスティックなどに保存する場合は、安全なパスワードで暗号化することもできます。

公開鍵は、他者に対するあなたの身元です。したがって、問題はありません。少なくとも、明示的な新しいIDを使用したくない場合は、すべてに対して1つのキーペアを使用する方がよいので、他の人はあなただと気付かないでしょう。


3
ありがとう、しかし、あなたの答えは、ほとんど私の質問とは無関係です。@Diskillaの回答を参照してください。
Behrang
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.