wake-up-neo.net

Die Ausführung der EC2-Instanz lehnt die SSH-Verbindung plötzlich ab

Ich habe die EC2-Instanz vor ein paar Tagen eingerichtet und sogar letzte Nacht konnte ich ohne Probleme SSH machen. Heute morgen kann ich nicht ssh dazu. Port 22 ist bereits in der Sicherheitsgruppe geöffnet, und ich habe seit gestern Nacht nichts geändert.

Error:

ssh: connect to Host [ip address] port 22: Connection refused

Ich hatte kürzlich ein ähnliches Problem, und ich konnte nicht herausfinden, warum es geschah. Daher musste ich eine neue Instanz erstellen, sie erneut einrichten und alle EBS-Speicher mit der neuen verbinden und konfigurieren. Ich habe ein paar Stunden gebraucht ... und jetzt passiert es wieder. In der vorherigen Version habe ich denyhost installiert, was mich möglicherweise blockiert hat, aber in der aktuellen Version sind nur Apache2 und mysql aktiv.

Die aktuelle Instanz ist jetzt seit 16 Stunden in Betrieb, daher glaube ich nicht, dass der Startvorgang nicht abgeschlossen wurde. Außerdem ist Port 22 für alle Quellen offen (0.0.0.0/0) und verwendet das TCP-Protokoll. 

Irgendwelche Ideen?

Vielen Dank.

19
Sherzod

Mit Hilfe von @ abhi.gupta200297 konnten wir das Problem lösen.

Das Problem war der Fehler in /etc/fstab, und sshd sollte gestartet werden, nachdem fstab erfolgreich war. Es war aber nicht so, dass die sshd nicht starten würde und deswegen lehnte sie die Verbindung ab. Die Lösung bestand darin, eine temporäre Instanz zu erstellen, das Root-EBS aus der ursprünglichen Instanz zu mounten und Dinge aus der Variablen fstab und voila auszukommentieren, damit ich mich erneut verbinden kann. Und für die Zukunft habe ich einfach aufgehört, fstab zu verwenden, und erstellte eine Reihe von Shell-Befehlen, um die EBS-Volumes in Verzeichnisse zu mounten, und fügte sie in /etc/init.d/ebs-init-mount-Datei hinzu. Anschließend führe ich update-rc.d ebs-init-mount defaults aus, um die Datei zu initialisieren.

UPDATE 23.04.2015

Das Amazon-Team hat ein Video-Tutorial zu einem ähnlichen Problem erstellt und zeigt, wie mit dieser Methode debuggt wird: https://www.youtube.com/watch?v=_P29ZHu_feU

25
Sherzod

Sieht so aus, als hätte sshd aus irgendeinem Grund aufgehört. Wird die Instanz EBS unterstützt? Wenn dies der Fall ist, versuchen Sie es herunterzufahren und wieder hochzufahren. Das sollte das Problem lösen.

Können Sie auch von der AWS-Webkonsole aus ssh verwenden? Sie haben dort ein Java-Plugin für ssh in die Instanz.

6

Für diejenigen von Ihnen, die auf diesen Beitrag gestoßen sind, weil Sie nach einem Neustart keine SSH in Ihre EC2-Instanz einfügen können, dies ist ein Cross-Posting an eine ähnliche Frage an Serverfault :

Von dem AWS Developer Forum-Post zu diesem Thema

Versuchen Sie, die beschädigte Instanz anzuhalten, das EBS-Volume zu entfernen und Als sekundäres Volume an eine andere Instanz anzuhängen. Wenn Sie das beschädigte Volume irgendwo in der anderen Instanz gemountet haben, überprüfen Sie die Datei /Etc/sshd_config (unten). Ich hatte ein paar RHEL-Instanzen , Bei denen Yum die sshd_config-Datei gescroggt hat, wobei am Ende Doppelte Zeilen eingefügt wurden, die dazu führten, dass sshd beim Start aufgrund von Syntaxfehlern fehlschlug.

Sobald Sie das Problem behoben haben, nehmen Sie die Bereitstellung des Volumes auf, trennen Sie es, fügen Sie es erneut zu Ihrer anderen Instanz hinzu und starten Sie es erneut.

Lassen Sie uns dies mit Links zur AWS-Dokumentation aufschlüsseln:

  1. Stoppen Sie die beschädigte Instanz und trennen Sie das EBS-Volume (Root-Volume), indem Sie in der EC2-Verwaltungskonsole auf "Elastic Block Store"> "Volumes" klicken und mit der rechten Maustaste auf das Volume klicken, das der angehaltenen Instanz zugeordnet ist.
  2. Starten Sie eine neue Instanz in derselben Region und im gleichen Betriebssystem wie die beschädigte Instanz und und fügen Sie das ursprüngliche EBS-Root-Volume als sekundäres Volume an Ihre neue Instanz an . Bei den Befehlen in Schritt 4 wird davon ausgegangen, dass Sie das Volume in einem Ordner mit dem Namen "data" einhängen.
  3. Sobald Sie das defekte Volume irgendwo in der anderen Instanz gemountet haben ,
  4. Überprüfen Sie die Datei "/ etc/sshd_config" auf die doppelten Einträge, indem Sie die folgenden Befehle ausgeben:
    • cd /etc/ssh
    • Sudo nano sshd_config
    • ctrl-v ein paar Mal, um an die Unterseite der Datei zu gelangen
    • ctrl-k alle Zeilen unten mit "PermitRootLogin without-password" und "UseDNS no"
    • ctrl-x und Y zum Speichern und Beenden der bearbeiteten Datei
  5. @Telegardweist darauf hin (in seinem Kommentar) , dass wir nur das Symptom behoben haben. Wir können die cause beheben, indem wir die 3 zugehörigen Zeilen in der Datei "/etc/rc.local" auskommentieren. So:
    • cd /etc
    • Sudo nano rc.local
    • suchen Sie nach den Zeilen "PermitRootLogin ..." und löschen Sie sie
    • ctrl-x und Y zum Speichern und Beenden der bearbeiteten Datei
  6. Wenn Sie das Problem behoben haben, entfernen Sie einfach die Lautstärke
  7. klicken Sie zum Öffnen der EC2-Verwaltungskonsole auf "Elastic Block Store"> "Volumes". Klicken Sie mit der rechten Maustaste auf das Volume, das der angehaltenen Instanz zugeordnet ist. 
  8. wieder zu Ihrer anderen Instanz hinzufügen und 
  9. feuere es wieder hoch .
5
Jeromy French

Dies ist mir in einer Red Hat EC2-Instanz passiert, da diese beiden Zeilen bei jedem Start meiner Instanz automatisch an das Ende der Datei/etc/ssh/sshd_config angehängt wurden:

PermitRootLogin ohne Kennwort
UseDNS Nr

Eine dieser Anfügeoperationen wurde ohne Zeilenumbruch ausgeführt, daher sah das Ende der Datei sshd_config folgendermaßen aus:

PermitRootLogin ohne Kennwort
UseDNS noPermitRootLogin ohne Kennwort
UseDNS Nr

Dadurch konnte sshd beim nächsten Start nicht gestartet werden. Ich denke, dass dies durch den hier gemeldeten Fehler verursacht wurde: https://bugzilla.redhat.com/show_bug.cgi?id=956531 Die Lösung bestand darin, alle doppelten Einträge am Ende der Datei sshd_config zu entfernen, und Fügen Sie am Ende zusätzliche Zeilenumbrüche ein.

4
ianmcook

Gehen Sie zu Ihrer AWS-Verwaltungskonsole> Instanz auswählen> klicken Sie mit der rechten Maustaste und wählen Sie "Systemprotokolle abrufen" . Hier wird aufgelistet, was schief gegangen ist. 

1
Stewie

Ich habe ähnliche ssh durch das Trennen eines EBS gesperrt, habe aber vergessen, die/etc/fstab zu ändern

0
wdanxna

Hatte das gleiche Problem, aber Sys-Protokolle hatten diese:

Starten von sshd:/var/empty/sshd muss im Besitz von root sein und darf nicht von einer Gruppe oder einer Welt geschrieben werden. [GESCHEITERT]

Gehen Sie wie oben beschrieben vor, um das Volume zu trennen und eine Verbindung zur verbindbaren Instanz herzustellen. Dann verwendet:

Sudo chmod 755/var/empty/sshd

Sudo chown root: root/var/empty/sshd

( https://support.Microsoft.com/en-us/help/4092816/ssh-fails-because-var-empty-sshd-is-not-owned-by-root-and-is-not -Gruppe )

Anschließend wurde die Verbindung zur ursprünglichen EC2-Instanz getrennt und wieder hergestellt. Der Zugriff erfolgte nun über ssh.

0
user3473534

Wenn dein Ubuntu systemd hat, kannst du /lib/systemd/system/local-fs.target und kommentiere die letzten beiden Zeilen aus:

#OnFailure=emergency.target
#OnFailureJobMode=replace-irreversibly

Ich habe dies nicht ausgiebig getestet und weiß nicht, ob es Risiken oder Nebenwirkungen gibt, aber bisher funktioniert es wie ein Zauber. Das Root-Volume und alle anderen Volumes (mit Ausnahme derjenigen, die offensichtlich falsch konfiguriert sind) werden gemountet. Anschließend wird der Startvorgang fortgesetzt, bis SSH aktiv ist, sodass Sie eine Verbindung zur Instanz herstellen und die falschen fstab -Einträge korrigieren können.

0
ThiagoAlves