Amazon EC2 - никакой SSH после перезагрузки, соединения, которому отказывают
Автомонтирование сетевых ресурсов означает хранить учетные данные в файле где-нибудь где mount может считать их (через credentials=filename смонтируйте опцию в случае cifs файловых систем) - это - не обязательно проблема, но могло быть проблемой безопасности даже вне использования, дающего кому-то доступ к сценарию. При хранении учетных данных в файлы как это более безопасны, чем хранение их в сценарии непосредственно потому что тот путь, там не шанс, они появятся на командных строках, когда пользователи будут искать список задач с ps или подобный, но жизненно важно, чтобы Вы удостоверились, что только сценарий может считать файл. Вы касаетесь о пользователях, которые идут на компромисс, сервер не отличается в этой ситуации - если они поставят под угрозу его, в то время как это живо, у них потенциально будет доступ к долям так или иначе.
Стоимость монтирования и размонтирования долей не должна быть значительной - несколько секунд (если это) самое большее, если Вы не говорите с долями по очень медленному соединению высокой задержки и можете быть предпочтительными с точки зрения безопасности, потому что Вы не сохраняете долю смонтированной (потенциально способом, который мог бы оставить это читаемым другим пользователям с доступом), когда это будет не нужно, и другой конец сможет журнал, когда Ваши сценарии проходят проверку подлинности и разъединяются (поэтому, если существует обнаруженная проблема с другой стороны, легче отследить то, что, возможно, имело доступ в то время, когда проблема, кажется, произошла).
Хранение долей, смонтированных несмотря на перекрывающееся выполнение сценария, могло быть сделано путем отбрасывания файла со случайным (или иначе достаточно вряд ли быть дублированными другим вызовом сценария) имя в некотором месте (скажите что каталог под /var/run) и удаляя тот файл после того, как фактическое задание сценария закончилось - чем при самой проверке конца, что нет никаких других файлов в том каталоге перед выполнением umount. Другой метод должен был бы позволить несколько монтирования той же доле путем предоставления каждому сценарию ее собственной точки монтирования - этот способ, которым каждый сценарий будет иметь свою собственную долю и не вмешался бы в другие, и Вы могли также дать каждому сценарию его собственные учетные данные аутентификации, таким образом, у Вас есть опция руководящих полномочий более мелкомодульным способом в другой стороне (возможно, для некоторых сценариев нужен read+write доступ, и немного только нужно только для чтения, например).
Похожее поведение сегодня было на моем примере ec2, и отследил его до этого:
когда я делаю
перезагрузиться сейчас
машина зависает, и я должен перезапустить ее вручную из консоли управления aws.
когда я делаю
sudo reboot
он прекрасно перезагружается.
Очевидно, что "сейчас" не является подходящим вариантом для перезагрузки, как указано здесь https://askubuntu.com/questions/397502/reboot-a-server-from-command-line
мысли?
.Это может не помочь ситуации, но я видел некоторые случаи, когда перезагрузка на EC2 "зависает". Если вы выполните «сброс» на виртуальной машине, а затем получите системные журналы, это может изменить поведение. Убедитесь, что журналы относятся ко второй загрузке, а не первой - они, как правило, задерживаются при обновлении.
Еще одна вещь, которую необходимо проверить, - убедиться, что экземпляр отвечает по IP. Вы, кажется, получаете отказ в соединении выше, что звучит так, как будто экземпляр запущен, но SSH не работает или защищен брандмауэром, но убедитесь, что экземпляр полностью перезагружен.
Вы также можете попробовать открыть все порты из тестовой системы и посмотреть, что показывает «nmap» - какие-либо другие службы отвечают на этот экземпляр.
Щелкните правой кнопкой мыши имя экземпляра и выберите «Изменить группы безопасности». Убедитесь, что созданная вами группа безопасности, разрешающая любому пользователю подключаться к порту 22, отмечена и применена к этому экземпляру.
В документации , упомянутой Райаном , отсутствует 2 Параметры NTDSettings, необходимые для поддержки всех комбинаций. прикрепить его как дополнительный том к другому экземпляру. Как только вы смонтировал сломанный том где-нибудь на другом экземпляре, проверьте / etc / sshd_config (внизу). У меня было несколько экземпляров RHEL где Yum проверял sshd_config, вставляя повторяющиеся строки в снизу, что приводило к сбою sshd при запуске из-за синтаксических ошибок.
После того, как вы исправили это, просто отключите том, отсоедините, снова подключите к ваш другой экземпляр и снова запустите его.
Давайте разберемся со ссылками на документацию AWS:
- Остановите сломанный экземпляр и отсоедините том EBS (корневой), войдя в консоль управления EC2 , щелкнув «Elastic Block Store»> «Тома», щелкнув правой кнопкой мыши том, связанный с остановленным экземпляром.
- Запустить новый экземпляр в том же регионе и той же ОС, что и сломанный экземпляр. затем присоедините исходный корневой том EBS в качестве дополнительного тома к новому экземпляру . Команды на шаге 4 ниже предполагают, что вы монтируете том в папку с именем «data».
- После того, как вы смонтировали сломанный том где-нибудь в другом экземпляре ,
- проверьте "/ etc / sshd_config "
cd / etc / sshsudo nano sshd_configctrl-vнесколько раз, чтобы добраться до конца файлаctrl-kвсе строки внизу упоминание «PermitRootLogin без пароля» и «UseDNS no»ctrl-xиYдля сохранения и выхода из отредактированного файла
- @Telegard указывает (в своем комментарии ) , что мы только устранили симптом. Мы можем исправить причину , закомментировав 3 связанные строки в файле "/etc/rc.local". Так:
cd / etcsudo nano rc.local- найдите строки «PermitRootLogin ...» и удалите их
ctrl-xиYдля сохранения и закрыть отредактированный файл
- После того, как вы исправили его, просто отключите том ,
- отключите, войдя в консоль управления EC2, нажав «Elastic Block Store»> «Volumes», щелкнув правой кнопкой мыши том, связанный с остановленным экземпляром,
- повторно подключите его к другому экземпляру и
- снова запустите его .
Я получил эту проблему после того, как сделал sudo перезагрузки сейчас через SSH на моем EC2 сервере под управлением Ubuntu 14.04. После повторной перезагрузки с помощью консоли управления EC2 работала нормально
У меня была аналогичная проблема, мой экземпляр EC2 Amazon Linux больше не был доступен после запуска sudo reboot .
Отсутствие доступа по SSH, команды остановки / запуска / перезагрузки из консоли администратора Amazon тоже не дали мне результата.
Я наконец смог перезапустить свой экземпляр, создав образ через консоль Amazon. Похоже, что процесс создания образа исправляет состояние экземпляра.
Надеюсь, это поможет;)
В моем случае я бы настроил группу безопасности, чтобы разрешить подключения к порту 22 только с моего IP. Несколько дней спустя мой интернет-провайдер изменил мой IP-адрес, поэтому группу безопасности необходимо обновить.
Как уже упоминалось, вы, вероятно, испортили файл / etc / fstab /
. У меня была эта проблема. Сначала вам нужно повторно добавить том в / dev / sda1, как говорится в предупреждающем сообщении.
Тогда я не мог использовать ssh. Я понял, что мне нужно добавить другой том, который я создал, и это устранило проблему ssh.
Затем вы можете войти в систему и восстановить исходный файл fstab.
У меня была такая же проблема после выполнения ванильной команды sudo reboot . Я обнаружил, что смог решить проблему, полностью остановив (не перезагружая) свой AMI с помощью консоли AWS, а затем запустив его резервную копию.
По какой-либо причине перезапуск AMI из консоли AWS, например, щелчок по действию перезапуска вместо остановки и последующего запуска экземпляра, не решил проблему.