Битами Wordpress Стек SSH

Question

У меня есть экземпляр, использующий этот AMI - ami-b7a29cc3

http://thecloudmarket.com/image/ami-b7a29cc3--bitnami-wordpress-3-3-1-1-multisite-linux-ubuntu-10-04-ebs#/details

Это многосайтное изображение Bitnami в Wordpress.

Он установлен и загружен нормально, я настроил группы безопасности SSH, HTTP, HTTP.

Но как ни странно, подключение через SSH не работает, несмотря на то, что интерфейс работает нормально.

Я пробовал следующих пользователей и команды безрезультатно, Ubuntu, root и bitnami.

Я продолжаю получать что-то странное, как это происходит, когда я запускаю команду.

D-Hewards-MacBook-Pro: загружает dheward $ ssh -i macbookpro.pem bitnami@176.34.127.170 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@ @ ПРЕДУПРЕЖДЕНИЕ: ДИСТАНЦИОННАЯ ИДЕНТИФИКАЦИЯ ХОЗЯИНА ИЗМЕНИЛАСЬ! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@ ВОЗМОЖНО, ЧТО-ТО ЧТО-ТО ДЕЛАЕТ! Кто-то может подслушивать вас прямо сейчас (атака «человек посередине»)! Также возможно, что ключ хоста RSA был только что изменен. Отпечаток ключа RSA, отправленный удаленным хостом, 9f: 85: 89: 8а: 7a: 9d: дБ: е0: 15: е4: 11: d0: е0: 4b: 74: A9. Пожалуйста, обратитесь к системному администратору. Добавьте правильный ключ хоста в /Users/dheward/.ssh/known_hosts, чтобы избавиться от этого сообщения. Ключ оскорбления в /Users/dheward/.ssh/known_hosts:17 Ключ хоста RSA для 176.34.127.170 изменился, и вы запросили строгую проверку. Ошибка проверки ключа хоста. D-Hewards-MacBook-Pro: загружаемые версии $

Answer 1

Это вероятно (то есть вы должны судить об этом самостоятельно после чтения и понимания моего объяснения, потому что в противном случае ваша безопасность действительно была бы под угрозой!)просто нормальное поведение SSH в сочетании с повторным использованием дефицитных IP-адресов Amazon EC2 (см. исчерпание IPv4-адреса ):

Справочная информация

сторона сервера вашего SSH-соединения должна идентифицировать себя по упомянутому отпечатку пальца для ключа RSA , который впоследствии проверяется вашим SSH-инструментом на стороне клиента, чтобы убедиться, что вы не стали жертвой Man-inсредняя атака .

Обычный процесс SSH

1. при первом подключении к новому серверу SSH
2. новый сервер представляет свой RSAидентификатор ключа для вашего SSH-клиента
3. ваш SSH-клиент попросит вас подтвердить подлинность этого сервера и по очереди импортирует ключ RSA для будущих проверок безопасности (в /Users/dheward/.ssh/known_hosts в вашем случае)
   • в идеале вы бы получили этот ключ RSA на безопасном канале, чтобы правильно оценить его действительность, однако большинство людей просто не делают этого в сегодняшних постоянно меняющихся облачных средах, см. опрос Эрика Хаммонда: проверка ssh Fingerprint onЭкземпляры EC2
     • В сообщении Эрика упоминаются варианты, которые уже в принципе решают эту проблему, т. Е. . Для оптимальной безопасности вы должны запросить вывод консоли экземпляра и найти отпечаток ключа хоста ssh в журнале.чтобы убедиться, что он совпадает с отпечатком, представленным вам командой ssh ​​.
     • Более того, Эрик подробно обсудил эту тему в паранойе ключа хоста ssh .
   • Скотт Мозер подготовил отличную сводку о том, как на самом деле проверить ключи SSH для экземпляров EC2 , и предоставляет инструкции по обновлению файла known_hosts по очереди.
4. при каждом последующем подключении к тому же SSH-серверу ваш SSH-клиент будет сравнивать сохраненныеКлюч RSA с ключом, предоставленным сервером SSH, и предоставит большое полное предупреждение о потенциальной вредоносности, если он изменится, потому что это обычно не должно действительно (я пока пропущу редкие исключения)
   • это означаетЕсли это внезапно изменилось ( особенно для хоста, к которому вы уже подключались без такого предупреждения), вам действительно следует немедленно отступить и сначала оценить ситуацию, т.е. если вы не знаете причину дляВ результате изменения безопасность вашего соединения находится под угрозой

Причина (т.е. ваш опыт) * ​​1061 * Возможно, вы выполнили шаги 1-4 один раз для другого сервера SSHна EC2, который, как оказалось, имеет тот же IP-адрес из своего пула (т.е. 176.34.127.170);хотя это встречается не каждый день, это маловероятно с течением времени, учитывая ограниченное количество адресов IPv4, доступных в целом, и соответствующий пул, доступный для Amazon в частности. Теперь, поскольку вы подключаетесь к совершенно другому серверузатем тот, для которого ключ RSA был сохранен в первую очередь (каждый запущенный экземпляр EC2 имеет соответственно уникальный идентификатор), ваш SSH-клиент выкрикивает фол и выдает правильно эскалированное предупреждение, которое вы видите. Кроме того,в этой ситуации кажется, что он полностью запрещает доступ по SSH, поскольку вы [или ваш системный администратор] запросили строгую проверку .(Большинство настольных SSH-клиентов , похоже, запрашивают подтверждение, как и при первом коммите в этом случае по умолчанию). Решение Убедитесь, что чертовски уверены мое объяснение вашего опыта на самом деле относится к вашей ситуации! Следуйте инструкциям, уже приведенным в предупреждающем сообщении: Отпечаток пальца для ключа RSA, отправленныйудаленный хост - 9f: 85: 89: 8a: 7a: 9d: дБ: e0: 15: e4: 11: d0: e0: 4b: 74: a9.Пожалуйста, обратитесь к системному администратору. Добавьте правильный ключ хоста в/Users/dheward/.ssh/known_hosts, чтобы избавиться от этого сообщения. Оскорблять введите /Users/dheward/.ssh/known_hosts:17 ключ хоста RSA для 176.34.127.170 изменился, и вы запросили строгую проверку. [Акцент мой] т.е. кеш ключа SSH RSA, поддерживаемый в /Users/dheward/.ssh/known_hosts, в настоящее время имеет запись № 17 для IP-адреса 176.34.127.170 с другим ключом RSA, чем тот, который представлен сервером с IP-адресом 176.34.127.170, к которому вы сейчас пытаетесь подключиться - это необходимо настроить, если вы уверены, что на самом деле нет атаки типа «человек посередине» (что маловероятно, учитывая, что это новый хост, который вы только что заказали, хотя, как упоминалось в пункте 3 выше), вы можете Я хочу убедиться в этом, следуя инструкциям Скотта Мозера, как на самом деле Проверить ключи SSH на экземплярах EC2 ). Удачи!