Amazon EC2 - нет SSH после перезагрузки, соединение отклонено

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

Вот мои шаги:

  1. Запустите новый экземпляр через консоль управления EC2, используя: Ubuntu Server 13.10 - ami-ace67f9c (64-bit)
  2. Запуск с настройками по умолчанию (используя мою существующую пару ключей)
  3. Экземпляр запускается. Я могу SSH к нему, используя Putty или Mac терминал. Успех!
  4. Я перезагружаю экземпляр

  5. Через 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, я проверяю, что это то же самое. Weird. Ради интереса я пытаюсь подключиться к общедоступному DNS-имени хоста: ec2-54-201-200-208.us-west-2.compute.amazonaws.com. Нет кости, тот же результат.

Даже используя SSH-клиент Connect via Java, встроенный в консоль EC2, я получаю отказ в соединении.

Я проверил группы безопасности. Этот экземпляр находится в группе launch-wizard-4. Если посмотреть на входящую конфигурацию для этой группы, то для порта 22 разрешен вход 0.0.0.0/0, поэтому он должен быть где угодно. Я знаю, что поражаю свой экземпляр, и это правильная группа безопасности, потому что я не могу пропинговать экземпляр. Если я включаю ICMP для этой группы безопасности, мои пинг-сообщения внезапно проходят.

Я нашел несколько других сообщений в Интернете с похожими сообщениями об ошибках, но большинство из них, кажется, легко решаются путем настройки параметров брандмауэра. Я попробовал несколько из них, но не повезло.

Я предполагаю, что есть простой шаг EC2, который я пропускаю. Спасибо за любую помощь, которую вы можете оказать, и я рад предоставить дополнительную информацию или провести тестирование!

Обновление - вот мои системные журналы с консоли Amazon EC2: http://pastebin.com/4M5pwGRt

Источник

9 ответов

Решение

Подобное поведение происходило сегодня на моем экземпляре ec2, и отследил это до следующего: когда я делаю sudo reboot nowмашина зависает, и я должен перезапустить ее вручную с консоли управления aws, когда я это сделаюsudo rebootперезагружается просто отлично. Очевидно, "сейчас" не является допустимым вариантом для перезагрузки, как указано здесь https://askubuntu.com/questions/397502/reboot-a-server-from-command-line

мысли?

Источник

Из сообщения форума разработчиков AWS на эту тему:

Попробуйте остановить поврежденный экземпляр, отсоединить том EBS и подключить его как дополнительный том к другому экземпляру. После того, как вы смонтировали поврежденный том где-то в другом экземпляре, проверьте файл /etc/sshd_config (внизу). У меня было несколько экземпляров RHEL, в которых Yum прокручивал sshd_config, вставляя повторяющиеся строки внизу, что приводило к сбою sshd при запуске из-за синтаксических ошибок.

Как только вы исправите это, просто размонтируйте том, отсоедините, подключите его к другому экземпляру и снова запустите его.

Давайте разберемся со ссылками на документацию AWS:

  1. Остановите поврежденный экземпляр и отсоедините том EBS (корневой), перейдя в консоль управления EC2, щелкнув "Elastic Block Store" > "Тома", щелкнув правой кнопкой мыши том, связанный с остановленным экземпляром.
  2. Запустите новый экземпляр в том же регионе и той же ОС, что и поврежденный экземпляр, затем подключите исходный корневой том EBS в качестве дополнительного тома к новому экземпляру. Команды в шаге 4 ниже предполагают, что вы монтируете том в папку с именем "data".
  3. После того, как вы установили сломанный том где-то в другом экземпляре,
  4. проверьте файл "/etc/sshd_config" на наличие дубликатов, выполнив следующие команды:
    • cd /etc/ssh
    • sudo nano sshd_config
    • ctrl-v кучу раз, чтобы добраться до сути файла
    • ctrl-k все строки внизу с упоминанием "PermitRootLogin без пароля" и "UseDNS no"
    • ctrl-x а также Y сохранить и выйти из отредактированного файла
  5. @Telegard указывает (в своем комментарии), что мы только исправили симптом. Мы можем устранить причину, закомментировав 3 связанные строки в файле /etc/rc.local. Так:
    • cd /etc
    • sudo nano rc.local
    • найдите строки "PermitRootLogin..." и удалите их
    • ctrl-x а также Y сохранить и выйти из отредактированного файла
  6. Как только вы исправите это, просто размонтируйте громкость,
  7. отсоединитесь, перейдя в консоль управления EC2, нажав "Elastic Block Store" > "Тома", щелкнув правой кнопкой мыши том, связанный с остановленным экземпляром,
  8. подключите к другому экземпляру и
  9. снова включи.
Источник

У меня была такая же проблема после запуска ванили sudo reboot команда. Я обнаружил, что смог решить проблему, полностью остановив (не перезагружая) свой AMI с помощью консоли AWS, а затем снова запустив его.

По какой-либо причине перезапуск AMI из консоли AWS, например нажатие на действие перезапуска, а не остановку и запуск экземпляра, не устранили проблему.

Источник

Это может не помочь ситуации, но я видел некоторые случаи, когда перезагрузка на EC2 застревает. Если вы выполните "перезагрузку" на ВМ, а затем восстановите системные журналы, это может изменить поведение. Убедитесь, что журналы относятся ко второй загрузке, а не к первой - они, как правило, задерживаются при обновлении.

Еще одна вещь, которую нужно проверить, это убедиться, что экземпляр отвечает по IP. Похоже, что вы получаете соединение, которое было отклонено выше, что звучит так, как будто экземпляр работает, но SSH не работает или защищен, но убедитесь, что экземпляр полностью перезагрузился.

Вы также можете попробовать открыть все порты из тестовой системы и посмотреть, что показывает "nmap" - реагируют ли другие сервисы на экземпляр.

Источник

Щелкните правой кнопкой мыши на имени экземпляра и выберите "Изменить группы безопасности". Убедитесь, что созданная вами группа безопасности, которая позволяет кому угодно из любого места на порт 22, проверена и применена к этому экземпляру.

Источник

У меня была похожая проблема, мой экземпляр EC2 Amazon Linux больше не был доступен после запуска sudo reboot.

Нет доступа по SSH, команды stop/start/reboot из консоли администратора Amazon тоже не дали результата.

Я наконец смог перезапустить свой экземпляр, создав образ через консоль Amazon. Кажется, процесс создания образа фиксирует состояние экземпляра.

Надеюсь, поможет;)

Источник

В моем случае я бы настроил группу безопасности, чтобы разрешить подключения к порту 22 только с моего IP. Через несколько дней мой провайдер изменил мой IP-адрес, поэтому группа безопасности нуждается в обновлении.

Источник

Я получил эту проблему после выполнения sudo reboot now через SSH на моем сервере EC2 под управлением Ubuntu 14.04. После перезагрузки снова работал нормально, используя консоль управления EC2.

Источник

Как уже упоминалось, вы, вероятно, испортили / etc / fstab /

У меня была эта проблема. Сначала вы должны заново добавить том в /dev/sda1, как написано в предупреждающем сообщении.

Тогда я не мог ssh. Я понял, что мне нужно добавить другой том, который я создал, и это решило проблему с ssh.

Затем вы можете войти и исправить fstab обратно к оригиналу.

Источник
Другие вопросы по тегам