Amazon EC2 – Nu există SSH după repornire, Conexiune refuzată (Administrarea sistemului, Ssh, Amazon Ec2, Cloud)

SteadH a intrebat.
a intrebat.

Am replicat acest lucru de două sau trei ori, așa că bănuiesc că este ceva în neregulă cu ceea ce fac.

Iată pașii mei:

  1. Lansați o nouă instanță prin intermediul consolei EC2 Management console folosind: Ubuntu Server 13.10 – ami-ace67f9c (64 biți)
  2. Lansare cu valorile implicite (folosind perechea mea de chei existentă)
  3. Instanța pornește. Pot să mă conectez SSH la ea folosind Putty sau terminalul Mac. Succes!
  4. Repornesc instanța
  5. 10 minute mai târziu, când instanța ar trebui să fie din nou funcțională, conexiunea mea la terminal arată:

    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$
    

Bine, înțeleg că adresa IP publică se poate schimba, așa că, verificând consola de management EC2, verific că este aceeași. Ciudat. Doar ca să mă distrez, încerc să mă conectez cu numele de gazdă DNS public: ec2-54-201-200-208.us-west-2.compute.amazonaws.com. Nici un zar, același rezultat.

Chiar și folosind clientul Connect via Java SSH integrat în consola EC2, primesc Connection Refused (Conexiune refuzată).

Am verificat grupurile de securitate. Această instanță se află în grupul launch-wizard-4. Dacă mă uit la configurația de intrare pentru acest grup, portul 22 este permis de la 0.0.0.0.0/0, deci ar trebui să fie oriunde. Știu că am nimerit instanța mea și că acesta este grupul de securitate corect, deoarece nu pot face ping la instanță. Dacă activez ICMP pentru acest grup de securitate, dintr-o dată, ping-urile mele trec.

Am mai găsit câteva mesaje pe internet cu mesaje de eroare similare, dar majoritatea par să fie ușor de rezolvat prin modificarea setărilor firewall-ului. Am încercat câteva dintre acestea, fără succes.

Bănuiesc că există un pas EC2 simplu pe care îl ratez. Mulțumesc pentru orice ajutor pe care îl puteți oferi și sunt bucuros să ofer mai multe informații sau să testez mai departe!

Actualizare – Iată jurnalele mele de sistem din consola Amazon EC2: http://pastebin.com/4M5pwGRt

Comentarii

  • V-aș sugera să vă uitați în jurnalele de sistem de pe consola AWS pentru a vedea dacă spune că ceva nu a mers bine în timpul repornirii , ați putea dori să vă asigurați că ambele verificări de accesibilitate trec atunci când sistemul repornește și când u încearcă să ssh (numai pe consolă) –  > Por APZ.
  • Nu ați făcut nimic după prima conexiune ? Nu ați umblat la tabelele IP sau la fișierele de configurare sshd ? Pentru că se pare că renunți la conexiune nu că portul 22 nu este disponibil. –  > Por typositoire.
  • Ați umblat cu /etc/fstab înainte de a reporni? –  > Por David Levesque.
  • Nici o modificare a iptables sau fstab înainte de repornire. Prima comandă pe care am rulat-o a fost „reboot now” Voi actualiza cele de mai sus cu jurnalele mele de sistem AWS.  > Por SteadH.
  • De asemenea, verificările de stare sunt ambele bune – 2/2! Speram că am avut ceva simplu în neregulă cu configurația mea… poate că nu! –  > Por SteadH.
9 răspunsuri
oromoiluig

A avut un comportament similar astăzi pe instanța mea ec2, și a urmărit lucrul la acest lucru: când fac sudo reboot nowmașina se blochează și trebuie să o repornesc manual din consola de administrare awscând facsudo rebootse repornește foarte bine. se pare că „acum” nu este o opțiune validă pentru repornire, așa cum se arată aici https://askubuntu.com/questions/397502/reboot-a-server-from-command-line https://askubuntu.com/questions/397502/reboot-a-server-from-command-line

gânduri?

Comentarii

  • Minunat! Am încercat asta pe instanța mea astăzi și a funcționat. Vă mulțumesc! –  > Por SteadH.
  • De asemenea, acest link este amuzant pentru că am folosit întotdeauna sudo reboot now ca metodă de repornire a serverului meu Ubuntu. Ciudat! –  > Por SteadH.
  • @oromoiluig cum se poate reporni, dacă nu se poate ssh mașina? –  > Por Vaibhav Kumar.
  • @VaibhavKumar din consola AWS: opriți instanța și porniți-o din nou. –  > Por oromoiluig.
Jeromy French

De la postarea de pe forumul dezvoltatorilor AWS pe această temă:

Încercați să opriți instanța stricată, să detașați volumul EBS și să îl atașați ca volum secundar la o altă instanță. După ce ați montat volumul stricat undeva pe cealaltă instanță, verificați fișierul /etc/sshd_config (în partea de jos). Am avut câteva instanțe RHEL în care Yum a scrobit fișierul sshd_config inserând linii duplicate în partea de jos, ceea ce a făcut ca sshd să eșueze la pornire din cauza unor erori de sintaxă.

După ce ați rezolvat problema, demontați volumul, detașați-l, reatașați-l la cealaltă instanță și porniți-o din nou.

Haideți să deslușim acest lucru, cu linkuri către documentația AWS:

  1. Opriți instanța defectă și detașați volumul EBS (rădăcină), intrând în EC2 Management Console, făcând clic pe „Elastic Block Store” > „Volumes”, apoi făcând clic dreapta pe volumul asociat cu instanța pe care ați oprit-o.
  2. Porniți o nouă instanță în aceeași regiune și cu același sistem de operare ca și instanța oprită apoi atașați volumul rădăcină EBS original ca volum secundar la noua instanță. Comenzile din pasul 4 de mai jos presupun că montați volumul într-un dosar numit „data”.
  3. După ce ați montat volumul stricat undeva pe cealaltă instanță,
  4. verificați fișierul „/etc/sshd_config” pentru intrările duplicate, lansând aceste comenzi:
    • cd /etc/ssh
    • sudo nano sshd_config
    • ctrl-v de mai multe ori pentru a ajunge la sfârșitul fișierului
    • ctrl-k toate liniile din partea de jos care menționează „PermitRootLogin without-password” și „UseDNS no”.
    • ctrl-x și Y pentru a salva și a ieși din fișierul editat
  5. @Telegard atrage atenția (în comentariul său) că am rezolvat doar simptomul. Putem remedia cauza prin comentarea celor 3 linii aferente din fișierul „/etc/rc.local”. Astfel:
    • cd /etc
    • sudo nano rc.local
    • căutați liniile „PermitRootLogin…” și ștergeți-le
    • ctrl-x și Y pentru a salva și ieși din fișierul editat
  6. După ce ați rezolvat problema, trebuie doar să demontați volumul,
  7. detașați intrând în EC2 Management Console, făcând clic pe „Elastic Block Store” > „Volumes”, apoi făcând clic dreapta pe volumul asociat cu instanța pe care ați oprit-o,
  8. reatașați la cealaltă instanță și
  9. porniți-o din nou..

Comentarii

  • Această întrebare ar putea fi, de asemenea, relevantă: serverfault.com/q/325140/153062 –  > Por Jeromy French.
  • Aceeași problemă și o soluție similară propusă la stackoverflow.com/a/21563478/1430996 Comentariul este deosebit de util. –  > Por Jeromy French.
  • Vă mulțumim pentru acest lucru! Bănuiesc că acest lucru ar fi rezolvat problema, iar aceasta este o modalitate bună de a ajunge la acel jurnal SSH. Vă mulțumim! –  > Por SteadH.
  • Acest lucru a funcționat, mulțumesc. Deși problema mea (același simptom: „connection refused”) se datora proprietății greșite a dir-ului /var/empty/sshd. Ar fi trebuit să fie root:root. De ce s-a schimbat: nici o idee, nici măcar nu am fost niciodată aproape de el. Oh, bine. –  > Por cucu8.
  • @JeromyFrench Și eu am aceeași problemă. Am urmat procedura, dar nu am primit ‘”PermitRootLogin without-password”‘. Are „PermitRootLogin=prohibit-password”. Ce ar trebui să fac? –  > Por Vaibhav Kumar.
Nathan Neulinger

Este posibil să nu ajute cu nimic situația, dar am văzut unele cazuri în care o repornire pe EC2 se „blochează”. Dacă faceți o „resetare” pe VM și apoi redați jurnalele de sistem, s-ar putea să se schimbe comportamentul. Asigurați-vă că jurnalele sunt de la a doua pornire și nu de la prima – acestea tind să fie întârziate la actualizări.

Un alt lucru pe care trebuie să-l verificați este să vă asigurați că instanța răspunde la IP. Se pare că primiți o conexiune refuzată mai sus, ceea ce sună ca și cum instanța este activă, dar SSH nu rulează sau este blocată prin firewall, dar asigurați-vă că instanța a repornit complet.

De asemenea, ați putea încerca să deschideți toate porturile de pe un sistem de testare și să vedeți ce vă arată „nmap” – dacă există și alte servicii care răspund pe instanță.

shaimoom

Faceți clic dreapta pe numele instanței și faceți clic pe „Change Security Groups”. Asigurați-vă că grupul de securitate pe care l-ați creat și care permite oricui de oriunde să acceseze portul 22 este bifat și aplicat acestei instanțe.

Romain Pellerin-Rezzi

Am avut o problemă similară, instanța mea EC2 Amazon Linux nu a mai fost accesibilă după ce am rulat sudo reboot.

Nu există acces SSH, comenzile de oprire / pornire / repornire din consola de administrare Amazon nu mi-au dat nici un rezultat.

Am reușit în cele din urmă să repornesc instanța mea prin crearea unei imagini prin intermediul consolei Amazon. Procesul de creare a imaginii pare să repare starea instanței.

Sper că vă ajută 😉

Kris Khaira

Am avut această problemă după ce am făcut sudo reboot now prin SSH pe serverul meu EC2 care rulează Ubuntu 14.04. A funcționat bine după ce am repornit din nou folosind EC2 Management Console.

redcalx

În cazul meu, am configurat un grup de securitate pentru a permite conexiuni la portul 22 doar de la IP-ul meu. Câteva zile mai târziu, ISP-ul meu mi-a schimbat adresa IP, prin urmare grupul de securitate trebuie actualizat.

ACV

Am avut aceeași problemă după ce am rulat un vanilla sudo reboot comandă. Am constatat că am reușit să rezolv problema oprind complet (nu repornind) AMI-ul meu folosind consola AWS și apoi pornindu-l din nou.

Indiferent de motiv, repornirea AMI din consola AWS, adică făcând clic pe acțiunea de repornire, spre deosebire de oprirea și apoi pornirea instanței, a făcut ca nu nu a rezolvat problema.

utilizator355555158

După cum s-a menționat, probabil că ați modificat fișierul /etc/fstab/

Eu am avut această problemă. În primul rând trebuie să adăugați din nou volumul la /dev/sda1 așa cum spune mesajul de avertizare.

Apoi nu am putut să fac ssh. Mi-am dat seama că trebuia să adaug celălalt volum pe care l-am creat și asta a rezolvat problema ssh.

Apoi puteți să vă conectați și să reparați fstab-ul înapoi la original.

Comentarii

  • Nu editați fsab, doar o comandă de repornire. –  > Por SteadH.