Sie können kein Schlüsselpaar auf eine laufende Instanz anwenden. Sie können das neue Schlüsselpaar nur zum Starten einer neuen Instanz verwenden.
Wenn es sich um ein EBS-Boot-AMI handelt, können Sie es für die Wiederherstellung stoppen und einen Snapshot des Volumes erstellen. Erstellen Sie darauf basierend ein neues Volume. Und Sie können es wieder verwenden, um die alte Instanz zu starten, ein neues Image zu erstellen oder Daten wiederherzustellen.
Daten bei kurzlebiger Speicherung gehen jedoch verloren.
Aufgrund der Beliebtheit dieser Frage und Antwort wollte ich die Informationen in dem Link erfassen, den Rodney in seinem Kommentar gepostet hat.
Kredit geht an Eric Hammond für diese Informationen .
Fixieren von Dateien auf dem Root-EBS-Volume einer EC2-Instanz
Sie können Dateien auf dem Root-EBS-Volume einer EC2-Instanz untersuchen und bearbeiten, selbst wenn Sie sich in einer für Sie katastrophalen Situation befinden, wie:
- Sie haben Ihren SSH-Schlüssel verloren oder Ihr Passwort vergessen
- Sie haben beim Bearbeiten der Datei / etc / sudoers einen Fehler gemacht und können mit sudo keinen Root-Zugriff mehr erhalten, um das Problem zu beheben
- Ihre lang laufende Instanz ist aus irgendeinem Grund hängen geblieben, kann nicht kontaktiert werden und startet nicht ordnungsgemäß
- Sie müssen Dateien von der Instanz wiederherstellen, können jedoch nicht darauf zugreifen
Auf einem physischen Computer an Ihrem Schreibtisch können Sie das System einfach mit einer CD oder einem USB-Stick starten, die Festplatte einbinden, die Dateien auschecken und reparieren und dann den Computer neu starten, um wieder im Geschäft zu sein.
Eine entfernte EC2-Instanz scheint jedoch entfernt und unzugänglich zu sein, wenn Sie sich in einer dieser Situationen befinden. Glücklicherweise bietet uns AWS die Leistung und Flexibilität, um ein solches System wiederherstellen zu können, vorausgesetzt, wir führen EBS-Startinstanzen und keinen Instanzspeicher aus.
Der Ansatz auf EC2 ähnelt in gewisser Weise der physischen Lösung, aber wir werden die fehlerhafte „Festplatte“ (Root-EBS-Volume) verschieben und auf eine andere Instanz montieren, beheben und dann zurück verschieben.
In einigen Situationen ist es möglicherweise einfacher, eine neue EC2-Instanz zu starten und die fehlerhafte Instanz wegzuwerfen. Wenn Sie Ihre Dateien jedoch wirklich reparieren möchten, ist hier der Ansatz, der für viele funktioniert hat:
Konfiguration
Identifizieren Sie die ursprüngliche Instanz (A) und das Volume, das das defekte Root-EBS-Volume enthält, mit den Dateien, die Sie anzeigen und bearbeiten möchten.
instance_a=i-XXXXXXXX
volume=$(ec2-describe-instances $instance_a |
egrep '^BLOCKDEVICE./dev/sda1' | cut -f3)
Identifizieren Sie die zweite EC2-Instanz (B), mit der Sie die Dateien auf dem ursprünglichen EBS-Volume reparieren. Diese Instanz muss in derselben Verfügbarkeitszone wie Instanz A ausgeführt werden, damit das EBS-Volume daran angehängt werden kann. Wenn noch keine Instanz ausgeführt wird, starten Sie eine temporäre.
instance_b=i-YYYYYYYY
Stoppen Sie die defekte Instanz A (warten Sie, bis sie vollständig zum Stillstand gekommen ist), trennen Sie das Root-EBS-Volume von der Instanz (warten Sie, bis sie getrennt wird) und hängen Sie das Volume dann an Instanz B auf einem nicht verwendeten Gerät an.
ec2-stop-instances $instance_a
ec2-detach-volume $volume
ec2-attach-volume --instance $instance_b --device /dev/sdj $volume
ssh auf Instanz B und mounten Sie das Volume, damit Sie auf das Dateisystem zugreifen können.
ssh ...instance b...
sudo mkdir -p 000 /vol-a
sudo mount /dev/sdj /vol-a
Repariere es
Zu diesem Zeitpunkt kann Ihr gesamtes Root-Dateisystem von Instanz A unter / vol-a auf Instanz B angezeigt und bearbeitet werden. Beispielsweise möchten Sie möglicherweise:
- Geben Sie die richtigen SSH-Schlüssel in /vol-a/home/ubuntu/.ssh/authorized_keys ein
- Bearbeiten und korrigieren Sie / vol-a / etc / sudoers
- Suchen Sie in / vol-a / var / log / syslog nach Fehlermeldungen
- Kopieren Sie wichtige Dateien aus / vol-a /…
Hinweis: Die Benutzeroberflächen der beiden Instanzen sind möglicherweise nicht identisch. Seien Sie also vorsichtig, wenn Sie Dateien erstellen, bearbeiten oder kopieren, die Nicht-Root-Benutzern gehören. Beispielsweise hat Ihr MySQL-Benutzer in Instanz A möglicherweise dieselbe UID wie Ihr Postfix-Benutzer in Instanz B, was zu Problemen führen kann, wenn Sie Dateien mit einem Namen chownieren und das Volume dann wieder auf A verschieben.
Einpacken
Wenn Sie fertig sind und mit den Dateien unter / vol-a zufrieden sind, heben Sie das Dateisystem auf (noch auf Instanz B):
sudo umount /vol-a
sudo rmdir /vol-a
Zurück auf Ihrem System mit ec2-api-tools, verschieben Sie das EBS-Volume weiter auf die ursprüngliche Instanz A und starten Sie die Instanz erneut:
ec2-detach-volume $volume
ec2-attach-volume --instance $instance_a --device /dev/sda1 $volume
ec2-start-instances $instance_a
Hoffentlich haben Sie das Problem behoben, Instanz A wird einwandfrei angezeigt, und Sie können das erreichen, was Sie ursprünglich geplant hatten. Wenn nicht, müssen Sie diese Schritte möglicherweise so lange wiederholen, bis sie funktionieren.
Hinweis: Wenn Instanz A beim Stoppen eine elastische IP-Adresse zugewiesen wurde, müssen Sie sie nach dem erneuten Starten erneut zuordnen.
Merken! Wenn Ihre Instanz B nur für diesen Prozess vorübergehend gestartet wurde, vergessen Sie nicht, sie jetzt zu beenden.
ssh-addsollte tun, was Sie brauchen.