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

Ответ 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.