サーバー管理者から使用する秘密キーが送られてきました。どうして?


73

会社のステージングサーバーとライブサーバーを展開ループにリンクするために、サーバーにアクセスすることになっています。側の管理者が2つのインスタンスをセットアップしてから、サーバーにユーザーを作成し、SSHでログインします。これほど私は慣れています。

今、私の頭の中では、承認されたキーフォルダー内に配置できる公開キーを送信します。代わりに、彼らは私にファイルid_rsa内に-----BEGIN RSA PRIVATE KEY-----電子メールを含むファイル名を送信しました。これは正常ですか?

私は周りを見回して、ゼロから自分のキーを生成およびセットアップするための膨大なリソースを見つけることができますが、サーバーの秘密キーから開始することについては何もありません。これを使用して自分用のキーを生成する必要がありますか?

私はシステム管理者に直接尋ねますが、馬鹿に見えて、私たちの間の時間を無駄にしたくありません。彼が私に送ったキーを無視して、彼らの許可されたフォルダの中に私の公開キーを入れるように頼むべきですか?


6
私はそれを通常または正気とは言いませんが、あなたは秘密鍵を持っているので(彼らはすでにそれを承認されたものとして追加していると仮定して)、他の秘密鍵を使うのと同じようにそれを使うことができます。対応する公開鍵は必要ありませんが、必要に応じていつでも生成できます:askubuntu.com/a/53555/158442
muru

34
ユーザー名テーブルで-----BEGIN RSA PRIVATE KEY-----指定さ'); DROP DATABASE;--れたユーザーを見た後の電子メールの取得は、次の恐ろしいことです。
ドミトリーグリゴリエフ

62
@DmitryGrigoryev見ておよそ怖い何も'); DROP DATABASE;--あなたのデータベーステーブルにユーザ名として-それはあなたが正しくユーザーの入力を脱出してきた示し
HorusKol

19
「他の秘密鍵を使用するのと同じように使用する」ことできません。これはプライベートではありません。エルゴは、おそらくそれが作成された機能を果たすことができません。それは捨てられ、UNIX管理者は厳しく非難されるべきです。@muru
user207421 16

7
この秘密鍵を持っている人は誰でも新しいサーバーにアクセスできます。おそらく、管理者はキーを必要とせずにアクセスできるため、サーバーをセットアップできたため、管理者による不正アクセスの追加の脅威はありません。ただし、これがあなたの鍵であるため、彼は確実にあなたになりすますことができます。また、あなた以外の誰かがメールを読んで、あなたになりすます可能性もあります。
user253751 16

回答:


116

今、私の頭の中では、承認されたキーフォルダー内に配置できる公開キーを送信します。

これから起こるべきことは「あなたの心の中」にあるのは正しいことです。

電子メールは安全な通信チャネルではないため、適切なセキュリティの観点から、ユーザー(およびユーザー)は秘密キーが侵害されたと見なす必要があります。

あなたの技術的なスキルとあなたがどのように外交的になりたいかに応じて、いくつかの異なることをすることができます。次のいずれかをお勧めします。

  1. 独自のキーペアを生成し、公開キーを送信する電子メールに添付して、次のように伝えます。

    ありがとう!電子メールは秘密キーの安全な配布方法ではないため、代わりに公開キーを配置してください。添付されています。

  2. 彼らに送信した秘密鍵は、電子メールで送信された後に侵害されたとみなされるため、彼らに感謝し、彼らがあなた自身のキーペアをインストールすることに反対するかどうか尋ねてください。

    独自のキーペアを生成し、送信されたキーを使用して最初にログインし、そのアクセスを使用してauthorized_keysファイルを編集して新しい公開キーを含めます(そして侵害された秘密キーに対応する公開キーを削除します)。

要するに、あなたはバカのように見えません。 しかし、他の管理者は非常に簡単に馬鹿のように見えるようにすることができます。良い外交はそれを避けることができます。


MontyHarderからのコメントに応じて編集します。

私が提案する行動方針のどちらも、「他の管理者に彼が間違ったことを伝えることなく物事を修正する」ことを含みません。私は彼をバスに放り込むことなく微妙にそうしました。

ただし、微妙な手がかりが得られなかった場合に(丁寧に)フォローアップすることを付け加えます。

こんにちは、私はあなたが安全でないチャネルとしての電子メールについての私のコメントに応答しなかったことを見ました。これは二度と起こらないと確信したいです。

私が秘密鍵の安全な取り扱いについてこの点を述べている理由を理解していますか?

ベスト、

トビー


9
+1ベストアンサー。加えて、このシステム管理者は無能であることが証明されているので、特に注意してください。彼/彼女が永久にサーバーを台無しにするとき(そしてそうでない場合)、背中を覆われている方が良いです。
dr01 16

2
ありがとう。繊細なフレーズを使用して、公開鍵を送信しました。それはすべて解決したように見えますが、彼が今送ってきたキーの認証を解除します。
トビー

27
他の管理者が「馬鹿のように見せることができる」わけではありません。他の管理者が何かばかげたことをしたということです。マシン間で秘密鍵を共有する必要があるシナリオは1つしか考えられません。そのシナリオでは、サーバープールに同じ名前(ラウンドロビンDNS解決など)でアクセスし、同じSSHホストキーを提示する必要があります。自動化プロセスは、その名前であることを受け入れます。その場合、同じ人がすべてのサーバーの管理者となり、外部の関係者が関与することなく転送を処理します。
モンティハーダー

21
@zwol私の仕事では、私たちは間違いを犯すことを理解しているが、同じ間違いを二度としないことを最優先にしています。ただし、同じ間違いを2回行わないためには、間違いであることを知っておく必要があります。そのため、OPが他の管理者に何を間違えたかを伝えることなく、物事を修正することを示唆する答えに投票できません。あなたが概説した理由のために管理者名を正確に呼ぶのではなく、間違いを「ばかげた」と呼ぶことにしました。(しかし、あなたの結論の括弧で囲まれた意味のある区別がはっきりしない。)
モンティ・ハーダー

8
@LightnessRacesinOrbit、あなたは「外交」の意味を完全に理解していないのではないかと思います。WebsterのThird New International Dictionaryなどの優れた辞書で整理してみましたか?
ワイルドカード

34

彼が私に送ったキーを無視して、彼らの許可されたフォルダの中に私の公開キーを入れるように頼むべきですか?

はい、それはまさにあなたがすべきことです。秘密鍵と全体のポイントは、彼らがしていることである民間だけで、あなたの秘密鍵を持っている意味します。管理者からそのキーを受け取ったので、彼もそれを持っています。そのため、彼はいつでもあなたになりすますことができます。

キーが安全なチャネルを介して送信されたかどうかは関係ありません:秘密キーを直接受け取ったとしても、何も変わりません。機密性の高い暗号化キーを電子メールで送信することは重要だというコメントには同意しますが、管理者は何らかのセキュリティポリシーが用意されているふりをすることすらありません。


6
また、OPには管理者のマシンがどれほど安全であるかを知る方法がないため(物語から、おそらく非常に安全ではない)、彼は秘密鍵が他の人にも漏洩している(または流出する)と想定する必要があります。電子メールで秘密鍵を送信することは、infosecの無知のための単なるボーナス事実です。
DR01

1
ユーザーを作成できる管理者は、あなたになりすますために秘密鍵は必要ないと想定できます。
マックスリード

3
@MaxRied適切なセキュリティログを適切に作成するのは難しいかもしれません。秘密鍵を使用すると、ログをモックアップする必要さえありません。これは、パスワードをリセットする能力とパスワードを知る能力があるようなものです。
ドミトリーグリゴリエフ

@DmitryGrigoryev彼はいつも...あなたのauthorized_keysファイルに別のキーを追加することができます
マックス・リート

4
@MaxRied私が言及していた、/var/log/secureまたは類似していた、私はスペーストリックがこれをだますことはないと確信しています。
ドミトリーグリゴリエフ

14

私には、管理者があなたのために秘密鍵と公開鍵のペアを生成し、公開鍵をauthorized_keysに追加して、秘密鍵を送信しているように見えます。この方法では、サーバーとのsshセッションにこの秘密鍵を使用するだけで済みます。自分でキーペアを生成したり、破損した可能性のある(常に最悪の場合:Pと考えられる)プライベートキーの公開キーを管理者に送信する必要はありません。

ただし、暗号化されていないメールで送信された秘密鍵は信頼しません。

私のアプローチは、秘密鍵を使用して一度ログインし、サーバー上のauthorized_keysに独自の公開鍵を追加し(元の公開鍵を置き換えて)、このメール秘密鍵を破棄することです。その後、管理者に感謝します。管理者は秘密鍵を提供してくれましたが、そのような情報/鍵は電子メール(/まったく)で送信しないことを希望します。


3
@Toby秘密鍵を送信することで想像できる唯一の理由は、彼らが使用しているツールを理解していないということです。また-i、コマンドラインでを使用して、使用する秘密キーを選択できます。
カスペルド16

18
@kasperd が想像できる理由は、電子メールで秘密鍵を送信するリスクは、技術に詳しくないユーザーにキーペアを適切に生成して送信する方法を説明しようとする手間が重すぎると判断したシステム管理者の過労ですパブリックキーバック。
mattdm 16

1
これを自分で修正できるというのは素晴らしい点です。管理者が新しいキーペアの公開キーをインストールするのを待つよりも、自分ですぐに実行した方が良いでしょう。もはや秘密ではない秘密鍵の使用を避けることは何の助けにもなりません。盗聴者になる可能性のある人は、authorized_keys(自分で追加してテストした後)侵入して削除する前に、それを使用する時間が長くなります。
ピーターコーデス

4
@mattdmそれは...完全に論理的ですが、恐ろしいです。鍵ペアを生成して公開鍵を送信できない人は、おそらく私が彼に与えた秘密鍵ではそれほどうまくいかないでしょう。
モンティハーダー

1
@mattdm、十分に公平ですが、私が彼にこのすべてを行うように頼んだので、私は彼が私がsshで接続する方法がわからないと思ったと信じることは難しいと思います。私が公開鍵を使用する基本的な一般的な方法しかわからないので、彼がとったステップはどちらかと言えば混乱を招きました。:x
トビー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.