Amazon EC2 - Brak SSH po ponownym uruchomieniu, odmowa połączenia

Powtórzyłem to dwa lub trzy razy, więc zgaduję, że coś jest nie tak z tym, co robię.

Oto moje kroki:

1. Uruchom nową instancję za pomocą konsoli zarządzania EC2 przy użyciu: Ubuntu Server 13.10 - ami-ace67f9c (64-bit)
2. Uruchom z ustawieniami domyślnymi (używając mojej istniejącej pary kluczy)
3. Instancja się rozpoczyna. Mogę SSH do niego za pomocą Putty lub terminala Mac. Sukces!
4. Ponownie uruchamiam instancję

5. 10 minut później, gdy instancja powinna zostać ponownie uruchomiona, moje połączenie terminalowe pokazuje:

   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$
   

Dobrze, rozumiem, że publiczny adres IP może się zmienić, więc sprawdzając konsolę zarządzania EC2, sprawdzam, czy jest taki sam. Dziwne. Dla zabawy próbuję połączyć się z publiczną nazwą hosta DNS: ec2-54-201-200-208.us-west-2.compute.amazonaws.com. Brak kości, ten sam wynik.

Nawet za pomocą Connect za pośrednictwem klienta Java SSH wbudowanego w konsolę EC2 otrzymuję odmowę połączenia.

Sprawdziłem grupy bezpieczeństwa. Ta instancja znajduje się w grupie launch-wizard-4. Patrząc na konfigurację przychodzącą dla tej grupy, port 22 jest dozwolony od 0.0.0.0/0, więc powinien być w dowolnym miejscu. Wiem, że uderzam w moją instancję i jest to odpowiednia grupa zabezpieczeń, ponieważ nie mogę pingować instancji. Jeśli włączę ICMP dla tej grupy zabezpieczeń, nagle moje pingi przechodzą.

Znalazłem kilka innych postów w Internecie z podobnymi komunikatami o błędach, ale większość z nich wydaje się łatwa do rozwiązania przez dostosowanie ustawień zapory. Próbowałem kilka z nich, bez powodzenia.

Domyślam się, że brakuje mi prostego kroku EC2. Dziękujemy za wszelką pomoc, którą chętnie udzielę, iz przyjemnością udzielę więcej informacji lub przetestuję dalej!

Aktualizacja - oto moje dzienniki systemowe z konsoli Amazon EC2: http://pastebin.com/4M5pwGRt

Miałem podobne zachowanie dzisiaj w mojej instancji ec2 i wyśledziłem następującą rzecz: kiedy robię, sudo reboot now komputer zawiesza się i muszę go ponownie uruchomić ręcznie z konsoli zarządzania aws, kiedy to robię sudo reboot , restartuje się dobrze. Najwyraźniej „teraz” nie jest prawidłową opcją ponownego uruchomienia, jak wskazano tutaj /ubuntu/397502/reboot-a-server-from-command-line

myśli?

Z postu Forum programistów AWS na ten temat :

Spróbuj zatrzymać uszkodzoną instancję, odłączyć wolumin EBS i dołączyć go jako wolumin dodatkowy do innej instancji. Po zamontowaniu uszkodzonego woluminu gdzieś w innym wystąpieniu sprawdź plik / etc / sshd_config (u dołu). Miałem kilka instancji RHEL, w których Yum przeglądał sshd_config wstawiając na dole zduplikowane linie, które powodowały błąd sshd podczas uruchamiania z powodu błędów składniowych.

Po naprawieniu wystarczy odmontować wolumin, odłączyć, ponownie podłączyć do drugiej instancji i ponownie uruchomić.

Podzielmy to z linkami do dokumentacji AWS:

1. Zatrzymaj uszkodzoną instancję i odłącz wolumin EBS (root), wchodząc do konsoli zarządzania EC2, klikając „Elastic Block Store”> „Woluminy”, klikając prawym przyciskiem myszy wolumin powiązany z zatrzymaną instancją.
2. Uruchom nową instancję w tym samym regionie i tym samym systemie operacyjnym co zepsuta instancja, a następnie dołącz oryginalny wolumin główny EBS jako wolumin dodatkowy do nowej instancji . Polecenia w kroku 4 poniżej zakładają, że podłączasz wolumin do folderu o nazwie „dane”.
3. Po zamontowaniu uszkodzonego woluminu gdzieś w innym wystąpieniu ,
4. sprawdź plik „/ etc / sshd_config” pod kątem zduplikowanych wpisów, wydając następujące polecenia:
   • cd /etc/ssh
   • sudo nano sshd_config
   • ctrl-v kilka razy, aby dostać się do dolnej części pliku
   • ctrl-k wszystkie wiersze u dołu wspominające „PermitRootLogin bez hasła” i „UseDNS nie”
   • ctrl-xoraz w Ycelu zapisania i wyjścia z edytowanego pliku
5. @Telegard wskazuje (w swoim komentarzu) , że naprawiliśmy tylko symptom. Możemy naprawić przyczynę , komentując 3 powiązane wiersze w pliku „/etc/rc.local”. Więc:
   • cd /etc
   • sudo nano rc.local
   • poszukaj linii „PermitRootLogin ...” i usuń je
   • ctrl-xoraz w Ycelu zapisania i wyjścia z edytowanego pliku
6. Po naprawieniu po prostu odmontuj głośność ,
7. odłącz, wchodząc do konsoli zarządzania EC2, klikając „Elastic Block Store”> „Woluminy”, klikając prawym przyciskiem myszy wolumin związany z zatrzymaną instancją,
8. podłącz ponownie do innej instancji i
9. odpal go ponownie .

Może to wcale nie pomóc w tej sytuacji, ale widziałem kilka przypadków, w których restart EC2 „blokuje się”. Jeśli wykonasz „reset” na maszynie wirtualnej, a następnie przywrócisz dzienniki systemowe, może to zmienić zachowanie. Upewnij się, że dzienniki pochodzą z drugiego rozruchu, a nie pierwszego - są one opóźnione przy aktualizacjach.

Inną sprawą do sprawdzenia jest upewnienie się, że instancja odpowiada na adres IP. Wygląda na to, że połączenie zostało odrzucone powyżej, co wydaje się, że instancja jest uruchomiona, ale SSH nie działa lub jest zaporą ogniową, ale upewnij się, że instancja została w pełni uruchomiona ponownie.

Możesz także spróbować otworzyć wszystkie porty z systemu testowego i zobaczyć, co pokazuje „nmap” - czy są inne usługi odpowiadające na instancję.

Kliknij prawym przyciskiem myszy nazwę instancji i kliknij „Zmień grupy zabezpieczeń”. Upewnij się, że utworzona grupa zabezpieczeń, która zezwala każdemu z dowolnego miejsca na port 22, jest sprawdzona i zastosowana do tego wystąpienia.

Ten problem wystąpił po wykonaniu sudo reboot nowSSH na moim serwerze EC2 z systemem Ubuntu 14.04. Działa dobrze po ponownym uruchomieniu komputera za pomocą konsoli zarządzania EC2.

W moim przypadku skonfigurowałbym grupę zabezpieczeń, aby zezwalać na połączenia z portem 22 tylko z mojego adresu IP. Kilka dni później mój dostawca usług internetowych zmienił mój adres IP, dlatego grupa zabezpieczeń wymaga aktualizacji.

Miałem podobny problem, moja instancja EC2 Amazon Linux nie była już dostępna po ponownym uruchomieniu sudo .

Brak dostępu do SSH, polecenia stop / start / restart z konsoli administracyjnej Amazon nie dały mi również rezultatu.

W końcu mogłem zrestartować instancję, tworząc obraz za pomocą konsoli Amazon. Wydaje się, że proces tworzenia obrazu naprawia stan instancji.

Mam nadzieję, że to pomoże ;)

Miałem ten sam problem po uruchomieniu sudo rebootpolecenia waniliowego . Odkryłem, że udało mi się rozwiązać problem, całkowicie zatrzymując (nie restartując) mój interfejs AMI za pomocą konsoli AWS, a następnie uruchamiając go ponownie.

Z jakiegokolwiek powodu zrestartowanie AMI z konsoli AWS, jak kliknięcie akcji restartu w przeciwieństwie do zatrzymania, a następnie uruchomienia instancji, nie rozwiązało problemu.

Jak wspomniano, prawdopodobnie pomieszałeś z / etc / fstab /

Miałem ten problem. Najpierw musisz ponownie dodać wolumin w katalogu / dev / sda1, jak mówi komunikat ostrzegawczy.

Więc nie mogłem ssh. Uświadomiłem sobie, że muszę dodać drugi utworzony wolumin i to rozwiązało problem z ssh.

Następnie możesz się zalogować i naprawić fstab z powrotem do oryginału.