You are not logged in.
Hallo an alle,
ich nutze auf meinem Server die Verwaltungssoftware Froxlor und die Benutzer welcher angelegt wurden werden über libnss-extrausers abgerufen.
Nun bekomme ich seit einigen Tagen diese Meldung und ich kann mich nicht mehr auf den Benutzerkonten über SSH anmelden:
PAM failed: Authentication token is no longer valid; new one required
user@10000.service: Failed to set up PAM session: Operation not permitted
user@10000.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
Wenn ich nun mittels passwd das Passwort ändern möchte erscheint:
passwd: Benutzer »testuser« ist in /etc/passwd nicht vorhanden.
Dies ist zwar korrekt da die Benutzer in "/var/lib/extrausers/passwd" und "/var/lib/extrausers/shadows" gelistet sind, aber eine Passwortänderung derjenigen ist nicht möglich.
Nutze ich dann "passwd -Sa" werden aber alle Benutzer korrekt angezeigt. Wie ändere ich nun das Passwort der Benutzer welche in extrausers abgelegt sind? Auch der Befehl "chage" findet die Benutzer nicht.
Vielen Dank im Voraus.
Last edited by localhorst (2021-06-20 10:23:52)
Offline
https://unix.stackexchange.com/question … etc-shadow
man 5 shadow
extrausers ist eine Debian Geschichte, ich denke nicht, daß Du die vanilla shadow-utils dazu überreden kannst, das zu editieren.
=> sudoedit /var/lib/extrausers/shadows
Der link beschreibt, wie Du Passwörter generieren kannst und die shadow manpage schlüsselt die verschiedenen Felder auf (insbes. die Ablaufdaten dürften interessant sein)
Offline
Wenn das PAM-Modul die Funktionen zur Passwortänderung bereitstellt, dann kann passwd auch das Passwort ändern. Das klappt aber nur, wenn der Benutzer angemeldet ist und die Änderung selbst durchführt. Root kann die Änderung nicht über PAM durchführen.
Dies muss dann aber auch in der PAM-Konfiguration so angegeben werden. ("password required ... " Regeln sollten das sein)
Last edited by progandy (2021-06-20 12:57:54)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Zunächst mal vielen Dank für die Antworten. Leider kann ich mich mit den Benutzern nicht mehr anmelden um die Passwörter zu ändern. Da bleibt mir am Ende nur noch die händische Änderung, ob das klappt werde ich sehen. Das seltsame ist, dass laut Manpage die Höchstdauer auf 99999 Tage gesetzt wurde, diese aber bei weitem noch nicht erreicht sind, die Benutzer wurden im Jahr 2019 angelegt und bei 365 Tagen im Jahr komme ich noch lange nicht auf die 99999 Tage.
Offline
Gibt es einen Eintrag im vorletzten Feld ("Datum, an dem das Konto verfällt, wird als Anzahl der Tage seit dem 1. Januar 1970 ausgedrückt")?
Offline
Ich habe mal eine Zeile aus der shadow genommen, diese sieht bei allen (außer Benutzername und Passwort) gleich aus:
benutzer1:ichbineinpasswort:18797:0:99999:7:::
Wenn ich versuche mich mit dem betroffenen Benutzernamen anzumelden erscheint folgende Ausgabe:
You are required to change your password immediately (administrator enforced).
You are required to change your password immediately (administrator enforced).
You have new mail.
WARNING: Your password has expired.
You must change your password now and login again!
passwd: Benutzer bei zu Grunde liegendem Authentifizierungsmodul nicht bekannt
passwd: Passwort nicht geändert
EDIT: Was mir noch aufgefallen ist, dass es folgende Meldung im journal gibt:
335 Prüfe auf überwachte Datei »/var/db/passwd.db«: Datei oder Verzeichnis nicht gefunden
Es gibt keine /var/db/passwd.db sondern nur eine "/var/db/nscd/passwd". Könnte hier mit der Fehler liegen oder sind das zwei verschiedene paar Schuhe.
Last edited by localhorst (2021-06-20 14:05:49)
Offline
Systemd Regression?
https://github.com/systemd/systemd/pull/19773
Edit: allerdings sagt der RH bug "systemd-239" …
Edit #2: nscd mault deswegend dauernd, https://sourceware.org/bugzilla/show_bug.cgi?id=20036
Last edited by seth (2021-06-20 14:15:23)
Offline
Ohje sorry so tief stecke ich nicht in der Materie drin, systemd hat die Version 248.3-2 soviel kann ich noch sagen.
Gut, wenn nscd mault aber nichts weiter dahinter steckt, bin ich damit zufrieden.
Offline
Ich weiß nicht wie relevant das ist - der RH bug ist neu, aber wenn das Problem in system-239 (von 2018) bestand, ist ein systemd update eher nicht der Grund, warum der login erst jetzt scheitert.
Und das Passwort händisch oder nicht zurückzusetzen wird eher nichts ändern, da es formal nicht abgelaufen ist.
Hat evtl. ein update /etc/pam.d/* oder /etc/nsswitch.conf zurückgesetzt?
Offline
Naja ich lass ab und an mal ein pacman -Syu drüberlaufen, schaue aber danach nicht explizit alle Funktionen durch ob diese noch funktionieren. Die /etc/nsswitch.conf sieht noch normal aus, also keine Änderungen. In /etc/pam.d/* gibt es verschiedene Speicherdatas. Ich wüsste aber nicht ob sich da was geändert hat, da ich da noch nie reingeschaut hatte. Wie gesagt bis vor ein paar Wochen funktionierte es noch, aber das ist natürlich keine gute Problemaussage meinerseits.
Das ganze betrifft auch nur die Benutzer in extrausers, alle anderen welche in der normalen passwd drin sind haben keine Probleme.
/etc/nsswitch.conf
passwd: compat extrausers
group: compat extrausers
shadow: compat extrausershosts: files dns
networks: files dnsservices: db files
protocols: db files
rpc: db files
ethers: db files
netmasks: files
netgroup: files
bootparams: filesautomount: files
aliases: files
Last edited by localhorst (2021-06-20 15:56:46)
Offline
passwd: compat extrausers
group: compat extrausers
shadow: compat extrausers
Mein Verdacht war, daß das jetzt fehlt.
Funktioniert ein lokaler login (im Zweifel via su), ie. betrifft das Ganze nur ssh?
Offline
Also wenn ich mich mit einem Benutzer (aus /etc/passwd) anmelde, dann funktioniert dieser Login. Wenn ich danach mittels su benutzername (Benutzer aus extrausers) zugreifen möchte erscheint:
Sie müssen Ihr Passwort sofort ändern (von root erzwungen).
su: Benutzer bei zu Grunde liegendem Authentifizierungsmodul nicht bekannt
Also sagt er mir zwar das ich ändern muss, will wahrscheinlich dann mittels passwd die Änderung anschieben, scheitert aber daran. Denn wenn ich sudo passwd benutzername eingebe erscheint:
passwd: Benutzer bei zu Grunde liegendem Authentifizierungsmodul nicht bekannt
passwd: Passwort nicht geändert
Offline
Hat das vorhandene passwort einen salt?
$6$salt$langerhash
Edit, idee von diesem patch: https://bodhi.fedoraproject.org/updates … e6916d6758
Last edited by seth (2021-06-20 16:17:20)
Offline
Also sagt er mir zwar das ich ändern muss, will wahrscheinlich dann mittels passwd die Änderung anschieben, scheitert aber daran. Denn wenn ich sudo passwd benutzername eingebe erscheint:
passwd: Benutzer bei zu Grunde liegendem Authentifizierungsmodul nicht bekannt
passwd: Passwort nicht geändert
Damit passwd funktioniert, muss in /etc/pam.d/passwd das Module pam_extrausers eingetragen sein, wie im Beispiel auf der Manpage:
https://manpages.ubuntu.com/manpages/bi … ers.8.html
Etwas ähnliches muss für alle pam Sitzungen gemacht werden, die das Passwort ändern können sollen.
Last edited by progandy (2021-06-20 16:23:15)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Mich stört ggw. deutlich mehr daß das vorhandene Passwort gültig sein sollte™ - wenn es der fehlende salt ist, erschlägt passwd es, aber ansonsten ändert er das Passwort und sonst nichts :\
Offline
Dass die alten Passwörter ersetzt werden müssen ist vermutlich diesem Update geschuldet:
https://archlinux.org/news/sorting-out- … rd-hashes/
https://www.archlinux.de/news/34044-lib … esselungen
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Also ein Salt hat das Passwort scheinbar schon: $5$irgendwas$irgenwas -> bei allen Passwörtern so. Ich habe jetzt einen ganz neuen Benutzer mit Froxlor angelegt, dieser wurde auch in shadows (extrauser) eingetragen mit Salt, aber selbst bei dem kann ich mich nicht anmelden:
su neuerUser
Passwort:
Sie müssen Ihr Passwort sofort ändern (von root erzwungen).
su: Benutzer bei zu Grunde liegendem Authentifizierungsmodul nicht bekannt
Langsam bin ich verwirrt.
Offline
DANKE DANKE für eure Hilfe ihr seit echt toll. Ich habe jetzt libxcrypt wieder mittels "downgrade libxcrypt" auf libxcrypt-4.4.20-1 gesetzt und schon funktioniert alles wieder!!! Tolle Sache!!!
EDIT:
Das ganze ging an mir vorbei da libxcrypt-4.4.21 gar nicht erst installiert wurde sondern gleich auf 4.4.22 somit kommt es mit den paar Wochen zuvor, als es noch funktionierte hin. Gleich in pacman.conf als ignore eingetragen erstmal.
Last edited by localhorst (2021-06-20 16:57:37)
Offline
Es wäre besser, die Passwörter zu aktualisieren und den stärkeren hash zu verwenden (sha512)
Geht auch mit der älteren libxcrypt
Offline
Ja hab ich gemacht, habe in Froxlor Sha512 auswählen können, alle Passwörter neu erstellt. Nun funktioniert es auch mit der neusten Version von libxcrypt.
Offline