Linux Benutzerkontenverwaltung + sudo: wie am besten einstellen?

[Volvo-Berti]

moinsen in die Runde,

ich hab mal eine Frage zur Benutzerkontenverwaltung und sudo.

Aktuell ist es so, das ich nach der Installation von Linux ein weiteres Konto angelegt habe und das mit Admin-Rechten versehen habe. Anschließend hab ich mein Konto auf normalen User gesetzt. Grund ist das Kennwort, was auch meine Holde kennt

Jetzt ist es so, das zB sudo-Befehle im Terminal weder mein Passwort noch das des Admins annehmen. Beispielsweise "sudo tlp-stat" zur Anzeige des Batteriestatus. Da muss ich immer zum Admin-Konto wechseln, das ist natürlich nicht praktisch.

Wenn meine Erinnerung mich nicht trügt, war das früher anders, oder nicht?

 

[Volvo-Berti]

ich möchte, das ich mein System administrieren kann, und dazu brauche ich nur einen Useraccount. So ist es nun eingestellt.

aaber anscheinend stimmt jetzt leider was nicht... ich kann jetzt quasi nix mehr machen, denn es kommt als Fehler, dass Audit-plugin nicht initialisiert werden kann

 

[hikaru]

Zeig am besten nochmal deine aktuelle /etc/sudoers !
Ich habe allerdings keine Ahnung, was "Audit-plugin" ist, wozu es gut ist, und was es dafür braucht.

 

[fakiauso]

Zumindest ist jetzt der worst case eingetreten;-)

Hast Du es einmal mit dem "neuen" Passwort versucht für sudo, welches Du angelegt hast?

Klappt das, dann würde ich in der /etc/sudoers die von hikaru bemängelte Einträge des Users wir löschen und mal in der /etc/shadow nachschauen. Allerdings sind die Passwörter dort auch nur als Hash gespeichert:

Linux /etc/shadow Datei – Thomas-Krenn-Wiki

Passwörter von lokalen Benutzern werden unter Linux in der Datei /etc/shadow (shadow-Datei) gespeichert.

www.thomas-krenn.com

Wenn es eher experimentell war, bügelst Du vielleicht Mint noch einmal neu drauf.

 

[Ravensberger]

Blöde Frage, da ich selber kein Mint vor mir habe:
root hat ein Passwort bekommen?

sudo passwd root

Ist die Anmeldung entsprechend möglich?

su -

Wenn ja, hast Du Deinen Superuser root bereit, den Du immer unter Anmeldung root im virtuellen Terminal oder über su - im grafischen Terminal aufrufen kannst.
Dann prüfen, dass aus der Date /etc/group im Eintrag sudo keinen User enthält ist:

~$ cat /etc/group |grep sudo
sudo:x:27:

Achtung: die :27: kann bei Dir eine andere Nummerierung sein.

Wenn das so umgesetzt ist, ist root immer verfügbar, via sudo führt dann nur noch Dein User "wir" die Befehle aus, die Du weiter oben beschrieben hast.

Wie viele weitere User Du anlegst, bleibt hiervon unbenommen.

 

[Volvo-Berti]

Zeig am besten nochmal deine aktuelle /etc/sudoers !
Ich habe allerdings keine Ahnung, was "Audit-plugin" ist, wozu es gut ist, und was es dafür braucht.

geht nicht wg. dem Fehler

Zumindest ist jetzt der worst case eingetreten;-)

Hast Du es einmal mit dem "neuen" Passwort versucht für sudo, welches Du angelegt hast?

Klappt das, dann würde ich in der /etc/sudoers die von hikaru bemängelte Einträge des Users wir löschen und mal in der /etc/shadow nachschauen. Allerdings sind die Passwörter dort auch nur als Hash gespeichert:

Linux /etc/shadow Datei – Thomas-Krenn-Wiki

Passwörter von lokalen Benutzern werden unter Linux in der Datei /etc/shadow (shadow-Datei) gespeichert.

www.thomas-krenn.com

Wenn es eher experimentell war, bügelst Du vielleicht Mint noch einmal neu drauf.

mit dem Code "su -" ist keine Anmeldung möglich.
es sieht mal nach Neu-Installation aus...naja

 

[hikaru]

Boote von einem Live-System, mounte das root-Dateisystem deiner SSD, und öffne /etc/sudoers auf deiner SSD vom Live-System aus!

 

[fakiauso]

root hat ein Passwort bekommen?

Vermutlich eher nicht, da unter Mint üblicherweise kein User root existiert. Wenn der zusätzliche Account ein normaler User war, der nur sudo ausführen darf, war´s das ohne Extras. sudo su statt su dürfte daher ebenfalls in die Hecke gehen;-)

Es gibt zwar noch ein paar Sachen wie das Bearbeiten der Dateien aus einem Live-System heraus und dem Löschen der Passwörter in der /etc/shadow, damit man es neu setzen kann. Erfahrungsgemäß knallt es dann aber irgendwann wieder, wenn man gar nicht mehr damit rechnet.

Hintricksen kann man das ggf. noch so:

Konfiguration › sudo › Wiki › ubuntuusers.de

wiki.ubuntuusers.de

Im Allgemeinen fährt man bei Ubuntu gut damit, den Root-Account deaktiviert zu lassen und das System ausschließlich über sudo zu administrieren. Es gibt allerdings einen Grund, den Root-Account u.U. zu aktivieren. Wenn nicht-vertrauenswürdige Benutzer direkten Zugang zum Rechner haben, können sie ihn über den Bootmanager Grub im Recovery Modus starten. Ist der Root-Account deaktiviert, erhält ein böswilliger Benutzer so ohne Passwortabfrage eine Root-Shell.

Dort könntest Du dann auch mit automatischen root-Rechten die Dateien bearbeiten.

Oder so:

Passwort zurücksetzen unter Linux | Schritt-für-Schritt-Anleitung

Hier finden Sie eine Schritt-für-Schritt-Anleitung zum Zurücksetzen eines Passworts unter Linux. Befolgen Sie diese Schritte und stellen Sie den Zugang zu Ihrem System effizient wieder her.

gcore.com

 

[Volvo-Berti]

hat alles nix mehr geholfen, ich werde das System einfach mal neu aufsetzen

 

[cuco]

sudo mv /etc/sudoers /etc/sudoers.old

Dann bleibt die originale Datei erhalten und Du kannst diese im Falle eines Aussperrens sogar aus einem Live-System zurück umbenennen.

Vorsicht! mv verschiebt die Datei. Zum Sichern ist das wohl kaum geeignet! Dann wohl eher cp nehmen.

 

[Volvo-Berti]

jetzt isses zu spät, mit dem Befehl kann ich die sudoers.old nicht zurückschieben. Eben weil dieses Audit-Plugin nicht initialisiert werden kann.

ganz vielen Dank an euch für eure Geduld!!

 

[Ravensberger]

alles ein schöner Mist. Bei dem mv Befehlt hatte ich auch gedacht 'bloß nicht', dann aber, da auf der Arbeit, nur flüchtig überflogen und gedacht 'es wird wohl schon eine neue zusätzliche Datei geben'... Ein Umbenennen ist ja immer ein verschieben, im Grunde auch unter Windows.

Zum Glück hat mint aber ein Livesystem auf dem Installationsstick. Hiermit kannst Du zumindest die sudoers ja schnell wieder umbenennen. Falls das System dann weiterhin meckert, was ich noch nicht glaube, kannst Du immer es noch neu aufsetzen.

 

[fakiauso]

Vorsicht! mv verschiebt die Datei. Zum Sichern ist das wohl kaum geeignet! Dann wohl eher cp nehmen.

Nach dem Bearbeiten die *.old latürnich wieder unter dem originalen Namen abspeichern, sonst hat´s freilich keinen Sinn;-)

So wie hier im Nachhinein hätte es ja sowieso nichts mehr gebracht.

 

[Volvo-Berti]

Mal schauen, wie ich das machen kann via Live System. Da hab ich keine Erfahrungen damit.
Wird damit die sudoers bearbeitbar?
Und interessant wird es dann bzgl des audit-Plugins.
Ansonsten halt frisch drauf und gut ist

 

[fakiauso]

Wird damit die sudoers bearbeitbar?

Da Du im Live-System für sudo keine Passwörter brauchst, kannst Du von diesem aus auch alles beackern. Die andere Rückfallebene wäre ja der single-Modus oder eben der recovery-Modus aus dem grub des installierten Systems, der Dir quasi "automatisch" eine root-Shell bereit stellt.

Beitrag automatisch zusammengeführt: 7 Aug. 2025

Dieses audit-Dingens ist nur das Symptom, weil Du Deine sudoers zerbröselt hast und damit kein Zugriff mehr besteht:

Gutes Beispiel:

Fehler mit sudoers › System einrichten und verwalten › Systemverwaltung, Installation, Aktualisierung › Forum › ubuntuusers.de

forum.ubuntuusers.de

 

[cuco]

Nach dem Bearbeiten die *.old latürnich wieder unter dem originalen Namen abspeichern, sonst hat´s freilich keinen Sinn;-)

Und wie willst du die ohne root-Rechte, wenn alles kaputt ist, zurückschieben? mv macht in diesem Fall halt einfach dein System kaputt. Eine Kopie mit cp wäre das einzig sinnvolle, aber auch die kannst du natürlich nur zurückschieben, solange du es nicht verkorkst hast, daher hilft das auch nur begrenzt. Bearbeiten der sudoers natülrich nur mit visudo, um zumindest einen Sanity-Check zu haben. Wenn man die sudoers "gültig verkorkst", hilft aber natürlich auch das nix. Dann ist das System kaputt - so wie jetzt auch, durch den Mist mit dem mv-Befehl. Dann muss man ran, wie von fakiauso beschrieben. Also entweder per GRUB in 'ne Root-Shell und die sudoers reparieren oder über ein Live-System das Dateisystem mounten und dann die sudoers-Datei reparieren. Hier vermutlich nur den mv-Befehl rückgängig machen, in dem man via mv die Datei zurückschiebt.

 

[fakiauso]

Und wie willst du die ohne root-Rechte, wenn alles kaputt ist, zurückschieben?

Es ging ja um vorher, falls Volvo-Berti so etwas das nächste Mal macht. Im Nachhinein bringt es natürlich nichts mehr, aber zu dem Zeitpunkt war es ja bereits zerdeppert.

PS. Notnotfalls kann das ja sogar per Klickibunti im Dateimanager erledigt werden (wobei es da auch wieder Knatsch geben kann, wenn der mit root-Rechten gestartet wird) oder man kopiert die Datei zusätzlich noch auf Stick oder so, damit sie von dort per Livesystem zurückgeschrieben werden kann, gerade wenn man wie hier experimentierfreudig ist.

Wenn es eher noch mehr um das Ausprobieren geht, wäre ein virtuelles System sogar noch besser geeignet, da startet man einfach die VM neu. Aber der TE hat ja gleich das "Produktivsystem" in Angriff genommen;-)

 

[cuco]

Ja, aber auch vorher ist mv eine blöde Idee. Denn genau dann ist das System ja kaputt ^^

 

[Ravensberger]

Das kann doch alles einmal passieren. Jetzt geht es darum, das System wieder laufend zu bekommen. Aus Fehlern lernt man mehr als wenn man sein System nie auch einmal anfasst.

Also, im Live-System kommt man auf die Festplatte über den Dateimanager. Da Mint ein Ubuntu ist, lässt dieses sogar den unsicheren grafischen Start des Dateimanagers zu, falls man ihn für unser Szenario überhaupt benötigt. Lässt sich die Datei sudoers noch einsehen? Dann einfach umbenennen, den Inhalt nochmals prüfen und neu starten. Falls die Datei keinen Text mehr anzeigt, also, warum auch immer, einen Schaden hat, dann hat das Live-System unter /etc/sudoers ebenfalls eine solche Datei, die man "klauen" kann. Auch /etc/group , dieses mal wieder auf der eingehängten Platte der Installation, kann man noch einmal überprüfen und ggf. in die Zeile "sudo:x:27:wir" eintragen.

 

[Volvo-Berti]

es lässt sich auf dem TP nix einsehen bei der Datei, weil es ja diese audit_plugin nicht initialisiert werden kann.
->
also den Rechner vom Stick booten, dort dann die /etc/sudoers aus dem Livesystem auf den Rechner kopieren, soweit richtig?

Ps: das Kopieren hat geklappt.
In /etc/group steht das drin wie oben angegeben.
Es läuft wieder alles!! Ihr seit klasse

@L0nestar ich hoffe, du hast hier mitgelesen zum Lernen, wie man nicht vorgeht