Ich hasse PAM, seit es auftaucht.
Wie aktiviere ich das PAM-Debugging in Debian Squeeze auf Administratorebene?
Ich habe jede Ressource überprüft, die ich finden konnte. Google, Hilfeseiten, was auch immer. Das Einzige, was ich noch nicht ausprobiert habe (ich wage es einfach nicht, habe ich schon erwähnt, dass ich PAM hasse?), Ist, in der Bibliotheksquelle von PAM zu stöbern.
Ich habe versucht, nach einer Lösung zu suchen, nichts. Was ich bisher gefunden habe:
http://www.bitbull.ch/wiki/index.php/Pam_debugging_funktion ( /etc/pam_debug) und
http://nixdoc.net/man-pages/HP-UX/man4/pam.conf.4.html ( debugOption für PAM-Einträge in /etc/pam.d/).
Nein, funktioniert nicht. Keine PAM-Ausgabe, nichts, absolute Stille.
Auf der Suche nach einer Lösung bin ich sogar Links zu Pam gefolgt, das sind Tankstellen hier in Deutschland. Na ja, bei all den Milliarden von Treffern könnte sich vielleicht ein Hinweis verbergen, aber erschieß mich, ich wäre tot, bevor ich es herausfinde.
Rest ist FYI:
Welches Problem hatte ich?
Nach dem Upgrade auf Debian Squeeze wurde etwas seltsam (nun, hey, es war einmal, äh, was direkt über dem Etch war ... ah, ja, Woody). Es ist also wahrscheinlich nicht Debians Schuld, sondern nur ein langlebiges vermasseltes Setup. Ich hatte sofort den Eindruck, dass es etwas mit PAM zu tun hat, aber ich wusste wirklich nicht, was los ist. Ich war völlig im Dunkeln, allein, hilflos wie ein Baby, YKWIM. Einige SSH-Logins funktionierten, andere nicht. Es war irgendwie lustig. Keine Anhaltspunkte ssh -v, keine Anhaltspunkte /var/log/*, nichts. Nur "Authentifizierung erfolgreich" oder "Authentifizierung fehlgeschlagen", manchmal war derselbe Benutzer, der sich anmeldet, bei einer Sitzung gleichermaßen erfolgreich und bei der anderen fehlgeschlagen. Und nichts, woran Sie wirklich kommen können.
Nachdem ich eine Menge anderer Optionen ausgegraben hatte, konnte ich es herausfinden. Es gibt nullokund nullok_secure, ein Debian-Special. Irgendwas mit /etc/securettyund je nach tty(was etwas zufällig ist) wurde ein Login abgelehnt oder nicht. WIRKLICH SCHÖN, Puh!
Die Lösung war einfach und alles ist wieder in Ordnung.
Dies ließ mich jedoch bei der Frage zurück, wie man ein solches Durcheinander in Zukunft beseitigen kann. Es ist nicht das erste Mal, dass PAM mich verrückt macht. Ich würde also gerne eine endgültige Lösung sehen. Final wie in "gelöst", nicht final wie in "armageddon". Vielen Dank.
Übrigens, dies hat meinen Glauben wieder verstärkt, dass es gut ist, PAM zu hassen, seit es auftaucht. Habe ich das schon erwähnt?
PermitEmptyPasswords yesin /etc/ssh/sshd_confignatürlich dann PAM gibt so etwas wie pam_unix(sshd:auth): authentication failure, aber immer noch nichts an den Debug - Kanal noch jeden Hinweis verursacht , die PAM - Modul den Fehler.
/var/log/auth.logDatei? Ich habe kürzlich entdeckt, dass Ubuntu es hat und protokolliere alle pam-bezogenen Sachen dort. Keine der Antworten hier hat mir geholfen, aber ein Blick hinein /var/log/auth.loghat mir geholfen, mein Problem zu beheben.
/var/log/auth.logist syslog. Das Problem ist nicht die Protokollierung, sondern das Debuggen. Wenn beispielsweise der PAM-Stack vorzeitig ausfällt, sehen Sie nichts, da die Module, die ausgegeben werden sollen, syslogüberhaupt nicht aufgerufen werden. Oder etwas schlägt fehl und etwas nicht, aber beide protokollieren genau die gleichen Zeilen. Es ist richtig, dass ich denke, 95% aller Fälle können gelöst werden, indem man in die üblichen Protokolle schaut, aber 5% können nicht, da es einfach keine Spur von dem gibt, was wirklich hinter den Kulissen passiert.
passwd -d userVersuchen Sie dann, wie folgt in die Box zu sshuser. Die Ausgabe "failed password" in syslog hat überhaupt nichts mit PAM-Debugging zu tun, daher bleibt PAM stumm.