I just noticed, that I wasn't able to login to my server using ssh after the upgrade to pam 0.78 (pam 0.77-r8 works). I'm using nss_ldap and pam_smbpass (which in turn uses the LDAP backend). I don't see anything special in the log, just "authentication failure". Perhaps this only happens when I'm using LDAP as backend for the users, I'm not sure (root, which is a classic user in /etc/passwd and /etc/shadow, works). If someone has an idea what might be going on... I don't. It is not related to nss_ldap, since pam 0.78 works with nss_ldap and kerberos on another machine. I'm using: [ebuild R ] net-libs/nss_ldap-234 [ebuild R ] net-fs/samba-3.0.11 [ebuild R ] net-nds/openldap-2.2.23-r1 My /etc/pam.d/system-auth: #%PAM-1.0 auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_unix.so likeauth nullok nodelay auth sufficient /lib/security/pam_smbpass.so use_first_pass auth required /lib/security/pam_deny.so account required /lib/security/pam_unix.so password required /lib/security/pam_cracklib.so retry=3 password sufficient /lib/security/pam_unix.so nullok md5 shadow use_authtok try_first_pass password sufficient /lib/security/pam_smbpass.so use_authtok try_first_pass password required /lib/security/pam_deny.so session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so session optional /lib/security/pam_mkhomedir.so silent Reproducible: Always Steps to Reproduce: Portage 2.0.51-r15 (default-linux/x86/2005.0, gcc-3.4.3, glibc-2.3.4.20050125-r0, 2.6.11-rc4-cs1 i686) ================================================================= System uname: 2.6.11-rc4-cs1 i686 Intel(R) Pentium(R) M processor 1.70GHz Gentoo Base System version 1.6.9 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Feb 17 2005, 21:44:36)] distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.94.0.2.2 sys-devel/libtool: 1.5.10-r5 virtual/os-headers: 2.6.10 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium-m -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/fax /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/alias /var/qmail/control /var/spool/fax/etc" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium-m -O2 -pipe -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks nostrip sandbox sfperms" GENTOO_MIRRORS="ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.easynet.nl/mirror/gentoo/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo" LANG="de_DE@euro" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aalib acl alsa apm authdaemond avi bash-completion berkdb bitmap-fonts bonobo cdr crypt cups curl devmap dga droproot dvd emboss encode esd ethereal f77 fam flac foomaticdb fortran gd gdbm gif gnome gnutls gpm gstreamer gtk gtk2 gtkhtml guile hal i8x0 imagemagick imap imlib ipv6 java jpeg junit kerberos ldap libcaca libg++ libwww mad maildir mikmod mmx motif mozilla mpeg mysql ncurses nfsv4 nls nptl odbc oggvorbis opengl oss pam pdflib perl png postgres python qt quicktime quotas readline samba sasl sdl slang slp snmp spell sse sse2 ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts usb x86 xinerama xml xml2 xv xvmc zlib" Unset: ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
I forgot: Strangely, PubkeyAuthentication also fails.
The same happens with pam_krb5. I am also using nss_ldap. root login using krb5 password works, so the problem must be related to nss_ldap. (pam-0.77-r8 works ok.) Feb 28 11:31:23 [login(pam_unix)] check pass; user unknown Feb 28 11:31:23 [login(pam_unix)] authentication failure; logname= uid=0 euid=0 tty=/dev/vc/2 ruser= rhost= Feb 28 11:31:23 [login] pam_krb5[9944]: authentication succeeds for 'andrej' (andrej@F9.IJS.SI) Feb 28 11:31:23 [login] Authentication service cannot retrieve authentication info. for andrej from f9pc46.ijs.si
It's even worse than I thought. I was just notified that none of the per-user crontab entries were working. The log just says "Unable to retrieve authentication info". It also says that every time I want to su to a user. (But it then ignores this because of pam_rootok) - this is using LDAP+KRB5 This really sucks. There is something wrong with PAM 0.78.
Ok. I just tried to figure out what is happening. Apparently pam_unix is more strict now. An account is always considered invalid if it has no shadow entry (which is a problem when the authentication is not done via the shadow mechanism). The old behavior can be restored by adding broken_shadow to the pam_unix.so options in /etc/pam.d/system_auth (and /etc/pam.d/cron). For pam_ldap, pam_smbpass and pam_krb5 users you should add a warning message to the pam 0.78 ebuild. It now works, I think this bug can be closed.
I have checked that. broken_shadow works also for pam_krb5, so the bug can be closed.
Right, but in theory if pam_unix failed, it should have considered pam_smbpass ... I think it might be related to an issue which might be fixed in 0.79. I will try to push 0.79 soonish, please test that and reopen if it have the same issues.
