Lösung 1:
Hoffentlich verwenden Sie ein EBS-Root-Volume. Wenn ja, ist die Lösung nicht allzu schwierig.
Im Wesentlichen hängen Sie das EBS-Volume an eine andere Instanz an, nehmen die Änderungen vor und fügen es wieder an die ursprüngliche Instanz an:
- Beenden (nicht beenden) Sie die ursprüngliche Instanz
- Trennen Sie das EBS-Volume
- Starten Sie eine weitere Instanz
- Hängen Sie Ihr aktuelles EBS-Volume an die neue Instanz an
- SSH in die neue Instanz, mounten Sie das EBS-Volume und nehmen Sie die erforderlichen Änderungen vor
- Unmounten Sie das EBS-Volume (z. B.
umount -d /dev/xvdh
oderumount -d /dev/sdh
) - Trennen Sie das EBS-Volume von der neuen Instanz und hängen Sie es als Root-Volume an (z. B.
/dev/sda1
) der alten Instanz - Starten Sie die alte Instanz
- Wenn alles funktioniert, beenden Sie die neue Instanz
Der Grund dafür ist, dass Sie auf der frischen, neuen Instanz die richtigen Berechtigungen haben – ihr Root-Volume ist intakt – was die sudoers-Datei Ihrer ursprünglichen Instanz zu einer weiteren Datei macht, die Sie bearbeiten können.
Wenn Sie ein Instance-Store-Root-Volume haben, können Sie das Problem leider wahrscheinlich nicht beheben und müssen zu einem AMI zurückkehren, das Sie zuvor als Backup erstellt haben.
Lösung 2:
Es hängt davon ab, ob es sich um ein AMI- oder EBS-Root-Gerät handelt.
Wenn es sich um ein AMI handelt und Sie das Root-Passwort nicht haben und das AMI den Root-SSH-Zugriff nicht konfiguriert, können Sie nichts tun.
Wenn es sich um ein EBS-Root handelt, können Sie es beenden und das Volume an eine andere Instanz anhängen (als zusätzliche Festplatte, nicht als Root). Sie können dann entweder auf die Daten zugreifen oder die sudoers-Datei korrigieren und eine neue Instanz mit dem Volume starten.