Ich habe eine Amazon EC2-Instanz. Ich kann mich ganz gut einloggen, aber jetzt funktionieren weder "su" noch "sudo" (zuvor funktionierten sie gut):
„su“ fordert ein Passwort, aber ich anmelden SSH - Schlüssel verwenden, und ich glaube nicht, der Root - Benutzer selbst hat ein Passwort.
"sudo <anything>" macht das:
sudo: /etc/sudoers is owned by uid 222, should be 0 sudo: no valid sudoers sources found, quitting
Ich habe wahrscheinlich "chown ec2-user / etc / sudoers" (oder, wahrscheinlicher "chown -R ec2-user / etc", weil ich es satt hatte, dass rsync versagt), also ist dies meine Schuld.
Wie kann ich mich erholen? Ich habe die Instanz angehalten und die Option "Benutzerdaten anzeigen / ändern" auf der AWS EC2-Konsole ausprobiert, was jedoch nicht geholfen hat.
EDIT: Ich weiß, dass ich diese Instanz beenden und eine neue erstellen kann, aber ich hoffte, etwas Extremes zu vermeiden.
In einer solchen Situation sollten Sie in der Lage sein, eine zweite Instanz zu verwenden, um das Problem zu beheben:
Trennen Sie die EBS-Platte, die das defekte System enthält
Erstellen Sie eine weitere EC2-Instanz
Hängen Sie die Diskette an und montieren Sie sie in die neue Instanz
Korrigieren Sie die Berechtigungen
Umount, Trennen und erneutes Anfügen an die ursprüngliche Instanz
5
Rekee
Stoppen Sie Ihre aktuelle Instanz
Bestehendes Volume trennen
Erstellen Sie ein neues Volume
Hängen Sie das neue Volume als "/ dev / xvda" an Ihre Instanz an.
Starten Sie Ihre Instanz
Schließen Sie das alte Volume (eines mit Sudo-Berechtigungsproblem) an die Instanz an, während es als "/ dev / sdf" ausgeführt wird.
Melden Sie sich mit putty bei Ihrer Instanz an
Verwenden Sie den lsblkBefehl, um die verfügbaren Festplattengeräte und ihre Einhängepunkte anzuzeigen (falls zutreffend), um den richtigen Gerätenamen zu ermitteln.
ec2-user ~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvdf 202:80 0 100G 0 disk xvda1 202:1 0 8G 0 disk /
Die Ausgabe von lsblk entfernt das Präfix / dev / aus den vollständigen Gerätepfaden. In diesem Beispiel /dev/xvda1ist es als Root-Gerät gemountet (beachten Sie, dass MOUNTPOINT als /, als Root der Linux-Dateisystemhierarchie aufgeführt ist) und /dev/xvdfangehängt ist, aber noch nicht bereitgestellt wurde .
Verwenden Sie den folgenden Befehl, um ein Mountpunktverzeichnis für das Volume zu erstellen. Der Bereitstellungspunkt ist der Ort, an dem sich das Volume in der Dateisystemstruktur befindet, und an dem Sie Dateien lesen und schreiben, nachdem Sie das Volume bereitgestellt haben. Ersetzen Sie mount_point durch einen Ort, z. B. / data.
sudo su cd /mnt mkdir other mount /dev/xvdf other cd / chown -R root:root /mnt/other/etc/ exit
Gehen Sie zurück zu AWS und stoppen Sie die Instanz
Trennen Sie die Volumes und verbinden Sie das alte (jetzt festgelegte) Volume als / dev / xvda
Starten Sie Ihre Instanz und jetzt sollten Ihre Berechtigungen wieder so sein, wie sie waren
Totally gearbeitet, aber ich musste neu als / dev / sda1 und nicht als / dev / xvda hinzufügen. Vielen Dank!
Erik Aronesty vor 6 Jahren
0
1
Brandon J Brotsky
Ich hatte das gleiche Problem und weil es so schwierig war, machte ich ein Video, um die Lösung zu erklären. Dies ist so ziemlich das gleiche wie die Lösung von Rekee in Form eines Video-Tutorials.
Sieht so aus, als hätten Sie das selbst beantwortet ...
Ich habe wahrscheinlich "chown ec2-user / etc / sudoers" (oder, wahrscheinlicher "chown -R ec2-user / etc", weil ich es satt hatte, dass rsync versagt), also ist dies meine Schuld.
Auf jeden Fall glaube ich nicht, dass Sie dieses Problem lösen können, ohne eine Root-Shell zu erhalten. (Ich bin nicht sicher, welche Wiederherstellungsmethoden auf ec2 möglich sind?)
Wenn Sie tatsächlich rekursiv / etc gown haben, dann denke ich, dass der Server neu aufgebaut werden sollte, ist der beste Weg.