Aktivieren Sie das PAM-Debugging für Syslog

34

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?

Tino
quelle
Hier ist, wie Sie dieses Problem unter Debian selbst erstellen können: passwd -d userVersuchen Sie dann, wie folgt in die Box zu ssh user. Die Ausgabe "failed password" in syslog hat überhaupt nichts mit PAM-Debugging zu tun, daher bleibt PAM stumm.
Tino
Ich vergaß zu erwähnen , dass Sie setzen müssen 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.
Tino
Hat Debian eine /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.
LordOfThePigs
/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.
Tino
4
+1 für das Hassen von PAM. ;)
Zayne S Halsall

Antworten:

24

Ein paar Dinge, die Sie ausprobieren sollten:

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 Sie mit :wq!.

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

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

touch /etc/pam_debug

ODER Sie können das Debuggen nur für die Module aktivieren, an denen Sie interessiert sind, indem Sie "debug" am Ende der entsprechenden Zeilen in /etc/pam.d/system-authoder in den anderen /etc/pam.d/*Dateien einfügen:

login   auth    required    pam_unix.so debug

Dann sollten Debugging-Meldungen in angezeigt werden /var/log/debug.log. Hoffe das hilft dir weiter!

sn3ak3rp1mp
quelle
Gute Antwort, aber ich glaube, ich hatte Syslog-Debugging auf. Ich werde es mir ansehen.
Tino
Ich habe es überprüft, sorry, deine Antwort ist nicht die Lösung. PAM schweigt immer noch. Vielleicht ist dies eine nullokBesonderheit, dass gerade diesem Modul das Debuggen fehlt. Lassen Sie es mich mit diesen Worten sagen: Das Fehlen eines Debuggings für einen so wichtigen zentralen Code ist ein schlimmerer Albtraum, als nur von Freddy Kruger heimgesucht zu werden.
Tino
OK, naja, ich denke du antwortest genau richtig! Es ist nicht die Schuld der Antwort, die PAMstumm ist. Deshalb akzeptiere ich es vorerst als "Lösung", bis ich PAMkapituliere. Vielen Dank.
Tino
Die Debug-Ausgabe wird immer noch nicht angezeigt. Unter Ubuntu 16.04 können Sie das Syslog-Debug jedoch folgendermaßen anzeigen: echo '* .debug /var/log/debug.log'> /etc/rsyslog.d/90-debug. conf; Systemctl Neustart rsyslog.service
Noam
Beachten Sie, dass Sie für debug.log die richtigen Berechtigungen und Dateieigentümer benötigen - stellen Sie sie auf das gleiche wie für syslog ein. (Es ist einfach und leicht zu vergessen.)
mgarey
10

Zumindest unter CentOS 6.4, /etc/pam_debugwird NICHT verwendet.

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

auth required pam_warn.so

success required pam_warn.so

usw. Dieses Modul stellt sicher, dass es den Authentifizierungsprozess zu keinem Zeitpunkt stört, protokolliert jedoch wichtige Daten über Syslog.

Aktualisieren

Nachdem ich den Code untersucht und kompiliert hatte, stellte ich fest, dass (1) dieser Debug-Modus über die Quelle aktiviert werden kann und (2) ein RHEL-Patch die Funktion nahezu unbrauchbar macht (zumindest das Modul pam_unix) und (3) wahrscheinlich ist es besser, den Code trotzdem zu patchen.

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

  • Suchen Sie die Zeile, die mit beginnt

    % configure \

und danach --enable-debug hinzufügen \

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

Erstellen Sie dann die rpm und installieren Sie sie (mit Kraft, um vorhandene 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 Versenden an stderr ist meiner Meinung nach dumm und verursacht den Patch-Konflikt. Sie können dieses Verhalten ändern, indem Sie in die Datei libpam / include / security / _pam_macros.h wechseln und die 4 Zeilen von ersetzen

    logfile = stderr;

mit

return;

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

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

WENN Sie diesen kleinen Patch ausführen, können Sie den% patch2 wiederherstellen, da er wieder ordnungsgemäß funktionieren sollte.

Otheus
quelle
Vielen Dank. Guter Tipp. Ich werde es versuchen, wenn ich jemals wieder Probleme habe. Also hoffentlich nie ..;)
Tino
Dies hat bei mir funktioniert, aber wenn Sie SELinux ausführen, müssen Sie die entsprechenden Kontexte in /var/run/pam-debug.log festlegen (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 stillschweigend verworfen, wenn Sie das Standardfehlerverhalten des RedHat korrigiert haben).
Jgibson
6

Ich habe gerade mehrere Stunden damit verbracht, herauszufinden, wie Debug-Protokolle in PAM unter CentOS 6.4 aktiviert werden können. Obwohl diese Frage für Debian bestimmt ist, werde ich trotzdem aufschreiben, wie es auf CentOS gemacht wird, in der Hoffnung, dass andere Leute nicht die Zeit investieren müssen, die ich bereits habe.

Wie sich letztendlich herausstellte, ist das Aktivieren von Debug-Protokollen im pamCentOS-Paket unkompliziert. Die Schwierigkeit ergibt sich aus der Tatsache, dass das Paket neu kompiliert werden muss. Finden Sie also zuerst das SRPM (zB pam-1.1.1-13.el6.src.rpm) von hier . Leute, die sich mit dem Kompilieren von Paketen aus SRPMs nicht auskennen, können die Schritte zum Einrichten einer RPM- Erstellungsumgebung nachlesen .

Hier ist der Hauptschritt. Öffnen Sie die Spezifikationsdatei und fügen Sie --enable-debugsie dem %buildAbschnitt im configureAufruf hinzu. Neu kompilieren! Installieren Sie das neu erstellte Paket neu. Erstellen Sie schließlich die Datei, in die die Debug-Protokolle geschrieben werden.

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

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

pdp
quelle
Andere Unix-Varianten oder alles, was es wagt, PAM zu verwenden, sind ebenfalls willkommen;)
Tino
5

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

/var/log/auth.log

Ich habe anderthalb Tage lang mit einem pam-bezogenen Problem zu kämpfen gehabt, schließlich von dieser Protokolldatei erfahren und mich vor dem Wahnsinn bewahrt.

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.

LordOfThePigs
quelle
1
Bitte beachten Sie, dass alle Zeilen wie pam_*tatsächlich PAM realisiert sind. 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 ablehnt, ist es wirklich schwierig, die wahre Ursache zu finden, wenn es sich um PAM handelt. Die Nicht-PAM-Leitungen sind nicht hilfreich (da das Problem in PAM liegt) und die PAM-Leitungen sind oft auch nicht hilfreich, da sie oft zu leise sind. Bei der Anwesenheit vieler PAM-Module fällt es Ihnen wirklich schwer, zu erraten, welches Modul der Schuldige sein könnte, geschweige denn, wie Sie das Debuggen aktivieren können, da dies für jedes einzelne unterschiedlich ist.
Tino
0

Irgendwas mit / etc / securetty geschraubt und je nach tty (was etwas zufällig ist) wurde ein Login abgelehnt oder nicht. WIRKLICH SCHÖN, Puh!

Könnten Sie das etwas näher erläutern?

Manpage pro Sicherheit :

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 nach einer normalen Funktionsweise von securetty (vorausgesetzt, Sie melden sich tatsächlich als root an).

Einige SSH-Logins funktionierten, andere nicht.

Auch hier gelten möglicherweise Nicht-PAM-Einschränkungen. Daher kann es hilfreich sein, einen Einblick in Ihr /etc/ssh/sshd_configAussehen zu erhalten.

Insbesondere aus Ihrer Beschreibung:

  • Wenn Sie versuchen, sich als root anzumelden, und dies fehlschlägt, kann dies an der folgenden Zeile liegen sshd_config:PermitRootLogin no
  • Wenn einige Benutzer / Gruppen funktionieren und andere nicht, kann ein Grund die Verwendung sshd_configvon AllowGroupsoder sein AllowUsers. Eine Beispielzeile könnte folgendermaßen aussehen: AllowGroups users admins

Es ist natürlich durchaus möglich, dass PAM Teil des Problems ist, aber Ihre Hauptsymptome klingen für mich so, als könnten sie auf andere Weise erklärt werden.

Ich wurde von Agrue gegessen
quelle
-1

Asket ... Ich habe deinen Beitrag wirklich geliebt :) Ich habe die letzten 15 Stunden mit so etwas gekämpft ... (Ich hätte allerdings eine Pause von 30 Minuten machen können)

Irgendwie habe ich es zum Laufen gebracht, indem ich alles getan habe, was du getan hast, was bedeutet, dass ich ein / etc / pam_debug und ein Debug für pam-Einträge habe. ABER wie in meinem Fall, mit dem pam_mysqlich zu kämpfen hatte , musste ich einen anderen verbose=1nachher debugauf meine Pam-Einträge setzen:

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

Dieses "sqllog" dient nur zum Schreiben von Protokollen in die DB.

Vielleicht hilft dir das ein bisschen.

Wir alle hassen PAM. Viel Glück!

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