Запуск экземпляра EC2 внезапно отказывается от SSH-соединения

Я установил экземпляр EC2 пару дней назад, и даже вчера вечером я смог без проблем справиться с SSH. Сегодня утром я не могу сШ. Порт 22 уже открыт в группе безопасности, и я ничего не менял с прошлой ночи.

Ошибка:

ssh: connect to host [ip address] port 22: Connection refused

Недавно у меня была аналогичная проблема, и я не мог понять, почему это происходит, поэтому мне пришлось создать новый экземпляр, настроить его снова и подключить и настроить все хранилища EBS на новый. Взял меня пару часов... и теперь это происходит снова. В предыдущем я установил denyhost, который мог заблокировать меня, но в текущем, есть только apache2 и mysql.

Текущий экземпляр работает уже 16 часов, поэтому я не думаю, что он не закончил загрузку... Кроме того, порт 22 открыт для всех источников (0.0.0.0/0) и использует протокол tcp.

Любые идеи?

Спасибо.

Ответ 1

С помощью @abhi.gupta200297 мы смогли его решить.

Проблема заключалась в ошибке в /etc/fstab, и sshd должен был быть запущен после fstab. Но это было не так, поэтому sshd не запускался и почему он отказывался от связи. Решением было создать временный экземпляр, установить корневую EBS из исходного экземпляра и прокомментировать материал из fstab и voila, что позволит мне снова подключиться. И в будущем я просто прекратил использовать fstab и создал кучу команд оболочки для монтирования томов EBS в каталоги и добавил их в файл /etc/init.d/ebs-init-mount, а затем запустил update-rc.d ebs-init-mount defaults для инициализации файла, и я больше не имею проблемы с заблокированным ssh.

ОБНОВЛЕНИЕ 4/23/2015

Команда Amazon создала видео-учебник по аналогичной проблеме и покажет, как отлаживать этот метод: https://www.youtube.com/watch?v=_P29ZHu_feU

Ответ 2

Похоже, что sshd по какой-то причине остановился. Поддерживается ли экземпляр EBS? если это так, попробуйте отключить его и начать его резервное копирование. Это должно решить проблему.

Кроме того, вы можете ssh с веб-консоли AWS? У них есть java-плагин для ssh в экземпляр.

Ответ 3

Для тех из вас, кто столкнулся с этим сообщением, потому что вы не можете SSH в свой экземпляр EC2 после перезагрузки, это перекрестно размещено до аналогичный вопрос на serverfault:

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

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

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

Позвольте сломать это, со ссылками на документацию AWS:

Остановить сломанный экземпляр и отсоединить том EBS (root), перейдя в консоль управления EC2, нажав "Эластичный блок-магазин", > "Объемы", щелкнув правой кнопкой мыши на томе, связанном с экземпляром, который вы остановили.
Запустите новый экземпляр в том же регионе и той же ОС, что и сломанный экземпляр, затем присоедините исходный корневой том EBS в качестве вторичного тома к вашему новому экземпляр. Команды на шаге 4 ниже предполагают, что вы монтируете том в папку с именем "данные".
Когда вы смонтировали сломанный том где-то на другом экземпляре,
проверьте файл "/etc/sshd_config" для дубликатов записей, выпустив следующие команды:
- cd /etc/ssh
- sudo nano sshd_config
- ctrl-v несколько раз, чтобы добраться до нижней части файла.
- ctrl-k все строки внизу, в которых упоминаются "PermitRootLogin без пароля" и "UseDNS no"
- ctrl-x и Y для сохранения и выхода из отредактированного файла
@Telegard указывает (в своем комментарии), что мы только фиксировали симптом. Мы можем исправить эту причину, комментируя 3 связанные строки в файле "/etc/rc.local". Так:
- cd /etc
- sudo nano rc.local
- найдите строки PermitRootLogin... и удалите их.
- ctrl-x и Y для сохранения и выхода из отредактированного файла
Как только вы исправили его, просто отключить том,
отделитесь, перейдя в консоль управления EC2, нажав "Сохранение эластичного блока" > "Объемы", щелкнув правой кнопкой мыши на томе, связанном с остановленным экземпляром,
повторно подключиться к вашему другому экземпляру и
снова запустите его.

Ответ 4

Это произошло со мной в экземпляре Red Hat EC2, потому что эти две строки автоматически добавляли конец файла /etc/ssh/sshd _config каждый раз, когда я запускал свой экземпляр:

PermitRootLogin без пароля
UseDNS no

Одна из этих операций добавления была выполнена без разрыва строки, поэтому хвост файла sshd_config выглядел следующим образом:

PermitRootLogin без пароля
UseDNS noPermitRootLogin без пароля
UseDNS no

Это вызвало отказ sshd при следующем запуске. Я думаю, что это было вызвано сообщением об ошибке: https://bugzilla.redhat.com/show_bug.cgi?id=956531 Решение заключалось в том, чтобы удалить все дубликаты записей в нижней части файла sshd_config, и добавьте дополнительные разрывы строк в конце.

Ответ 5

Перейдите в консоль управления AWS > выберите экземпляp > щелкните правой кнопкой мыши и выберите "Получить системные журналы", В этом будет указано, что пошло не так.

Ответ 6

Я получил аналогичный ssh, заблокированный отсоединением EBS, но забыл изменить/etc/fstab

Ответ 7

Была та же проблема, но у системных журналов было это:

Запуск sshd: /var/empty/sshd должен принадлежать пользователю root, а не групповой или доступной для записи. [НЕ УДАЛОСЬ]

Для отсоединения тома и подключения к подключаемому экземпляру использовались те же действия, что описаны выше. Затем использовали:

sudo chmod 755/var/empty/sshd

sudo chown root: root/var/empty/sshd

(https://support.microsoft.com/en-us/help/4092816/ssh-fails-because-var-empty-sshd-is-not-owned-by-root-and-is-not-group)

Затем отсоединился и снова подключился к исходному экземпляру EC2 и теперь мог получить доступ через ssh.

Ответ 8

Если в вашей Ubuntu есть systemd, вы можете отредактировать /lib/systemd/system/local-fs.target и закомментировать последние две строки:

#OnFailure=emergency.target
#OnFailureJobMode=replace-irreversibly

Я не проверял это подробно и не знаю, есть ли какие-либо риски или побочные эффекты, но пока он работает как шарм. Он монтирует корневой том и все остальные тома (за исключением явно неправильно настроенных), затем продолжает процесс загрузки до тех пор, пока не активируется SSH, поэтому вы можете подключиться к экземпляру и исправить неправильные записи fstab.