Amazon EC2 - Kein SSH nach Neustart, Verbindung abgelehnt

Ich habe das zwei- oder dreimal wiederholt, also schätze ich, dass etwas nicht stimmt mit dem, was ich tue.

Hier sind meine Schritte:

1. Starten Sie eine neue Instanz über die EC2-Verwaltungskonsole unter Verwendung von: Ubuntu Server 13.10 - ami-ace67f9c (64-Bit)
2. Mit Standardeinstellungen starten (mit meinem vorhandenen Schlüsselpaar)
3. Die Instanz wird gestartet. Ich kann es mit Putty oder dem Mac-Terminal SSH. Erfolg!
4. Ich starte die Instanz neu

5. 10 Minuten später, wenn die Instanz wieder ausgeführt werden soll, zeigt meine Terminalverbindung Folgendes an:

   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$
   

Gut, ich verstehe, dass sich die öffentliche IP-Adresse ändern kann. Wenn ich die EC2-Verwaltungskonsole überprüfe, stelle ich sicher, dass sie identisch ist. Seltsam. Aus Spaß versuche ich, eine Verbindung mit dem öffentlichen DNS-Hostnamen herzustellen: ec2-54-201-200-208.us-west-2.compute.amazonaws.com. Kein Würfel, gleiches Ergebnis.

Selbst wenn ich den in die EC2-Konsole integrierten Connect via Java SSH-Client verwende, wird die Verbindung abgelehnt.

Ich habe die Sicherheitsgruppen überprüft. Diese Instanz befindet sich in Gruppe Start-Assistent-4. Wenn Sie die eingehende Konfiguration für diese Gruppe betrachten, ist Port 22 von 0.0.0.0/0 zulässig, das sollte also überall sein. Ich weiß, dass ich auf meine Instanz treffe und dies ist die richtige Sicherheitsgruppe, da ich die Instanz nicht anpingen kann. Wenn ich ICMP für diese Sicherheitsgruppe aktiviere, gehen plötzlich meine Pings durch.

Ich habe ein paar andere Posts im Internet mit ähnlichen Fehlermeldungen gefunden, aber die meisten scheinen sich leicht durch Ändern der Firewall-Einstellungen beheben zu lassen. Ich habe ein paar davon ausprobiert, ohne Glück.

Ich vermute, es gibt einen einfachen EC2-Schritt, den ich vermisse. Vielen Dank für jede Hilfe, die Sie geben können, und ich freue mich, weitere Informationen bereitzustellen oder weiter zu testen!

Update - Hier sind meine Systemprotokolle von der Amazon EC2-Konsole: http://pastebin.com/4M5pwGRt

Hatte heute ein ähnliches Verhalten auf meiner ec2-Instanz und verfolgte die Sache wie folgt: Wenn ich das mache sudo reboot now , hängt der Computer und ich muss ihn manuell von der aws-Verwaltungskonsole neu starten, wenn ich es mache sudo reboot , startet es ganz gut. Anscheinend ist "jetzt" keine gültige Option für einen Neustart, wie hier gezeigt: /ubuntu/397502/reboot-a-server-from-command-line

Gedanken?

Vom AWS Developer Forum-Beitrag zu diesem Thema :

Versuchen Sie, die fehlerhafte Instanz zu stoppen, das EBS-Volume zu trennen und es als sekundäres Volume an eine andere Instanz anzuhängen. Nachdem Sie das beschädigte Volume an einer anderen Stelle aktiviert haben, überprüfen Sie die Datei / etc / sshd_config (unten). Ich hatte ein paar RHEL-Instanzen, in denen Yum die Datei sshd_config gescroggt hat, wobei am unteren Rand doppelte Zeilen eingefügt wurden, die dazu führten, dass sshd beim Start aufgrund von Syntaxfehlern fehlschlug.

Sobald Sie es repariert haben, hängen Sie einfach das Volume aus, trennen Sie es, verbinden Sie es erneut mit Ihrer anderen Instanz und starten Sie es erneut.

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

1. Stoppen Sie die fehlerhafte 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 von Ihnen gestoppten Instanz zugeordnet ist.
2. Starten Sie eine neue Instanz in derselben Region und demselben Betriebssystem wie die fehlerhafte Instanz und hängen Sie dann 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" bereitstellen.
3. Sobald Sie das defekte Volume auf der anderen Instanz aktiviert haben ,
4. Überprüfen Sie die Datei "/ etc / sshd_config" auf doppelte Einträge, indem Sie die folgenden Befehle ausführen:
   • cd /etc/ssh
   • sudo nano sshd_config
   • ctrl-v ein paar Mal, um an den unteren Rand der Datei zu gelangen
   • ctrl-k Alle Zeilen am unteren Rand, in denen "PermitRootLogin without-password" und "UseDNS no" angegeben sind
   • ctrl-xund Yzum Speichern und Verlassen der bearbeiteten Datei
5. @Telegard weist (in seinem Kommentar) darauf hin, dass wir nur das Symptom behoben haben. Wir können die Ursache 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-xund Yzum Speichern und Verlassen der bearbeiteten Datei
6. Sobald Sie es behoben haben, hängen Sie einfach die Lautstärke ,
7. Trennen Sie die Verbindung, indem Sie in die EC2-Verwaltungskonsole gehen und auf "Elastic Block Store"> "Volumes" klicken. Klicken Sie mit der rechten Maustaste auf das Volume, das der gestoppten Instanz zugeordnet ist.
8. Verbinden Sie sich erneut mit Ihrer anderen Instanz und
9. feuere es wieder hoch .

Es mag der Situation nicht helfen, aber ich habe einige Fälle gesehen, in denen ein Neustart auf EC2 "hängen bleibt". Wenn Sie die VM zurücksetzen und anschließend die Systemprotokolle abrufen, kann dies zu einer Änderung des Verhaltens führen. Vergewissern Sie sich, dass die Protokolle vom zweiten Systemstart stammen und nicht vom ersten - sie werden bei Aktualisierungen in der Regel verzögert.

Eine andere zu überprüfende Sache ist, sicherzustellen, dass die Instanz auf der IP antwortet. Anscheinend wird oben eine Verbindung abgelehnt. Dies scheint, als wäre die Instanz aktiv, aber SSH wird nicht ausgeführt oder ist durch eine Firewall geschützt. Stellen Sie jedoch sicher, dass die Instanz vollständig neu gestartet wurde.

Sie können auch versuchen, alle Ports von einem Testsystem aus zu öffnen und zu sehen, was "nmap" Ihnen anzeigt - sind alle anderen Dienste, die auf die Instanz reagieren.

Klicken Sie mit der rechten Maustaste auf den Instanznamen und klicken Sie auf "Sicherheitsgruppen ändern". Vergewissern Sie sich, dass die von Ihnen erstellte Sicherheitsgruppe, die es jedem ermöglicht, von überall nach Port 22 zu gelangen, aktiviert und auf diese Instanz angewendet ist.

Ich habe dieses Problem, nachdem ich sudo reboot nowüber SSH auf meinem EC2-Server Ubuntu 14.04 ausgeführt habe. Funktionierte nach einem Neustart über die EC2-Verwaltungskonsole einwandfrei.

In meinem Fall habe ich eine Sicherheitsgruppe eingerichtet, die nur Verbindungen von Port 22 über meine IP zulässt. Einige Tage später hat mein ISP meine IP-Adresse geändert, daher muss die Sicherheitsgruppe aktualisiert werden.

Ich hatte ein ähnliches Problem, meine EC2 Amazon Linux-Instanz war nach dem Ausführen von sudo reboot nicht mehr erreichbar .

Kein SSH-Zugriff, Stopp / Start / Neustart-Befehle von der Amazon Admin-Konsole gaben mir ebenfalls kein Ergebnis.

Endlich konnte ich meine Instanz neu starten, indem ich ein Image über die Amazon-Konsole erstellte. Der Image-Erstellungsprozess scheint den Instanzstatus zu korrigieren.

Ich hoffe es hilft ;)

Ich hatte das gleiche Problem, nachdem ich einen Vanille- sudo rebootBefehl ausgeführt hatte. Ich stellte fest, dass ich das Problem beheben konnte, indem ich mein AMI über die AWS-Konsole vollständig stoppte (nicht neu startete) und es dann wieder startete.

Aus irgendeinem Grund konnte das Problem durch einen Neustart der AMI von der AWS-Konsole aus, indem auf die Neustartaktion geklickt wurde, anstatt die Instanz zu stoppen und dann zu starten, nicht behoben werden.

Wie bereits erwähnt, haben Sie wahrscheinlich mit der / etc / fstab /

Ich hatte dieses Problem. Zuerst müssen Sie das Volume unter / dev / sda1 erneut hinzufügen, wie in der Warnmeldung angegeben.

Dann konnte ich nicht ssh. Ich erkannte, dass ich das andere Volume hinzufügen musste, das ich erstellt hatte, und dass das SSH-Problem behoben war.

Anschließend können Sie sich anmelden und die fstab wieder auf das Original zurücksetzen.