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

17

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 [email protected]
    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

SteadH
źródło
2
Sugerowałbym, aby zajrzeć do dzienników systemowych na konsoli AWS, aby zobaczyć, czy nie powiedzie się, że coś poszło nie tak podczas ponownego uruchamiania, możesz mieć pewność, że obie kontrole dostępności przebiegną po ponownym uruchomieniu systemu i podczas próby ssh (na konsoli tylko)
APZ
2
Nie zrobiłeś nic po pierwszym połączeniu? Brak bałaganu w tabelach IP lub plikach konfiguracyjnych sshd? Ponieważ wygląda na to, że zrywasz połączenie, a port 22 nie jest dostępny.
typositoire
Czy bałagan /etc/fstabprzed ponownym uruchomieniem?
David Levesque
Bez zmiany iptables lub fstab przed ponownym uruchomieniem. Pierwsze polecenie, które uruchomiłem, brzmiało: „uruchom ponownie teraz”. Zaktualizuję powyższe moje dzienniki systemowe AWS
SteadH,
Również sprawdzanie statusu jest dobre - 2/2! Miałem nadzieję, że miałem coś prostego w mojej konfiguracji ... może nie!
SteadH

Odpowiedzi:

6

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?

oromoiluig
źródło
Niesamowite! Próbowałem tego dzisiaj na mojej instancji i zadziałało. Dziękuję Ci!
SteadH
Link ten jest także zabawny, ponieważ zawsze używałem ponownego uruchomienia sudo jako metody ponownego uruchomienia Ubuntu Server. Dziwne!
SteadH
@oromoiluig jak można zrestartować komputer, jeśli nie jest w stanie ssh maszyny?
Vaibhav Kumar
1
@VaibhavKumar z konsoli AWS: wyłącz instancję i włącz ją ponownie.
oromoiluig
17

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 .
Jeromy French
źródło
To pytanie może być również istotne: serverfault.com/q/325140/153062
Jeromy French
Ten sam problem i podobna proponowana poprawka na stackoverflow.com/a/21563478/1430996 Komentarz jest szczególnie pomocny.
Jeromy French
Dzięki za to! Podejrzewam, że rozwiązałoby to problem i jest to dobry sposób na uzyskanie dostępu do tego dziennika SSH. Dzięki!
SteadH
To działało, dzięki. Chociaż mój problem (ten sam symptom: „odmowa połączenia”) wynikał z niewłaściwej własności katalogu / var / empty / sshd. Powinien to być root: root. Dlaczego to się zmieniło: nie mam pojęcia, nigdy go nawet nie zamknęliśmy. No cóż.
cucu8
@JeromyFrench Mam ten sam problem. Postępowałem zgodnie z procedurą, ale nie dostałem „PermitRootLogin bez hasła”. Ma „PermitRootLogin = zabronić-hasło”. Co powinienem zrobić?
Vaibhav Kumar
0

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ę.

Nathan Neulinger
źródło
-1

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.

shaimoom
źródło
-2

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.

Kris Khaira
źródło
-2

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.

redcalx
źródło
-2

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 ;)

Romain Pellerin-Rezzi
źródło
-2

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.

ACV
źródło
-3

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.

użytkownik3555158
źródło
Brak edycji fsab, po prostu polecenie restartu.
SteadH