Activer le débogage PAM vers Syslog
Je déteste PAM depuis sa création.
Comment activer le débogage 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 tout simplement pas, ai-je mentionné que je déteste PAM?) Est de creuser dans la source de la bibliothèque du 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 (debug option 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, qui sont des stations-service ici en Allemagne. Eh bien, oui, peut-être que dans tous ces milliards de hits pourraient cacher un indice, mais tirez-moi, je serais mort avant de découvrir.
Le repos est FYI:
Quel problème avais-je?
Après la mise à niveau vers Debian Squeeze, quelque chose est devenu étrange (enfin, hé, c'était une fois, euh, ce qui se passait juste au-dessus de l'Etch .. ah, oui, Woody). Ce n'est donc probablement pas la faute de Debian, juste une configuration ratée de longue durée. J'ai immédiatement 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 assez drôle. Aucun indice dans ssh -v, aucun indice dans /var/log/*, rien. Juste "auth réussi" ou "échec d'auth", parfois le même utilisateur se connectant en parallèle réussit avec une session et échoue avec l'autre, en même temps. Et rien que vous puissiez vraiment obtenir.
Après avoir creusé des trains chargés d'autres options, j'ai pu le découvrir. Il y a nullok et nullok_secure, une spéciale Debian. Quelque chose de foutu avec /etc/securetty et selon le tty (qui est quelque peu aléatoire) une connexion a été rejetée ou non. VRAIMENT Nice, ouf!
La correction a été facile et tout va bien à nouveau.
Cependant, cela m'a laissé avec la question, comment déboguer un tel désordre à l'avenir. Ce n'est pas la première fois que PAM me rend fou. J'aimerais donc voir une solution finale. Finale comme dans "résolu", pas finale 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 le 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
Quittez 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 "debug" à la fin des lignes pertinentes dans /etc/pam.d/system-auth ou l'autre /etc/pam.d/* des dossiers:
login auth required pam_unix.so debug
Ensuite, 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_debug N'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 significatives via syslog.
Mise à jour
Après avoir examiné le code et effectué une compilation, j'ai trouvé (1) qu'il était possible d'activer ce mode de débogage via la source, et (2) un patch RHEL rend la fonctionnalité presque inutilisable (au moins le module pam_unix) et (3) c'est il vaut probablement mieux patcher le code de toute façon.
Pour que cela fonctionne pour RHEL, vous pouvez obtenir le Linux-PAM ... src.rpm (pour toute version 1.1) et modifier le fichier de spécifications comme suit:
Trouvez la ligne commençant par
% configure \
et après cela, ajoutez --enable-debug \
- Supprimez la ligne ou mettez en commentaire la ligne (au-dessus de la précédente) qui commence par% patch2
Ensuite, construisez le rpm et installez (avec force, pour écraser les packages 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 à stderr est, à mon avis, stupide, et c'est ce qui cause le conflit de patchs. Vous pouvez changer ce comportement en allant dans le fichier libpam/include/security/_pam_macros.h et en remplaçant les 4 lignes de
logfile = stderr;
avec
return;
Lors de la construction, vous obtiendrez des avertissements concernant les instructions inaccessibles, mais elles peuvent être ignorées. Vous pouvez faire ce changement dans un script sed (et le mettre dans la section% prep du RPM après les patchs) ...
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.
Je viens de passer plusieurs heures à essayer de savoir comment activer les journaux de débogage dans PAM sur CentOS 6.4. Bien que cette question s'adresse à Debian, je vais quand même écrire comment le faire sur CentOS dans l'espoir que d'autres personnes n'auront pas à mettre le temps que j'ai déjà.
En fin de compte, l'activation des journaux de débogage dans le package pam CentOS est simple. La difficulté vient du fait qu'elle implique une recompilation du package. Donc, trouvez d'abord le SRPM (par exemple pam-1.1.1-13.el6.src.rpm) de ici . Les personnes qui ne connaissent pas la compilation de packages à partir de SRPM peuvent se référer aux étapes sur configuration d'un environnement de construction RPM .
Voici l'étape principale. Ouvrez le fichier de spécifications et ajoutez --enable-debug à la %build section dans l'invocation configure. Recompilez! Réinstallez le package nouvellement créé. Enfin, créez le fichier où les journaux de débogage seront écrits.
$ Sudo touch /var/run/pam-debug.log
Si vous ne créez pas le fichier, de nombreux 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
Je me bats avec un problème lié au pam depuis un jour et demi, 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 cela ressemble quand cela 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 vissé avec/etc/securetty et selon le tty (qui est quelque peu aléatoire) une connexion a été rejetée ou non. VRAIMENT Nice, 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 de securetty qui fonctionne normalement (en supposant que vous vous connectez bien 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 ce que votre /etc/ssh/sshd_config ressemble à.
Notamment, d'après votre description:
- si vous essayez de vous connecter en tant qu'utilisateur root et échouez, cela peut être dû au fait que cette ligne est présente dans
sshd_config:PermitRootLogin no - si certains utilisateurs/groupes fonctionnent, et d'autres non, une raison pourrait être l'utilisation dans
sshd_configdeAllowGroupsouAllowUsers. Un exemple de ligne pourrait ressembler à:AllowGroups users admins
Il est bien sûr tout à fait possible que le PAM fasse partie du problème, mais vos principaux "symptômes" me semblent pouvoir être expliqués par d'autres moyens.