Aktivieren Sie das PAM-Debugging für Syslog

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?

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!

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.

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.

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.

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.

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!