Wie kann ich das fehlerhafte Eigentum von "etc / sudoers" auf EC2 beheben?

Ja, du hast es wirklich kaputt gemacht. Sie können nicht aus Gründen des Eigentums Sudo verwenden und die Instanzen von Amazon sind so eingerichtet, dass sie root ohne Sudo-Zugriff nicht zulassen.

Wenn der Neustart der Instanz nicht funktioniert hat, werden die vorgenommenen Änderungen auf dem angehängten EBS-Volume gespeichert. Zur Behebung dieses Problems müssen Sie eine andere, neue Instanz starten und das EBS-Volume, auf dem sich die verzierte Datei befindet, einhängen und ändern. Dadurch wird in Amazons eigener Dokumentation hier beschrieben sowie in der Antwort auf die Frage, die Sie verknüpfen zusammengefasst .

Nachdem Sie das Problem behoben haben, aber bevor Sie erneut versuchen zu bearbeiten /etc/sudoers, können Sie sich mit visudoeinem Werkzeug vertraut machen, das Sie in einen vorinstallierten Editor bringt /etc/sudoersund vor dem Speichern eine Sicherheitsüberprüfung durchführt.

Während das Durcharbeiten der Amazon-Dokumentation hilfreich war (wie in der Antwort von @ Ouroborus), überlegte ich schließlich, wie ich dieses Chaos reparieren sollte, in das ich mich hineingelegt hatte.

Mal sehen, ob ich mich an alle Schritte erinnern kann ...

• Bereiten Sie eine neue Instanz vor

  • Sie können Ihre vorhandene Instanz so gut wie möglich anpassen, indem Sie unter Meine AMIs das gleiche AMI-Image auswählen, das Ihre Probleminstanz verwendet.

    ---

    

  • Da dies nur eine Instanz für Wiederherstellungszwecke ist, wählen Sie den freien Instanztyp aus:

    

  • Dieser Schritt ist sehr wichtig ! Stellen Sie sicher, dass die Subnetzmaske in dieser Wiederherstellungsinstanz mit Ihrer Probleminstanz übereinstimmt (andernfalls können Sie das problematische EBS nicht in Ihre Wiederherstellungsinstanz einbinden! Ich habe es auf die harte Tour herausgefunden ...)

    

  • Sie können auf "Weiter: Speicher hinzufügen" klicken, die Seite belassen und auf "Weiter: Tag-Instanz" klicken.

  • Geben Sie im Feld "Wert" etwas wie "Wiederherstellung" ein (jeder Name reicht aus, in meinem Fall ist es nur der Zweck dieser Instanz zu kennzeichnen).

    

  • Es sollte einen letzten Schritt / Popup geben, in dem Sie aufgefordert werden, die eingehende / ausgehende Sicherheitsgruppe zu erstellen. Stellen Sie sicher, das gleiche holen Sie sollten bereits Setup für Ihr Problem Instanz haben. Das heißt, Sie können dieselbe SSH-Schlüsseldatei erneut verwenden, um sich bei dieser Instanz anzumelden (über Putty oder das gewünschte Programm).

Sobald diese Wiederherstellungsinstanz erstellt wurde ...

• Vergewissern Sie sich, dass Sie die Namen Ihrer EBS-Volumes im Auge behalten (da Sie Ihr problematisches Volume zwischen dieser temporären Instanz und wieder in Ihrer ursprünglichen Instanz bereitstellen müssen).
• Markieren Sie nach unten, welchen Weg Ihr Problem Instanz greift auf das Volumen (zB: /dev/xvda).
• Ok, jetzt Stop (nicht Beenden !!!) Ihrer Probleminstanz.
• Möglicherweise müssen Sie den Browser aktualisieren, um zu bestätigen, dass er angehalten wurde (dies kann einige Sekunden dauern).

• Navigieren Sie nun zum Abschnitt EBS Volumes:

  

• Deaktivieren Sie das Volume, die derzeit für das Problem Instanz gebunden ist (sind Sie in Ihrer Instanz des Status markiert sehen, wie gestoppt in einen der äußersten rechten Spalten).

• Aktualisieren, um zu bestätigen, dass das Volume "verfügbar" ist.

• Hängen Sie das Volume in Ihre neue Wiederherstellungsinstanz ein (wenn Sie Ihre Wiederherstellungsinstanz nicht in der Liste sehen können, haben Sie wahrscheinlich den oben genannten "Subnetz" -Schritt verpasst - und Sie müssen Ihre Wiederherstellungsinstanz immer wieder neu erstellen, um dieses Teilnetz anzupassen Rahmen).

• Aktualisieren Sie, bestätigen Sie, dass es jetzt in Ihrer Wiederherstellungsinstanz "in Verwendung" ist.

• Nun zu den lustigen Befehlszeilenschritten!

  • Melden Sie sich / SSH in Ihrer Wiederherstellungsbox an (Sie können die IP- / Host-Adresse der Wiederherstellungsinstanz im Abschnitt Instanzen von AWS nachschlagen).

  • Setzen Sie Ihr aktuelles Arbeitsverzeichnis auf das Stammverzeichnis:
    cd /

  • Erstellen Sie ein Verzeichnis für Ihr problematisches EBS-Volume:
    sudo mkdir bad

  • Montieren Sie es: sudo mount /dev/xvdf /bad

    (HINWEIS: Wenn dies nicht funktioniert, ist möglicherweise dasselbe Problem aufgetreten, das ich hatte. Versuchen Sie stattdessen Folgendes: sudo mount /dev/xvdf1 /badDank dieser Antwort https://serverfault.com/a/632906/356372 ).

  • Wenn dies gut geht, sollten Sie jetzt in diesem Verzeichnis cd/bad speichern können und die gleiche Dateistruktur sehen, die Sie normalerweise sehen würden, wenn sie in Ihre ursprüngliche (derzeit problematische) Instanz eingebunden wird.

  • SEHR WICHTIG Hinweis in den folgenden paar Schritten, wie ich verwende ./etcund nicht /etcdie Berechtigungen / Eigentum auf der, um anzuzeigen, zu ändern /bad/etc/sudoersDatei, nicht die Recovery - EBS Volumen! Ein kaputtes Volumen reicht, oder?

  • Versuchen Sie:
    cd /bad
ls -l ./etc/sudoers
    ... dann folgen Sie dem durch:
    stat --format %a ./etc/sudoers
    

  • Bestätigen Sie, dass der Besitz und / oder der chmodWert dieser Datei tatsächlich falsch ist.

Führen Sie folgende chownSchritte aus, um den Besitz zu korrigieren :

sudo chown root:root ./etc/sudoers

Führen Sie folgende chmodSchritte aus, um den Wert festzulegen:

sudo chmod 0755 ./etc/sudoers

Jetzt geht es nur noch darum, die Schritte umzukehren!

• Sobald dies erledigt ist, ist es Zeit für die Demontage: cd /
sudo umount /bad

• Gehen Sie zurück zur AWS-Konfigurationsseite zum Abschnitt EBS Volume.

• Hängen Sie das feste Volume von der Wiederherstellungsinstanz ab.
• Aktualisieren Sie, bestätigen Sie, dass es ist available.
• Mounten Sie es wieder in der ursprünglichen Instanz (NICHT VERGESSEN - verwenden /dev/whatever/Sie vor allen diesen Schritten denselben Pfad, den Ihre ursprüngliche Instanz verwendet hat).
• Aktualisieren Sie, bestätigen Sie, dass es ist in-use.
• Navigieren Sie nun zum Abschnitt Instanzen und starten Sie Ihre ursprüngliche Instanz erneut. (Der Neustart kann einige Sekunden / Minuten dauern).
• Wenn alles in Ordnung ist, sollten Sie sich jetzt anmelden und SSH in Ihre EC2-Instanz einfügen und sudoerneut verwenden können!

Glückwunsch, wenn es auch für Sie funktioniert hat!

Wenn nicht .... ich bin so .... es tut mir sehr leid, dass dir das passiert :(