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 ( 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, 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 nullok
et nullok_secure
, une spéciale Debian. Quelque chose de foutu avec /etc/securetty
et 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?
PermitEmptyPasswords yes
dans /etc/ssh/sshd_config
bien 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.
/var/log/auth.log
fichier? 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.log
dedans m'a aidé à résoudre mon problème.
/var/log/auth.log
est 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 syslog
ne 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.
passwd -d user
et essayez ensuite de faire ssh dans la boîte comme ceciuser
. La sortie "mot de passe échoué" dans syslog n'a rien à voir avec le débogage de PAM. Par conséquent, PAM reste silencieux.