Frage Aktivieren Sie das PAM-Debugging für Syslog


Ich hasse PAM seit es aufkam.

Wie aktiviere ich das PAM-Debugging in Debian Squeeze auf der Admin-Ebene?

Ich habe alle Ressourcen ü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 erwähnt, dass ich PAM hasse?), Graben in die Bibliotheksquelle der PAM.

Ich habe versucht, nach einer Lösung zu googlen, 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 (debug Option für PAM-Einträge in /etc/pam.d/).

Nein, funktioniert nicht.  Kein PAM-Ausgang, nichts, absolute Stille.

Auf der Suche nach einer Lösung habe ich sogar Links zu Pam, den Tankstellen hier in Deutschland, verfolgt. Nun ja, vielleicht könnte all diese Milliarden von Hits einen Hinweis verbergen, aber erschieß mich, ich wäre tot, bevor ich es entdecke.

Rest ist FYI:

Welches Problem hatte ich?

Nach dem Upgrade auf Debian Squeeze wurde etwas komisch (naja, hey, es war einmal, uh, was war über dem Etch ... ah, ja, Woody). Es ist also wahrscheinlich nicht Debians Schuld, nur ein langausgelaufenes 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 gelassen, hilflos wie ein Baby, YKWIM. Einige ssh Logins funktionierten, andere nicht. Es war irgendwie lustig. Keine Hinweise in ssh -v, keine Hinweise in /var/log/*, nichts. Nur "auth succeeded" oder "auth fail", manchmal ist derselbe angemeldete Benutzer parallel mit einer Sitzung erfolgreich und gleichzeitig mit der anderen fehlgeschlagen. Und nichts, was du wirklich bekommen kannst.

Nachdem ich Zugladungen anderer Optionen gegraben hatte, konnte ich es herausfinden. Es gibt nullok und nullok_secure, ein Debian-Special. Etwas hat sich angeschraubt /etc/securetty und abhängig von der tty (was etwas zufällig ist) ein Login wurde abgelehnt oder nicht. Wirklich schön, Puh!

Die Reparatur war einfach und alles ist wieder in Ordnung.

Allerdings hat mich das mit der Frage verlassen, wie man eine solche Unordnung austesten kann in der Zukunft. Es ist nicht das erste Mal, dass PAM mich verrückt macht. Daher würde ich gerne eine endgültige Lösung sehen. Finale wie in "gelöst", nicht endgültig wie in "armageddon". Vielen Dank.

Ah, BTW, dies bestärkte mich wieder in meinem Glauben daran, dass es gut ist, PAM zu hassen, seit es dazu kam. Habe ich erwähnt, dass ich das tue?


33
2018-03-21 02:32


Ursprung


Hier ist, wie man dieses Problem auf Debian selbst erstellt: passwd -d user und versuche dann, in die Box zu kommen user. Die Ausgabe "failed password" in syslog hat nichts mit PAM-Debugging zu tun, so dass PAM nichts sagt. - Tino
Ich habe vergessen zu erwähnen, dass du einstellen musst PermitEmptyPasswords yes im /etc/ssh/sshd_config natürlich, dann gibt PAM sowas aus pam_unix(sshd:auth): authentication failure, aber immer noch nichts zum Debug-Kanal noch irgendeinen Hinweis darauf, welches PAM-Modul den Fehler verursacht hat. - Tino
Hat Debian eine /var/log/auth.log Datei? Ich habe kürzlich entdeckt, dass Ubuntu es hat und alle PAM-bezogenen Sachen dort aufzeichnet. Keine der Antworten hier hat mir geholfen, sondern reingeschaut /var/log/auth.log hat mir geholfen, mein Problem zu lösen. - LordOfThePigs
/var/log/auth.log ist syslog. Das Problem besteht nicht in der Protokollierung, sondern im Debugging. Wenn zum Beispiel der PAM-Stack zu einem frühen Zeitpunkt ausfällt, werden Sie nichts sehen, weil die Module, die ausgegeben werden syslog werden überhaupt nicht aufgerufen. Oder etwas scheitert und etwas nicht, aber beide protokollieren genau dieselben Zeilen. Es ist richtig, dass 95% aller Fälle gelöst werden können, wenn man sich die üblichen Protokolle anschaut, aber 5% nicht, da es einfach keine Spur davon gibt, was wirklich hinter den Kulissen passiert. - Tino
+1 für das Hassen von PAM. ;) - Zayne S Halsall


Antworten:


Ein paar Dinge, die du ausprobieren solltest:

Haben Sie die Protokollierung von Debug-Meldungen in Syslog aktiviert?

cp /etc/syslog.conf /etc/syslog.conf.original
vi /etc/syslog.conf

Fügen Sie die folgende Zeile hinzu:

*.debug     /var/log/debug.log

Beenden mit :wq!.

touch /var/log/debug.log
service syslog restart

Sie können das Debugging für alle Module wie folgt aktivieren:

touch /etc/pam_debug

ODER Sie können das Debugging nur für die Module aktivieren, an denen Sie interessiert sind, indem Sie "debug" am Ende der relevanten Zeilen in hinzufügen /etc/pam.d/system-auth oder das andere /etc/pam.d/* Dateien:

login   auth    required    pam_unix.so debug

Dann sollten Debugging-Meldungen in erscheinen /var/log/debug.log. Hoffe das hilft dir aus!


22
2018-05-12 13:10



Gute Antwort, aber ich denke, ich hatte Syslog Debugging. Ich werde es mir ansehen. - Tino
Ich habe es überprüft, Entschuldigung, deine Antwort ist nicht die Lösung. PAM bleibt immer noch stumm. Vielleicht ist das ein nullok Speziell, dass gerade dieses Modul kein Debugging bietet. Lasst es mich mit diesen Worten sagen: Das Fehlen von Debugging auf solch einem zentralen Code ist ein schlimmerer Albtraum als nur von Freddy Kruger heimgesucht zu werden. - Tino
OK, nun, ich denke du antwortest accutally ist korrekt! Es ist nicht die Schuld, dass PAM ist stumm. Ich akzeptiere es vorläufig als "Lösung" bis PAM kapituliert. Vielen Dank. - Tino
Ich sehe immer noch nicht die Debug-Ausgabe, aber auf Ubuntu 16.04, um syslog debug zu sehen, tun Sie: echo '* .debug /var/log/debug.log'> /etc/rsyslog.d/90-debug. conf; systemctl Neustart rsyslog.service - Noam
Beachten Sie, dass Sie in debug.log die entsprechenden Berechtigungen und die Dateieigentümerschaft benötigen - legen Sie sie auf den gleichen Wert wie syslog fest. (Es ist einfach und leicht zu vergessen.) - mgarey


Zumindest auf CentOS 6.4, /etc/pam_debug ist nicht benutzt.

Wenn das Modul pam_warn.so installiert ist, können Sie auf diese Weise einige Protokollausgaben erhalten:

auth required pam_warn.so

success required pam_warn.so

usw. Dieses Modul stellt sicher, dass es den Authentifizierungsprozess zu keinem Zeitpunkt beeinträchtigt, aber es protokolliert sinnvolle Inhalte über Syslog.

Aktualisieren

Nachdem ich den Code untersucht und etwas kompiliert habe, habe ich festgestellt, dass es möglich ist, diesen Debug-Modus über die Quelle zu aktivieren, und ein RHEL-Patch macht das Feature nahezu unbrauchbar (zumindest das Modul pam_unix) und (3) wahrscheinlich besser, den Code trotzdem zu patchen.

Um dies für RHEL zu erreichen, können Sie Linux-PAM ... src.rpm (für jede Version 1.1) erhalten und die Spezifikationsdatei wie folgt ändern:

  • Finde die Zeile beginnend mit

    % konfigurieren \

und danach hinzufügen        --enable-debug \

  • Entfernen Sie die Zeile oder kommentieren Sie die Zeile (über der vorherigen Zeile), die mit beginnt % patch2

Dann baue die rpm und installiere (mit force, um existierende Pakete zu überschreiben). Erstellen Sie nun die Datei /var/run/pam-debug.log:

install -m 622 /dev/null /var/run/pam-debug.log

Wenn die Datei nicht existiert, wird die Debug-Ausgabe an stderr gesendet.

  • Dieses Aussenden an stderr ist meiner Meinung nach dumm und verursacht den Patch-Konflikt. Sie können dieses Verhalten ändern, indem Sie in die Datei gehen libpam / include / Sicherheit / _pam_macros.h und ersetze die 4 Zeilen von

    logfile = stderr;

mit

return;

Beim Erstellen erhalten Sie Warnungen über nicht erreichbare Anweisungen, die jedoch ignoriert werden können. Sie können diese Änderung in einem sed-Skript vornehmen (und in den% prep-Abschnitt des RPM nach den Patches einfügen) ...

sed -i 's/logfile = stderr;$/return;/' libpam/include/security/_pam_macros.h

Wenn Sie diesen kleinen Patch machen, können Sie% patch2 wiederherstellen, da es wieder richtig funktionieren sollte.


10
2018-06-05 11:13



Vielen Dank. Guter Hinweis. Ich werde es versuchen, wenn ich wieder Probleme habe. Also hoffentlich nie ..;) - Tino
Dies funktionierte für mich, aber beachte, dass du, wenn du SELinux ausführst, die entsprechenden Kontexte auf /var/run/pam-debug.log setzen musst (system_u: object_r: var_log_t hat die meisten Nachrichten abgefangen). Andernfalls wird ein Großteil der Debugging-Ausgabe in den Standardfehler geschrieben (oder automatisch verworfen, wenn Sie das Standardfehlerverhalten des RedHat ausbesserten). - jgibson


Ich habe gerade einige Stunden damit verbracht, herauszufinden, wie Debug-Protokolle in PAM auf CentOS 6.4 aktiviert werden können. Obwohl diese Frage für Debian ist, werde ich immer noch auf CentOS schreiben, in der Hoffnung, dass andere Leute die Zeit, die ich bereits habe, nicht aufbringen müssen.

Wie es sich herausstellte, aktivieren Debug-Protokolle in der pam CentOS-Paket ist einfach. Die Schwierigkeit ergibt sich daraus, dass das Paket neu kompiliert wird. Finde also zuerst die SRPM (z.B. pam-1.1.1-13.el6.src.rpm) von Hier. Leute, die nichts über das Kompilieren von Paketen aus SRPMs wissen, können sich auf die folgenden Schritte beziehen Einrichten einer RPM-Build-Umgebung.

Hier ist der Hauptschritt. Öffnen Sie die Spezifikationsdatei und fügen Sie sie hinzu --enable-debug zum %build Abschnitt in der configure Aufruf. Neu kompilieren! Installieren Sie das neu erstellte Paket neu. Schließlich erstellen Sie die Datei, in der Debug-Protokolle geschrieben werden.

$ sudo touch /var/run/pam-debug.log

Wenn Sie die Datei nicht erstellen, werden viele Protokolle am Terminal vorbeifliegen, was möglicherweise nicht sehr nützlich ist.


6
2017-07-28 07:01



Andere Varianten von Unix oder alles, was PAM zu benutzen wagt, ist ebenfalls sehr willkommen;) - Tino


Debian und Ubuntu (und möglicherweise andere Distributionen) haben eine spezielle Protokolldatei, in die alle Pam-Ausgaben protokolliert werden:

/var/log/auth.log

Ich habe anderthalb Tage mit einem Pam-Problem gekämpft, endlich von dieser Log-Datei erfahren und mich vor dem Wahnsinn gerettet.

Hier ist ein Beispiel für den Inhalt dieser Datei, wenn die Dinge nicht wie geplant verlaufen.

Jul 10 09:31:14 vagrant-ubuntu-trusty-64 pamtester: pam_userdb(vsftpd:auth): user_lookup: could not open database `/etc/vsftpd_users.db': No such file or directory
Jul 10 09:36:20 vagrant-ubuntu-trusty-64 sudo:  vagrant : TTY=pts/1 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/cat /var/log/auth.log

So sieht es aus, wenn es funktioniert:

Jul 10 09:47:00 vagrant-ubuntu-trusty-64 sshd[5222]: pam_unix(sshd:session): session closed for user vagrant
Jul 10 09:50:58 vagrant-ubuntu-trusty-64 sshd[5584]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Jul 10 09:50:58 vagrant-ubuntu-trusty-64 sshd[5584]: Accepted publickey for vagrant from 10.0.2.2 port 54652 ssh2: RSA dd:3b:b8:2e:85:04:06:e9:ab:ff:a8:0a:c0:04:6e:d6
Jul 10 09:50:58 vagrant-ubuntu-trusty-64 sshd[5584]: pam_unix(sshd:session): session opened for user vagrant by (uid=0)
Jul 10 09:51:13 vagrant-ubuntu-trusty-64 sudo:  vagrant : TTY=pts/1 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/cat /var/log/auth.log
Jul 10 09:51:13 vagrant-ubuntu-trusty-64 sudo: pam_unix(sudo:session): session opened for user root by vagrant(uid=0)
Jul 10 09:51:13 vagrant-ubuntu-trusty-64 sudo: pam_unix(sudo:session): session closed for user root
Jul 10 09:51:41 vagrant-ubuntu-trusty-64 pamtester: pam_userdb(vsftpd:auth): user 'foo' granted access
Jul 10 09:51:44 vagrant-ubuntu-trusty-64 sudo:  vagrant : TTY=pts/1 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/cat /var/log/auth.log
Jul 10 09:51:44 vagrant-ubuntu-trusty-64 sudo: pam_unix(sudo:session): session opened for user root by vagrant(uid=0)

Beachten Sie, dass keine der anderen Möglichkeiten zum Aktivieren der PAM-Debug-Protokollierung für mich funktioniert hat.


4
2017-07-10 09:53



Bitte beachten Sie, dass alle Zeilen mögen pam_* tatsächlich sind PAM reaclated. Die anderen Zeilen werden ohnehin von den Tools ausgegeben, unabhängig davon, ob sie PAM verwenden oder nicht. Das bedeutet: Wenn PAM aus irgendeinem Grund leugnet, ist es wirklich schwierig, die wirkliche Ursache zu finden, wenn es in PAM ist. Die Nicht-PAM-Zeilen sind nicht hilfreich (da das Problem in PAM liegt) und die PAM-Zeilen sind oft auch nicht hilfreich, da sie oft zu leise sind. Mit der Anwesenheit vieler PAM-Module ist es wirklich schwer zu erraten, welches Modul der Täter sein könnte, ganz zu schweigen davon, wie man das Debugging aktiviert, da dies für jeden einzelnen anders ist. - Tino
Das hat mir geholfen! Danke dir - Mohammed Noureldin


Etwas, das mit / etc / securetty verschraubt wurde und abhängig von der tty (die etwas zufällig ist) wurde ein Login abgelehnt oder nicht. Wirklich schön, Puh!

Könntest du das ein wenig erweitern?

Pro securetty's manpage:

the file contains the device names of terminal lines (one per line, without leading /dev/) on which root is allowed to login.

Das Verhalten, das Sie beschreiben, klingt ziemlich ähnlich wie securetty funktioniert normal (vorausgesetzt, Sie sind in der Tat als root anmelden).

Einige ssh Logins funktionierten, andere nicht.

Auch hier gibt es möglicherweise Nicht-PAM-Beschränkungen, so dass Sie möglicherweise einen Einblick in Ihre Möglichkeiten erhalten /etc/ssh/sshd_config sieht aus wie.

Bemerkenswert, aus Ihrer Beschreibung:

  • Wenn Sie versuchen, sich als root anzumelden und zu scheitern, könnte das daran liegen, dass diese Zeile in sshd_config: PermitRootLogin no
  • Wenn einige Benutzer / Gruppen arbeiten und andere nicht, könnte ein Grund die Verwendung sein sshd_config von AllowGroups oder AllowUsers. Eine Beispielzeile könnte folgendermaßen aussehen: AllowGroups users admins

Es ist natürlich völlig möglich, PAM ist Teil des Problems, aber Ihre wichtigsten "Symptome" klingen für mich, als ob sie mit anderen Mitteln erklärt werden könnten.


0
2018-03-21 08:33





Asket ... Ich liebte deinen Beitrag wirklich :) Ich habe die letzten 15 Stunden mit solchen Sachen gekämpft ... (Ich hätte vielleicht eine 30-minütige Pause gehabt)

Irgendwie habe ich es funktioniert, indem ich all das getan habe, was du getan hast, was bedeutet, dass ich ein / etc / pam_debug habe und debug an pam-Einträgen. ABER wie in meinem Fall kämpfte ich mit pam_mysqlIch musste einen anderen setzen verbose=1 nach dem debug auf meinen Pam-Einträgen:

mailsystem:~# cat /etc/pam.d/smtp

auth required pam_mysql.so debug sqllog=1 verbose=1 user=mail passwd=imverysecret host=127.0.0.1 db=mail table=mailbox usercolumn=username passwdcolumn=password crypt=1 logtable=log_auth logmsgcolumn=msg logusercolumn=user logpidcolumn=pid loghostcolumn=host logtimecolumn=time

account sufficient pam_mysql.so debug sqllog=1 verbose=1 user=mail passwd=imverysecret host=127.0.0.1 db=mail table=mailbox usercolumn=username passwdcolumn=password crypt=1 logtable=log_auth logmsgcolumn=msg logusercolumn=user logpidcolumn=pid loghostcolumn=host logtimecolumn=times

Dieser "sqllog" dient nur dazu, Protokolle in die DB zu schreiben.

Vielleicht hilft dir das also ein bisschen.

Wir alle hassen PAM. Viel Glück!


-1
2018-05-13 22:14



Danke für den Hinweis, aber leider hilft das nicht: pam_unix(sshd:auth): unrecognized option [verbose=1] - Tino