Amazon EC2 - Немає SSH після перезавантаження, з'єднання відмовлено

Я повторював це два-три рази, тому я здогадуюсь, що щось не так у тому, що я роблю.

Ось мої кроки:

1. Запустіть новий екземпляр через консоль управління EC2, використовуючи: Ubuntu Server 13.10 - ami-ace67f9c (64-розрядний)
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, я переконуюсь, що вона однакова. Дивно. Для розваги я намагаюся з'єднатись із загальнодоступним іменем DNS: ec2-54-201-200-208.us-west-2.compute.amazonaws.com. Без кісток, такий же результат.

Навіть використовуючи клієнт Connect через Java SSH, вбудований в консоль EC2, я отримую відмову від підключення.

Я перевірив групи безпеки. Цей екземпляр знаходиться в групі майстра запуску-4. Переглядаючи вхідну конфігурацію для цієї групи, порт 22 дозволений з 0,0.0.0/0, так що він повинен бути де завгодно. Я знаю, що я потрапляю на свою інстанцію, і це правильна група безпеки, тому що я не можу пінг-екземпляр. Якщо я ввімкну ICMP для цієї групи безпеки, раптом мої пінги пройдуться.

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

Я здогадуюсь, простий крок EC2, який я пропускаю. Дякуємо за будь-яку допомогу, яку ви можете надати, і я радий надати більше інформації або перевірити далі!

Оновлення - Ось мої системні журнали з консолі Amazon EC2: http://pastebin.com/4M5pwGRt

Мав подібну поведінку сьогодні на моєму екземплярі ec2, і відслідковував це до цього: коли я працюю, sudo reboot now машина зависає, і мені доведеться перезапустити її вручну з консолі управління aws, коли я sudo reboot це перезавантажую. Мабуть, "зараз" не є допустимим варіантом для перезавантаження, як зазначено тут /ubuntu/397502/reboot-a-server-from-command-line

думки?

З допису на цю тему на форумі розробників AWS :

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

Після того, як ви виправите це, просто відключіть гучність, від'єднайте, приєднайте знову до іншого екземпляра та заново створіть його.

Розберемо це з посиланнями на документацію AWS:

1. Зупиніть порушений екземпляр і від'єднайте об'єм EBS (root), зайшовши в консоль управління EC2, натиснувши "Elastic Block Store"> "Volumes", клацнувши правою кнопкою миші на томі, пов'язаному з екземпляром, який ви зупинили.
2. Запустіть новий екземпляр у тому самому регіоні та тій самій ОС, що і розбитий екземпляр, а потім приєднайте до нового примірника вихідний кореневий том EBS як вторинний том . Команди на кроці 4 нижче передбачають, що ви змонтуєте гучність у папці під назвою "дані".
3. Після того, як ви змонтували розбитий том десь в іншому екземплярі ,
4. перевірити файл "/ etc / sshd_config" на наявність дублікатів записів, видавши ці команди:
   • cd /etc/ssh
   • sudo nano sshd_config
   • ctrl-v купа разів, щоб дістатися до нижньої частини файлу
   • ctrl-k всі рядки внизу згадують "PermitRootLogin без пароля" та "UseDNS ні"
   • 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"> "Volumes", клацнувши правою кнопкою миші на томі, пов’язаному з екземпляром, який ви зупинили,
8. повторно приєднайте до іншого інстанції та
9. запустити його знову .

Це може не допомогти жодній ситуації, але я бачив випадки, коли перезавантаження на EC2 "застрягло". Якщо ви зробите «скидання» на VM і потім відновите системні журнали, це може змінити поведінку. Будьте впевнені, що журнали ведуться з другого завантажувального, а не першого - вони, як правило, затримуються з оновленнями.

Ще одне, що потрібно перевірити, - це бути впевненим, що екземпляр реагує на IP. Ви, здається, отримуєте з'єднання, відхилене вище, що здається, що екземпляр працює, але SSH не працює або скасовується, але будьте впевнені, що екземпляр повністю перезавантажився.

Ви також можете спробувати відкрити всі порти з тестової системи, і побачити, що показує 'nmap' - чи відповідають інші служби на екземпляр.

Клацніть правою кнопкою миші назву екземпляра та натисніть «Змінити групи безпеки». Переконайтеся, що група захисту, яку ви створили, яка дозволяє будь-кому з будь-якого місця на порт 22, перевірена та застосована до цього примірника.

Цю проблему я отримав після роботи sudo reboot nowчерез SSH на сервері EC2 під керуванням Ubuntu 14.04. Відмінно спрацював після перезавантаження знову за допомогою консолі управління EC2.

У моєму випадку я створив групу захисту, щоб дозволити підключення до порту 22 тільки з мого IP. Через кілька днів мій Інтернет-провайдер змінив мою IP-адресу, отже, група безпеки потребує оновлення.

У мене була подібна проблема, мій екземпляр EC2 Amazon Linux вже не був доступний після запуску перезавантаження sudo .

Немає доступу до SSH, зупинки / запуску / перезавантаження команд з консолі адміністратора Amazon теж не дало результату.

Нарешті я зміг перезапустити свій примірник, створивши зображення через консоль Amazon. Процес створення зображення, здається, фіксує стан екземпляра.

Сподіваюся, це допомагає;)

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

З будь-якої причини перезапуск AMI з консолі AWS, як при натисканні дії перезапуску на відміну від зупинки та запуску екземпляра, не усунув проблему.

Як згадувалося, ви, ймовірно, заплуталися з / etc / fstab /

У мене була ця проблема. Спочатку вам потрібно знову додати гучність у / dev / sda1, як йдеться у попереджувальному повідомленні.

Тоді я не міг ssh. Я зрозумів, що мені потрібно додати інший створений мені том, і це вирішило проблему ssh.

Потім ви можете увійти та виправити fstab назад до оригіналу.