Activer le débogage de PAM vers Syslog

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?

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!

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.

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.

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.

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.

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!