AWSが認証の問題に対処するために秘密鍵を配布するのはなぜですか？
AWSは、秘密鍵（.pem）EC2に接続する管理ホストに。
AWSはopensslツールを使用します
鍵ペアを使用すると、以下に示すように、公開鍵または秘密鍵で暗号化し、他の鍵で復号化できるため、鍵プロバイダーは一般に公開鍵を提供しますが、秘密鍵は提供しません。
$ openssl genrsa -out mykey 2048
$ cp mykey privatekey
$ openssl rsa -in mykey -pubout -out publickey
$ rm mykey
$ # Encrypt with public key
$ echo "the cat sat on the mat" | open ssl rsautl -encrypt -pubin -inkey publickey > ciphertxt
$ # cat cipher.txt
$ # cat cipher.txt | openssl rsautl -decrypt -inkey privatekey
1）AWSが公開鍵ではなく秘密鍵を配布するのはなぜですか？安全な通信のために...
2）キーペアは、主にAWSのリソースにアクセスするための通信を保護するためのものですが、ユーザーを認証するためのものではありません。
ssh -i something.pem user@ec2-public-dns-name
キーの配布は認証の問題をどのように解決しますか？キーは間違った人物に盗まれる可能性があります...なぜAWSはパスワードなしでEC2へのsshログインを許可するのですか？
1）AWSが公開鍵ではなく秘密鍵を配布するのはなぜですか？安全な通信のために...
秘密鍵がないと、自分が公開鍵の所有者であることを証明できません。あなたが所有者であることを証明しないと、SSH公開鍵認証を使用できません。
したがって、Amazonはキー自体を生成し、送信します。 Amazonを信頼していない場合は、別のキーを作成し、公開キーをauthorized_keysに配置して、以前のキーを削除できます。
2）キーペアは、主にAWSのリソースにアクセスするための通信を保護するためのものですが、ユーザーを認証するためのものではありません。
結構です。キーペアは認証にも確実に使用できます。秘密鍵でデータに署名すると、誰か（またはシステム）があなたの公開鍵を使用して、本当にデータに署名しているのかどうかを確認できます。
SSH鍵認証の単純化は次のようなものです。クライアントは、認証に使用する鍵をサーバーに送信します。サーバーがauthorized_keysファイルにその鍵を持っている場合、乱数を生成し、公開鍵で暗号化して、返信します。クライアントが実際に対応する秘密鍵を所有している場合は、ファイルを復号化し、セッションキー（簡単にするために省略）と連結し、結果をハッシュしてサーバーに送信できます。サーバーには、乱数とセッションキーがあります。サーバーが両方をハッシュし、結果がクライアントが送信したものと一致する場合、クライアントはキーの所有者であり、ログインできます。
キーの配布は認証の問題をどのように解決しますか？
簡単です。上記を参照。
キーは間違った人物に盗まれる可能性があります...なぜAWSはパスワードなしでEC2へのsshログインを許可するのですか？
なぜなら、パスワードを盗むよりも鍵を盗む方が数桁難しいからです。攻撃者がAmazonパスワードを盗むためにフィッシングサイトを作成し、それに騙された場合、パスワードが侵害されます。
同じ攻撃者がフィッシングSSHサーバーを作成してデータを盗む場合、秘密鍵は送信されないため、盗むことはありません。彼はまだ持っていないもの（乱数とセッションキー）を盗むことはできず、唯一の境界線sensitiveを盗むことができるのはあなたの公開鍵であり、公開鍵はとにかく公開されます。
キーを使用したSSHが最も安全な方法です。パスワードは盗まれたり漏洩したりする可能性がありますが、秘密鍵を盗むことははるかに困難です。
この特定のケースでは、秘密鍵と公開鍵のペアは認証用です。
AWSコンソールで秘密鍵と公開鍵のペアを生成する必要はありません。これを自分で行い、AWSに公開鍵justをアップロードできます。
重要なことは、EC2インスタンスにロードされた公開鍵が、ログオンしようとしている秘密鍵と一致することです。彼らのドキュメントによると：
Amazon EC2を使用してキーペアを作成できます。詳細については、Amazon EC2を使用したキーペアの作成を参照してください。または、サードパーティのツールを使用して、公開鍵をAmazon EC2にインポートすることもできます。詳細については、「Amazon EC2への独自の公開キーのインポート」を参照してください。各キーペアには名前が必要です。覚えやすい名前を選択してください。 Amazon EC2は、公開鍵を、キー名として指定した名前に関連付けます。 Amazon EC2は公開鍵のみを保存し、ユーザーは秘密鍵を保存します。秘密鍵を所持している人はだれでもログイン情報を解読できるため、秘密鍵を安全な場所に保管することが重要です。
いったんコンソールで生成された秘密鍵は取得できなくなるため、秘密にされます。 EC2を使用するためのエントリへの障壁を減らすためにコンソールからキーを生成するこの機能を提供していると思います。
同じことがコンソールのsshアクセスにも当てはまります。 EC2の使用を開始する多くの人々はSSHクライアントなどに慣れていないため、ブラウザーに直接ログオンすることは非常に役立ちます。ブラウザーでの直接アクセスは、モニターとキーボードをサーバー（sshではなく）に直接接続することをシミュレートし、明示的に設定しない限り、パスワードを要求しません。もちろん、AWSにはEC2に接続する新しい方法がありますが、私はそれらに慣れていません。
それどころか、非対称（公開鍵）暗号化は、SSLまたはSSH接続を介して流れるデータのバルク暗号化および復号化にほとんど使用されません。むしろ、認証と鍵合意に使用されます。対称暗号化は、非対称暗号化と比較して、はるかに効率的で、計算コストが低くなります。
SSLでは、サーバーは、公開鍵を含み、認証局によってCAの秘密鍵で署名された証明書を提供する必要があります。次に、クライアントは、事前にクライアントによって信頼されているCAの公開鍵を使用して署名を検証します。 （通常、サーバーとルートCA証明書の間には中間署名があります。）
検証されると、クライアントはサーバーの公開鍵を使用してサーバーとランダムなマスターシークレットを共有します。ランダムマスターシークレットは、セッションを保護するための暗号化キーを作成するために使用されます。証明書はサーバーをクライアントに対して認証するために使用されますが（ブラウザーにとって重要）、暗号化キーは対称的であり、それ自体では認証を提供しません。
AWSがそうするように構成されていると私が信じているサービスがこれを要求するように構成されていない限り、クライアントはプロトコルによってそれ自体をサーバーに対して認証する必要はありません。自身を認証するには、クライアントは独自の証明書を生成する必要があります。証明書には、署名するための独自の秘密鍵が必要です。 AWSはクライアントに代わって秘密鍵を作成し、クライアント証明書を検証できるように対応する公開鍵を保持しているようです。代わりの方法は、クライアントがこのキーを生成してAWSに公開キーを送信することです。これは、AWSが最初の使用時にクライアントの公開キーを信頼する必要があるため問題です。これは、暗号化ではなく認証に使用されます。
SSHは、公開鍵認証の直接使用を優先して、証明書プロセスの大部分をスキップします。この場合、クライアントは、SSH接続に関連しているため両方の当事者に知られているデータに署名することによってサーバーに対して認証を行い、サーバーはクライアントの公開鍵（サーバーと事前共有する必要があります）を使用してこの署名を検証します。 SSHでは、サーバーがクライアントに対して自身を認証することも必要ですが、ホスト鍵は事前共有されるのではなく、最初の使用時に信頼されることがよくあります。この場合も、SSLの場合と同様に、AWSがクライアントによって保持される秘密キーを作成するとは、AWSがクライアントを認証する署名を検証するための対応する公開キーをすでに持っていることを意味します。また、SSLと同様に、データは対称キーで暗号化されます。この場合、（匿名の一時キーを使用して）合意されますbefore認証が行われます（そのため、他の形式の認証、パスワードは、転送中の暗号化によって保護されます）。
これはすべて、クライアントがAWSから発行された秘密キーの漏洩を防ぐ必要があることを意味します。 AWSに関する限り、そのキーを所有している人なら誰でもisクライアントであり、クライアントが実行できることをすべて実行する完全な権限があります。