Activer le débogage de PAM vers Syslog


34

Je déteste PAM depuis qu'il est apparu.

Comment activer le débogage de PAM dans Debian Squeeze au niveau administrateur?

J'ai vérifié toutes les ressources que j'ai pu trouver. Google, pages de manuel, peu importe. La seule chose que je n'ai pas encore essayée (je n'ose simplement pas, est-ce que j'ai déjà dit que je déteste PAM?), C'est fouiller dans la source de la bibliothèque de PAM.

J'ai essayé de google pour une solution, rien. Ce que j'ai trouvé jusqu'à présent:

http://www.bitbull.ch/wiki/index.php/Pam_debugging_funktion ( /etc/pam_debug) et http://nixdoc.net/man-pages/HP-UX/man4/pam.conf.4.html ( debugoption sur les entrées PAM) dans /etc/pam.d/).

Non, ça ne marche pas. Pas de sortie PAM, rien, silence absolu.

En cherchant une solution, j'ai même suivi des liens vers Pam, des stations-service ici en Allemagne. Eh bien, oui, peut-être que dans tous ces milliards de hits pourrait cacher un indice, mais tirez-moi, je serais mort avant que je découvre.

Le reste est FYI:

Quel problème avais-je?

Après la mise à niveau vers Debian Squeeze, quelque chose est devenu bizarre (enfin, hé, c’était, euh, ce qui était juste au-dessus de l’Etch… ah, oui, Woody). Donc ce n’est probablement pas la faute de Debian, c’est juste une installation foirée de longue vie. J'ai tout de suite eu l'impression qu'il fallait faire quelque chose avec PAM, mais je ne savais vraiment pas ce qui se passait. J'étais complètement dans le noir, laissé seul, impuissant comme un bébé, YKWIM. Certaines connexions SSH ont fonctionné, d'autres non. C'était un peu drôle. Aucun indice ssh -v, aucun indice /var/log/*, rien. Juste "auth successed" ou "auth fail", parfois le même utilisateur qui se connecte a réussi simultanément avec une session et a échoué avec l'autre, en même temps. Et rien que vous ne puissiez vraiment vous procurer.

Après avoir creusé des tonnes de trains d’autres options, j’ai pu le découvrir. Il y a nulloket nullok_secure, une spéciale Debian. Quelque chose de foutu avec /etc/securettyet selon le tty(ce qui est un peu aléatoire) un login a été rejeté ou non. Vraiment sympa, ouf!

La solution était facile et tout va bien à nouveau.

Cependant, cela me laissait avec la question, comment déboguer un tel gâchis à l'avenir. Ce n'est pas la première fois que PAM me rend fou. Je voudrais donc voir une solution finale. Final comme dans "résolu", pas final comme dans "armageddon". Merci.

Ah, BTW, cela a encore renforcé ma conviction qu'il est bon de détester PAM depuis son apparition. Ai-je mentionné que je fais?


Voici comment créer vous-même ce problème sur Debian: passwd -d useret essayez ensuite de faire ssh dans la boîte comme ceci user. La sortie "mot de passe échoué" dans syslog n'a rien à voir avec le débogage de PAM. Par conséquent, PAM reste silencieux.
Tino

J'ai oublié de mentionner que vous devez définir PermitEmptyPasswords yesdans /etc/ssh/sshd_configbien sûr, puis de quelque chose de PAM comme pam_unix(sshd:auth): authentication failure, mais toujours rien au canal de débogage , ni aucune indication quel module PAM ont provoqué l'échec.
Tino

Est-ce que Debian a un /var/log/auth.logfichier? J'ai récemment découvert qu'Ubuntu en possédait et y consignait tous les trucs relatifs à pam. Aucune des réponses ici ne m'a aidé, mais regarder /var/log/auth.logdedans m'a aidé à résoudre mon problème.
LordOfThePigs

/var/log/auth.logest syslog. Le problème n'est pas la journalisation mais le débogage. Si, par exemple, la pile PAM échoue tôt, vous ne verrez rien, car les modules vers lesquels la sortie est générée syslogne sont pas appelés du tout. Ou quelque chose échoue et pas du tout, mais les deux consignent exactement les mêmes lignes. Il est vrai que, je suppose, 95% de tous les cas peuvent être résolus en consultant les journaux habituels, mais 5% ne le peuvent pas, car il n’ya tout simplement aucune trace de ce qui se passe réellement dans les coulisses.
Tino

4
+1 pour haïr PAM. ;)
Zayne S Halsall

Réponses:


24

Quelques choses à essayer:

Avez-vous activé la journalisation des messages de débogage dans Syslog?

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

Ajoutez la ligne suivante:

*.debug     /var/log/debug.log

Sortez avec :wq!.

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

Vous pouvez activer le débogage pour tous les modules comme ceci:

touch /etc/pam_debug

OU vous pouvez activer le débogage uniquement pour les modules qui vous intéressent en ajoutant "débogage" à la fin des lignes correspondantes dans /etc/pam.d/system-authles autres /etc/pam.d/*fichiers:

login   auth    required    pam_unix.so debug

Les messages de débogage devraient commencer à apparaître dans /var/log/debug.log. J'espère que cela vous aide!


Bonne réponse, mais je pense que je devais déboguer syslog. Je vais vérifier cela.
Tino

Je l'ai vérifié, désolé, votre réponse n'est pas la solution. PAM reste toujours silencieux. Peut-être est-ce une nullokparticularité que ce module manque juste de débogage. Permettez-moi de le dire avec ces mots: l'absence de débogage sur un élément de code aussi crucial est un pire cauchemar que d'être simplement hanté par Freddy Kruger.
Tino

OK, eh bien, je pense que vous répondez que c'est exact! Ce n'est pas la faute de la réponse qui PAMest muette. Donc pour le moment je l’accepte comme "solution" jusqu’à PAMcapituler. Merci.
Tino

Je ne vois toujours pas la sortie de débogage, mais de toute façon, sous Ubuntu 16.04, pour afficher le débogage de syslog, faites: echo '* .debug /var/log/debug.log'> /etc/rsyslog.d/90-debug. conf; systemctl restart rsyslog.service
Noam

Notez que vous avez besoin des autorisations appropriées et de la propriété du fichier sur debug.log - définissez-le sur la même chose que syslog. (C'est simple et facile à oublier.)
mgarey

10

Au moins sur CentOS 6.4, /etc/pam_debugn'est pas utilisé.

Si le module pam_warn.so est installé, vous pouvez obtenir une sortie de journalisation de cette façon:

auth required pam_warn.so

success required pam_warn.so

etc. Ce module garantit qu’il n’interférera à aucun moment avec le processus d’authentification, mais il enregistre des informations utiles via syslog.

Mise à jour

Après avoir examiné le code et procédé à la compilation, j'ai constaté qu'il était possible (1) d'activer ce mode de débogage via le code source, et (2) un correctif RHEL rend la fonctionnalité presque inutilisable (au moins le module pam_unix) et (3) c'est probablement mieux de patcher le code de toute façon.

Pour que cela fonctionne avec RHEL, vous pouvez obtenir le fichier Linux-PAM ... src.rpm (pour toute version 1.1) et modifier le fichier de spécification comme suit:

  • Trouvez la ligne commençant par

    % configure \

et ensuite, ajoutez --enable-debug \

  • Supprimez la ligne ou commentez la ligne (au-dessus de la précédente) qui commence par% patch2

Ensuite, construisez le rpm et installez (avec force, pour écraser les paquets existants). Créez maintenant le fichier /var/run/pam-debug.log:

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

Si le fichier n'existe pas, la sortie de débogage sera envoyée à stderr.

  • Cet envoi vers stderr est, à mon avis, stupide et est ce qui cause le conflit de patch. Vous pouvez changer ce comportement en allant dans le fichier libpam / include / security / _pam_macros.h et en remplaçant les 4 lignes de

    fichier journal = stderr;

avec

return;

Lors de la construction, vous recevrez des avertissements concernant les instructions inaccessibles, mais elles peuvent être ignorées. Vous pouvez faire cette modification dans un script sed (et le mettre dans la section% prep du RPM après les correctifs) ...

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

SI vous faites ce petit patch, vous pouvez restaurer le% patch2, car il devrait fonctionner à nouveau correctement.


Merci. Bon indice. Je vais essayer si j'ai encore des problèmes. Donc, espérons jamais ..;)
Tino

Cela a fonctionné pour moi, mais notez que si vous utilisez SELinux, vous devrez définir les contextes appropriés sur /var/run/pam-debug.log (system_u: object_r: var_log_t a capturé la plupart des messages). Sinon, une grande partie de la sortie de débogage sera écrite en erreur standard (ou ignorée en mode silencieux si vous corrigez le comportement d'erreur standard de RedHat).
Jgibson

6

Il m'est arrivé de passer plusieurs heures à essayer de savoir comment activer les journaux de débogage dans PAM sous CentOS 6.4. Bien que cette question s’adresse à Debian, j’écrirai quand même comment le faire sous CentOS dans l’espoir que d’autres personnes n’auront pas à passer le temps que je dispose déjà.

En fin de compte, l'activation des journaux de débogage dans le pampackage CentOS est simple. La difficulté provient du fait qu'il s'agit d'une recompilation du package. Donc, commencez par trouver le SRPM (par exemple pam-1.1.1-13.el6.src.rpm) à partir d’ ici . Les personnes qui ne connaissent pas la compilation de packages à partir de SRPM peuvent se référer aux étapes de la configuration d'un environnement de génération RPM .

Voici l'étape principale. Ouvrez le fichier de spécification et ajoutez-le --enable-debugà la %buildsection de l' configureappel. Recompiler! Réinstallez le package nouvellement créé. Enfin, créez le fichier dans lequel les journaux de débogage seront écrits.

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

Si vous ne créez pas le fichier, beaucoup de journaux voleront au terminal, ce qui pourrait ne pas être très utile.


D'autres saveurs d'Unix ou de tout ce qui ose utiliser PAM sont également les bienvenues;)
Tino

5

Debian et Ubuntu (et peut-être d'autres distributions) ont un fichier journal spécial dans lequel toutes les sorties pam sont enregistrées:

/var/log/auth.log

Cela fait un jour et demi que je lutte avec un problème lié à la pam, j'ai finalement découvert ce fichier journal et me suis sauvé de la folie.

Voici un exemple du contenu de ce fichier lorsque les choses ne se passent pas comme prévu.

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

Voici à quoi ça ressemble quand ça fonctionne:

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)

Notez qu'aucune des autres possibilités d'activation de la journalisation du débogage de pam n'a fonctionné pour moi.


1
Veuillez noter que toutes les lignes, comme en pam_*réalité, sont réalisées par PAM. Les autres lignes sont quand même générées par les outils, qu'ils utilisent ou non PAM. Cela signifie que si PAM refuse, pour une raison quelconque, il est vraiment difficile de trouver la cause réelle, si cela se trouve dans PAM. Les lignes non-PAM ne sont pas utiles (car le problème se trouve dans PAM) et les lignes PAM ne le sont souvent pas non plus, car elles sont souvent trop silencieuses. Avec la présence de nombreux modules PAM, vous avez vraiment du mal à deviner quel module pourrait être le coupable, et encore moins de savoir comment activer le débogage, car cela est différent pour chacun d'entre eux.
Tino

0

Quelque chose de foutu avec / etc / securetty et dépendant du tty (ce qui est un peu aléatoire) un login a été rejeté ou non. Vraiment sympa, ouf!

Pourriez-vous développer un peu cela?

Par page de manuel de securetty :

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

Le comportement que vous décrivez ressemble beaucoup à celui que sécuretty fonctionne normalement (en supposant que vous vous connectez en tant que root).

Certaines connexions SSH ont fonctionné, d'autres non.

Ici aussi, il peut y avoir des restrictions non-PAM en place, il peut donc être utile de donner un aperçu de votre /etc/ssh/sshd_configapparence.

Notamment, d'après votre description:

  • Si vous essayez de vous connecter en tant que root et que vous échouez, cela peut être dû au fait que cette ligne est présente dans sshd_config:PermitRootLogin no
  • si certains utilisateurs / groupes travaillent, et d'autres pas, une des raisons peut être l'utilisation sshd_configde AllowGroupsou AllowUsers. Un exemple de ligne pourrait ressembler à ceci: AllowGroups users admins

Il est bien entendu tout à fait possible que l’APM fasse partie du problème, mais vos principaux «symptômes» me semblent pouvoir s’expliquer par d’autres moyens.


-1

Asket ... J'ai vraiment adoré votre message :) Je me suis battu avec des trucs comme celui-ci pendant les 15 dernières heures ... (j'aurais peut-être eu une pause de 30 minutes cependant)

D'une façon ou d'une autre, je l'ai obtenu en faisant tout ce que vous avez fait, ce qui signifie que j'ai un fichier / etc / pam_debug et un débogage pour les entrées pam. MAIS comme dans mon cas je me débattais avec pam_mysql, je devais mettre un autre verbose=1après debugsur mes entrées de pam:

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

Ce "sqllog" est juste pour écrire des journaux dans la base de données.

Alors peut-être que cela vous aide un peu.

Nous détestons tous PAM. Bonne chance!


1
Merci pour l'allusion, mais malheureusement, cela n'aide pas:pam_unix(sshd:auth): unrecognized option [verbose=1]
Tino le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.