Почему Amazon отпускает закрытые клавиши вместо открытых ключей?
Можно обойти это путем установки сервера ожога Массив CAS, если это - то, что Вы действительно хотите сделать.
Создайте запись DNS для exchange.mysite.com на Вашем внутреннем сервере DNS и укажите на него на свой Exchange Server. Затем сделайте это:
Новый-ClientAccessArray - имя “массив CAS” –Fqdn “exchange.mysite.com” - сайт “Default-First-Site-Name”
DatabaseName-RpcClientAccessServer "exchange.mysite.com" набора-MailboxDatabase
Можно даже смочь заставить это работать без части Массива CAS, я просто не попробовал ее и вероятно не рекомендовал бы это как Microsoft, вероятно, привычка' поддерживает ее.
Если подумать более глубоко о процессе аутентификации, что нужно держать в секрете? Amazon знает публичную половину ключа, и любой может знать публичную половину. Открытая половина пары ключей при сопоставлении с частной половиной означает, что частная половина использовалась для аутентификации.
Ваш частный ключ, который предоставляется вам, когда Amazon генерирует для вас пару ключей, полезен только в том случае, если вы только тот, у которого он есть. Если это не секрет, то любой, кто знает это, может также пройти аутентификацию для любого, кто владеет публичной половиной пары ключей.
Кто бы ни аутентифицировался , должен владеть частной половиной. . Это нормально, если все в мире могут аутентифицировать вас, удерживая открытую половину ключа, но только вы должны контролировать частную половину.
Закрытым ключом является mydomain.key, который вы создали вместе с CSR.
GoDaddy отправил вам открытый ключ (файл сертификата mydomain.com.crt, подписанный GoDaddy), а также промежуточную цепочку сертификатов для GoDaddy, которые завершают цепочку доверия между вашим сертификатом и тем, о чем знает браузер конечного пользователя (файл gd_bundle.crt).
Я не особо знаком с ELB, но глядя на эту страницу документации:
Вы предоставите свой файл mydomain.key для закрытого ключа, mydomain.com. crt для открытого ключа и файл gd_bundle.crt для цепочки сертификатов.
открытый ключ устанавливается в файл authorized_keys пользователя при запуске экземпляра EC2. Закрытый ключ хранится только у пользователя и предоставляется для аутентификации на сервере.Из документации по адресу:
http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/ApiReference-query-CreateKeyPair .html
похоже, что Amazon генерирует пару ключей на своих серверах и отправляет вам закрытый ключ через HTTPS. Возможно, это далеко не идеально (в идеале, закрытый ключ будет у вас и у кого-либо еще), но, вероятно, не так уж и ужасно, учитывая, что все это происходит в контексте вашего аутентифицированного сеанса и только вы (и Amazon временно) видите закрытый ключ. Вы также всегда можете сгенерировать и загрузить свой собственный открытый ключ для использования в EC2, сохраняя при этом строго закрытый ключ.
Для настройки пользователей SFTP для аутентификации ключей они должны генерировать ключи SSH на своих машинах. После создания пары ключей они должны отправлять вам только открытый ключ для установки в соответствующем файле authorized_keys. Закрытый ключ, как следует из названия, является закрытым.
In one sense, it doesn't matter. A private/public key pair consists of two parts, and which of them is the public one is up to you. If something is encrypted with one key, you need the other one to decrypt it. If you have published one key publicly and not the other, the private key is the one you didn't publish.
Getting to your actual question: presumably the key Amazon gives you is to allow you to control your own resources, so it should not be given to other people. In this context, you have to trust Amazon to have your private key, at least for long enough to get set up.
If you want your customer to log in this way, you need them to give you a key they are prepared to share with you, so therefore their public key. You install this on the server in authorized_keys, which is effectively saying "anyone who posesses the private key matching this public one may access this resource".
Аутентификация с открытым ключом работает в обратном направлении, чем вы, вероятно, думаете. Открытый ключ шифрует сообщения, а закрытый ключ расшифровывает их. Сервер хранит открытый ключ владельца учетной записи и использует его для шифрования сообщения. Только владелец закрытого ключа может расшифровать это сообщение.
Если вы отправляете кому-то секрет, зашифрованный его открытым ключом, если он может сказать вам, что это за секрет, то вы знаете, что у него есть соответствующий закрытый ключ. Затем пользователь аутентифицируется.
AWS требует, чтобы вы загрузили и сохранили свой закрытый ключ, потому что они не будут хранить его по соображениям безопасности. Поскольку закрытый ключ нигде на AWS не хранится, вы можете быть уверены, что ваш экземпляр EC2 безопасен.