Direkt zum Inhalt

Wie behebe ich sudo-Fehler auf meiner Amazon-EC2- oder Lightsail-Instance, wenn ich den sudo-Befehl ausführe?

Lesedauer: 11 Minute
0

Ich habe den Eigentümer der Datei /etc/sudoers auf meiner Amazon Elastic Compute Cloud (Amazon EC2)- oder Amazon-Lightsail-Instance geändert oder gelöscht. Jetzt erhalte ich Fehler, wenn ich sudo-Befehle ausführe.

Kurzbeschreibung

Wenn du die Datei /etc/sudoers löschst oder falsch konfigurierst, erhältst du möglicherweise die folgenden syntax- oder sudo-Fehler:

  • „sudo: /etc/sudoers is owned by uid 1000, should be 0"
  • "sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set“
  • „sudo: unable to open /etc/sudoers: No such file or directory“
  • „sudo: no valid sudoers sources found, quitting“
  • „sudo: error initializing audit plugin sudoers_audit“

Wenn du eine dieser Fehlermeldungen erhältst, kannst du Benutzern oder Benutzergruppen keinen Zugriff für Systemressourcen gewähren. Um die Dateien /etc/sudoers und /usr/bin/sudo auf Amazon EC2 oder Lightsail zu korrigieren, verwende ein Benutzerdaten-Script oder ein Launch-Script, um die Dateiberechtigungen zu ändern. Füge alternativ die Stammfestplatte an eine Rettungs-Instance an, um manuell Änderungen vorzunehmen.

Hinweis: Wenn du die Datei /etc/sudoers gelöscht hast, musst du ein Benutzerdaten-Script verwenden, um sie neu zu erstellen.

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Ein Benutzerdaten- oder Launch-Script verwenden, um die Dateiberechtigungen zu ändern

Um die Fehlermeldungen „owned by uid 1000" oder „must be owned by uid 0" zu beheben, musst du die Dateiberechtigungen /etc/sudoers und /usr/bin/sudo ändern.

Führe für Amazon-EC2-Instances die folgenden Schritte aus, um ein Benutzerdaten-Sckript zum Ändern der Dateiberechtigungen zu verwenden:

  1. Öffne die Amazon-EC2-Konsole.

  2. Wähle im Navigationsbereich Instances und dann die EC2-Instance aus.

  3. Wähle Instance-Status und dann Instance stoppen aus.

  4. Wähle Aktionen und dann Instance-Einstellungen aus.

  5. Wähle Benutzerdaten bearbeiten.

  6. Gib das folgende Script ein:

    Content-Type: multipart/mixed; boundary="//"
    MIME-Version: 1.0
    --//
    Content-Type: text/cloud-config; charset="us-ascii"
    MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Disposition: attachment; filename="cloud-config.txt"
    #cloud-config
    cloud_final_modules:
    - [scripts-user, always]
    --//
    Content-Type: text/x-shellscript; charset="us-ascii"
    MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Disposition: attachment; filename="userdata.txt"
    
    #!/bin/bash
    # To fix error sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set. use below commands
    chown -R root:root /usr/bin/sudo
    chmod 4755 /usr/bin/sudo
    
    # to fix below sudo errors:
    #sudo: /etc/sudoers is owned by uid 1000, should be 0
    #sudo: no valid sudoers sources found, quitting
    #sudo: error initializing audit plugin sudoers_audit
    
    chown -R root:root /etc/sudoers
    chown -R root:root /etc/sudoers.d/
    sudo service sshd restart
    --//--
  7. Starte die Instance und warte, bis sie die Statusüberprüfungen bestanden hat.

  8. Stelle eine Verbindung zur Instance her und führe dann den folgenden Befehl aus, um zu überprüfen, ob die Berechtigungen der Dateien /etc/sudoers und /usr/bin/sudo korrekt sind:

    sudo ls -la /etc/sudoers
    sudo ls -la /usr/bin/sudo

    Die folgende Beispielausgabe zeigt die richtigen Berechtigungen:

    $sudo ls -la /etc/sudoers /usr/bin/sudo
    -r--r----- 1 root root   1714 Jun 25 13:38 /etc/sudoers
    -rwsr-xr-x 1 root root 281624 Jun 27  2023 /usr/bin/sudo

Führe für Lightsail-Instances die folgenden Schritte aus, um ein Launch-Script zum Ändern der Dateiberechtigungen zu verwenden:

  1. Öffne die Lightsail-Konsole.

  2. Wähle Snapshots und dann den Instance-Snapshot aus.

  3. Wähle Aktionen und dann Neue Instance erstellen aus.

  4. Wähle unter Optional die Option + Launch-Script hinzufügen.

  5. Gib das folgende Launch-Script ein:

    #!/bin/bash
    # To fix error sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set. use below commands
    chown -R root:root /usr/bin/sudo
    chmod 4755 /usr/bin/sudo
    
    # to fix below sudo errors:
    #sudo: /etc/sudoers is owned by uid 1000, should be 0
    #sudo: no valid sudoers sources found, quitting
    #sudo: error initializing audit plugin sudoers_audit
    
    chown -R root:root /etc/sudoers
    chown -R root:root /etc/sudoers.d/
    sudo service sshd restart
    --//--
  6. Wähle Instance erstellen.

  7. Stelle eine Verbindung zur Instance her und führe dann den folgenden Befehl aus, um die Berechtigungen der Dateien /etc/sudoers und /usr/bin/sudo zu überprüfen:

    sudo ls -la /etc/sudoers
    sudo ls -la /usr/bin/sudo

    Die folgende Beispielausgabe zeigt die richtigen Berechtigungen:

    $sudo ls -la /etc/sudoers /usr/bin/sudo
    -r--r----- 1 root root   1714 Jun 25 13:38 /etc/sudoers
    -rwsr-xr-x 1 root root 281624 Jun 27  2023 /usr/bin/sudo

Stammfestplatte an eine Rettungs-Instance anfügen

Instance für einen Stopp und Start konfigurieren

Hinweis: Wenn du eine Instance anhältst und startest, ändert sich die öffentliche IP-Adresse der Instance. Es empfiehlt sich, beim Weiterleiten von externem Datenverkehr an die Instance eine Elastic-IP-Adresse anstelle einer öffentlichen IP-Adresse zu verwenden. Wenn du Amazon Route 53 verwendest, musst du möglicherweise die Route-53-DNS-Datensätze aktualisieren, wenn sich die öffentliche IP-Adresse ändert.

Bevor du die Instance anhältst und startest, gehe wie folgt vor:

Stammfestplatte an eine Rettungs-Instance anfügen

Gehe wie folgt vor:

  1. Erstelle ein neues Schlüsselpaar.

  2. Rufe die Volume-ID und den Gerätenamen für das Root-Volume der ursprünglichen Instance ab.

  3. Halte die ursprüngliche Instance an.

  4. Starte eine Wiederherstellungs-Instance von einem Amazon Machine Image (AMI) mit derselben Linux-Betriebssystemversion in derselben Availability Zone.

  5. Trenne das Root-Volume von der ursprünglichen Instance und füge es dann als sekundäres Volume an die Wiederherstellungs-Instance an.

  6. Stelle mit dem neuen SSH-Schlüsselpaar eine Verbindung zur Wiederherstellungs-Instance her.

  7. Verwende den folgenden Befehl, um zum Root-Benutzer zu wechseln:

    sudo su
  8. Führe den folgenden Befehl von der Wiederherstellungs-Instance aus, um den Namen und die Partition des Blockgeräts zu identifizieren:

    lsblk

    Beispielausgabe

    [root ~]$ lsblk
    NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    xvda    202:0    0    8G  0 disk
    └─xvda1 202:1    0    8G  0 part /
    xvdf    202:80   0  101G  0 disk
    └─xvdf1 202:81   0  101G  0 part
    xvdg    202:96   0   30G  0 disk

    Im vorherigen Beispiel sind die Volume-Gerätenamen xvda und xvdf partitionierte Volumes und xvdg ist kein partitioniertes Volume.
    Wenn dein Volume partitioniert ist, führe den folgenden Befehl aus, um die Partition /dev/xvdf1 anstelle des /dev/xvdf-Rohgeräts einzubinden:

    mount -o nouuid  /dev/xvdf1 /mnt

    Wenn du eine Instance verwendest, die auf dem AWS Nitro System basiert, verwendet der Volume-Gerätename das Format /dev/nvme[0-26]n1. Führe den folgenden Befehl aus, um die Partition im Verzeichnis /mnt einzubinden:

    mount -o nouuid  /dev/nvme1n1p1 /mnt

    Hinweis: Ersetze /dev/nvme1n1p1 durch den Gerätenamen, den du mit dem Befehl lsblk ermittelt hast. Weitere Informationen findest du unter Gerätenamen für Volumes auf Amazon-EC2-Instances.

  9. Um die Datei /etc/sudoers als Backup von der Arbeits-Instance zu kopieren, führe den folgenden Befehl aus:

    cp /etc/sudoers /mnt/etc/sudoers.bak
  10. Um eine chroot-Umgebung im Verzeichnis /mnt zu erstellen, führe den folgenden Befehl aus:

for i in dev proc sys run; do mount -o bind /$i /mnt/$i; done; chroot /mnt

Der vorherige Befehl führt ein Bind-Mount der Verzeichnisse /dev, /proc, /sys und /run aus dem ursprünglichen Root-Dateisystem aus. Diese Konfiguration ermöglicht Prozessen, die in der chroot-Umgebung ausgeführt werden, den Zugriff auf diese Systemverzeichnisse. Um die Datei /etc/sudoers zu bearbeiten, führe den folgenden Befehl in der chroot-Umgebung aus:

visudo

Stelle sicher, dass die Datei die folgenden Standardeinstellungen hat:

# This file MUST be edited with the 'visudo' command as root.

# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.

# See the man page for details on how to write a sudoers file.

Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root ALL=(ALL:ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
#includedir /etc/sudoers.d

Hinweis: Der visudo-Befehl sperrt die sudoers-Datei.
Wenn du beim Ausführen des vorherigen Befehls eine Fehlermeldung erhältst, führe den folgenden diff-Befehl aus, um die Datei /etc/sudoers mit der neuen Datei /etc/sudoers.bak zu vergleichen:

diff /etc/sudoers /etc/sudoers.bak

Hinweis: Wenn du vor der Bearbeitung der Datei keine benutzerdefinierten Änderungen vorgenommen hast, stelle die Datei /etc/sudoers.bak wieder in /etc/sudoers her. Um die chroot-Umgebung zu verlassen, führe den folgenden Befehl aus:

exit
  1. Führe den folgenden Befehl aus, um die Einbindung des Root-Volumes aufzuheben:
umount -fl /mnt
  1. Trenne das Root-Volume, das du als sekundäres Volume angefügt hast, von der Wiederherstellungs-Instance. Füge es dann erneut mit dem Gerätenamen aus Schritt 2 an die ursprüngliche Instance an.
  2. Starte die ursprüngliche Instance und führe dann den folgenden Befehl aus, um dich zu vergewissern, dass die sudo-Befehle ordnungsgemäß funktionieren:
sudo su

Benutzerdaten verwenden, um den Dateiinhalt zu ändern oder die Datei neu zu erstellen

Hinweis: Um die folgende Methode zur Problembehandlung verwenden zu können, musst du ein Passwort für den/die Root-Benutzer:in festlegen.

Die Datei neu erstellen

Gehe wie folgt vor, um als Root-Benutzer:in auf die Instance zuzugreifen, sodass du die Datei neu erstellst:

  1. Öffne die Amazon-EC2-Konsole.

  2. Wähle im Navigationsbereich Instances und dann die Instance aus.

  3. Wähle Instance-Status und dann Instance stoppen aus.

  4. Wähle unter Instance stoppen? die Option Stopp aus.

  5. Wähle Aktionen und dann Instance-Einstellungen aus.

  6. Wähle Benutzerdaten bearbeiten.

  7. Gib das folgende Script ein, um ein temporäres Passwort für den/die Root-Benutzer:in festzulegen:

    Content-Type: multipart/mixed; boundary="//"            
    MIME-Version: 1.0
    
    --//
    Content-Type: text/cloud-config; charset="us-ascii"
    MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Disposition: attachment; filename="cloud-config.txt"
    
    #cloud-config
    cloud_final_modules:
    - [scripts-user, always]
    
    --//
    Content-Type: text/x-shellscript; charset="us-ascii"
    MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Disposition: attachment; filename="userdata.txt"
    
    #!/bin/bash
    chpasswd <<<"root:root"
    --//

    Wichtig: Dieses Passwort verwendet Nur-Text zur Weitergabe von Geheimnissen und ist nicht sicher. Stelle sicher, dass du das temporäre Passwort vom / von der Root-Benutzer:in entfernst, nachdem du die Schritte zur Problembehandlung abgeschlossen hast.

  8. Starte die Instance und melde dich dann als ec2-user an.

  9. Um die Datei /etc/sudoers wieder herzustellen, führe den folgenden pkexec-Befehl aus:

    pkexec /usr/sbin/visudo
  10. Gib das Passwort des Root-Benutzers ein und ändere dann die Datei /etc/sudoers mit den folgenden Werten:

# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults    env_reset
Defaults    mail_badpass
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d
  1. Führe einen sudo-Befehl aus, um zu überprüfen, ob sudo ordnungsgemäß funktioniert.
  2. Halte die Instance an.

Löschen des Benutzerdaten-Scripts

Gehe wie folgt vor, um die Benutzerdatenwerte, einschließlich des Passworts des Root-Benutzers, mithilfe der Amazon-EC2-Konsole zu löschen:

  1. Öffne die Amazon-EC2-Konsole.
  2. Wähle im Navigationsbereich Instances und dann die Instance aus.
  3. Wähle Aktionen und dann Instance-Einstellungen aus.
  4. Wähle Benutzerdaten bearbeiten aus und lösche dann alle Benutzerdaten.

Um die AWS CLI zum Löschen der Benutzerdatenwerte, einschließlich des Passworts des Root-Benutzers, zu verwenden, führe den folgenden modify-instance-attribute-Befehl aus:

aws ec2 modify-instance-attribute --instance-id example-instance-id --user-data Value=""

**Hinweis:**Ersetze example-instance-id durch deine Instance-ID.

Führe den folgenden describe-instance-attribute-Befehl aus, um zu überprüfen, ob du die Benutzerdaten entfernt hast:

aws ec2 describe-instance-attribute --instance-id example-instance-id --attribute userData

**Hinweis:**Ersetze example-instance-id durch deine Instance-ID.

Nachdem du die Benutzerdaten gelöscht hast, starte die Instance.

Ähnliche Informationen

Warum kann ich keine sudo-Befehle auf meiner EC2-Linux-Instance ausführen?

AWS OFFICIALAktualisiert vor 6 Monaten