Я повторил это два или три раза, поэтому я предполагаю, что что-то не так с тем, что я делаю.
Вот мои шаги:
Через 10 минут, когда экземпляр должен быть снова запущен, мое терминальное соединение показывает:
stead:~ stead$ ssh -v -i Dropbox/SteadCloud3.pem ubuntu@54.201.200.208
OpenSSH_5.6p1, Op`enSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to 54.201.200.208 [54.201.200.208] port 22.
debug1: connect to address 54.201.200.208 port 22: Connection refused
ssh: connect to host 54.201.200.208 port 22: Connection refused
stead:~ stead$
Хорошо, я понимаю, что общедоступный IP-адрес может измениться, поэтому проверяя консоль управления EC2, я проверяю, что он такой же. Странно. Ради интереса я пытаюсь подключиться к общедоступному DNS-имени хоста: ec2-54-201-200-208.us-west-2.compute.amazonaws.com. Без кубиков, результат тот же.
Даже при использовании клиента SSH Connect через Java, встроенного в консоль EC2, я получаю отказ в соединении.
Я проверил группы безопасности. Этот экземпляр находится в группе запуска-мастера-4. Если посмотреть на входящую конфигурацию для этой группы, порт 22 разрешен с 0.0.0.0/0, так что он должен быть где угодно. Я знаю, что попадаю в свой экземпляр, и это правильная группа безопасности, потому что я не могу проверить связь с экземпляром. Если я включаю ICMP для этой группы безопасности, мои пинги внезапно проходят.
Я нашел несколько других сообщений в Интернете с похожими сообщениями об ошибках, но большинство из них, похоже, легко решаются путем настройки параметров брандмауэра. Я пробовал несколько из них, но безуспешно.
Я предполагаю, что мне не хватает простого шага EC2. Спасибо за любую помощь, которую вы можете оказать, и я буду рад предоставить дополнительную информацию или протестировать дальше!
Обновление - вот мои системные журналы из консоли Amazon EC2: http://pastebin.com/4M5pwGRt
Из сообщение на форуме разработчиков AWS по этой теме:
Попробуйте остановить сломанный экземпляр, отсоединив том EBS и подключив его как дополнительный том к другому экземпляру. После того, как вы смонтировали сломанный том где-нибудь на другом экземпляре, проверьте файл / etc / sshd_config (внизу). У меня было несколько экземпляров RHEL, где Yum проверял sshd_config, вставляя повторяющиеся строки внизу, что приводило к сбою sshd при запуске из-за синтаксических ошибок.
После того, как вы его исправите, просто отключите том, отсоедините, повторно подключите к другому экземпляру и снова запустите его.
Давайте разберемся со ссылками на документацию AWS:
cd /etc/sshsudo nano sshd_configctrl-v несколько раз, чтобы добраться до конца файлаctrl-k все строки внизу с упоминанием «PermitRootLogin без пароля» и «UseDNS no»ctrl-x и Y сохранить и выйти из редактируемого файлаcd /etcsudo nano rc.localctrl-x и Y сохранить и выйти из редактируемого файлаСегодня у меня было подобное поведение на моем экземпляре ec2, и я отследил это: когда я sudo reboot now машина зависает, и мне приходится перезапускать ее вручную из консоли управления aws, когда я это делаю sudo reboot он перезагружается нормально. Очевидно, «сейчас» не является допустимым вариантом для перезагрузки, как указано здесь. https://askubuntu.com/questions/397502/reboot-a-server-from-command-line
мысли?
Это может не помочь ситуации, но я видел несколько случаев, когда перезагрузка на EC2 «зависала». Если вы выполните «сброс» на виртуальной машине, а затем получите системные журналы, это может изменить поведение. Убедитесь, что журналы относятся ко второй загрузке, а не первой - они, как правило, задерживаются при обновлениях.
Еще одна вещь, которую нужно проверить, - убедиться, что экземпляр отвечает по IP. Вы, кажется, получаете отказ в соединении выше, что звучит так, как будто экземпляр запущен, но SSH не работает или защищен брандмауэром, но убедитесь, что экземпляр полностью перезагружен.
Вы также можете попробовать открыть все порты в тестовой системе и посмотреть, что вам показывает «nmap» - отвечают ли другие службы на этом экземпляре.
Щелкните правой кнопкой мыши имя экземпляра и выберите «Изменить группы безопасности». Убедитесь, что созданная вами группа безопасности, разрешающая любому пользователю подключаться к порту 22, отмечена и применена к этому экземпляру.
У меня была аналогичная проблема, мой экземпляр EC2 Amazon Linux больше не был доступен после запуска перезагрузка sudo.
Нет доступа по SSH, команды остановки / запуска / перезагрузки из консоли администратора Amazon тоже не дали результата.
Наконец-то мне удалось перезапустить свой экземпляр, создав образ через консоль Amazon. Кажется, что процесс создания образа исправляет состояние экземпляра.
Надеюсь, поможет ;)
У меня возникла эта проблема после выполнения sudo reboot now через SSH на моем сервере EC2 под управлением Ubuntu 14.04. Работал нормально после перезагрузки снова с помощью консоли управления EC2.
В моем случае я бы настроил группу безопасности, чтобы разрешить подключения к порту 22 только с моего IP-адреса. Несколько дней спустя мой интернет-провайдер изменил мой IP-адрес, поэтому группу безопасности необходимо обновить.
У меня была такая же проблема после запуска ванили sudo reboot команда. Я обнаружил, что смог решить проблему, полностью остановив (не перезагружая) свой AMI с помощью консоли AWS, а затем запустив его резервную копию.
По какой-либо причине перезапуск AMI из консоли AWS, например, щелчок по действию перезапуска вместо остановки и последующего запуска экземпляра, не решить проблему.
Как уже упоминалось, вы, вероятно, испортили файл / etc / fstab /
У меня была такая проблема. Сначала вам нужно повторно добавить том в / dev / sda1, как говорится в предупреждающем сообщении.
Тогда я не мог ssh. Я понял, что мне нужно добавить другой том, который я создал, и это устранило проблему ssh.
Затем вы можете войти в систему и восстановить исходный файл fstab.