sshd: PAM adding faulty module

[Bolek]

Binary package hint: openssh-server

After installing Hardy Heron, I see following messages in my log when connecting to my system using SSH (telnet and ftp are disabled so I cannot comment on those):

Apr 27 10:52:03 tux-229 sshd[733]: PAM adding faulty module: /lib/security/migrate
Apr 27 10:52:03 tux-229 sshd[733]: PAM unable to dlopen(/lib/security/nullok)
Apr 27 10:52:03 tux-229 sshd[733]: PAM [error: /lib/security/nullok: cannot open shared object file: No such file or directory]

Each time a connection is made, these three entries are added. I checked the pointers, and indeed, these modules are not installed:

/lib/security/migrate
/lib/security/nullok
/lib/security/migrate

Providing that I have performed a standard Hardy Heron installation, I cannot imagine the above three mentioned security modules were 'optional' and would require me to install them manually. Can anybody, please, comment on this? This issue was not present in Gutsy and I can say with certainty, that it is a Hardy Heron 'phenomenon'.

Information as per your request:

1)
=> lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

2)
=> apt-cache policy openssh-server openssh-client
openssh-server:
  Installed: 1:4.7p1-8ubuntu1
  Candidate: 1:4.7p1-8ubuntu1
  Version table:
 *** 1:4.7p1-8ubuntu1 0
        500 http://ubuntu.media.mit.edu hardy/main Packages
        100 /var/lib/dpkg/status
openssh-client:
  Installed: 1:4.7p1-8ubuntu1
  Candidate: 1:4.7p1-8ubuntu1
  Version table:
 *** 1:4.7p1-8ubuntu1 0
        500 http://ubuntu.media.mit.edu hardy/main Packages
        100 /var/lib/dpkg/status

3) I do not expect to see following message in the log upon logging via ssh:

Apr 27 10:52:05 tux-229 sshd[1059]: PAM adding faulty module: /lib/security/migrate
Apr 27 10:52:05 tux-229 sshd[1059]: PAM unable to dlopen(/lib/security/nullok)
Apr 27 10:52:05 tux-229 sshd[1059]: PAM [error: /lib/security/nullok: cannot open shared object file: No such file or directory]

4) No applicable as per #3. It appears that PAM modules are missing as per my earlier description of the problem.

Thanks.

[Colin Watson (cjwatson)]

Looks rather like bug 216990. The error messages are mangled relative to that, though, and definitely don't look right - perhaps you could post /etc/pam.d/common-auth?

[Bolek (bmynars)]

As per Colin's suggestion, I am including the content of common-auth:

Current:

=> cat common-auth
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
auth requisite pam_unix.so nullok_secure
auth optional migrate

Original:

=> cat common-auth.04222008
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
auth requisite pam_unix.so nullok_secure
auth optional pam_smbpass.so migrate

They both generated the same error messages.

[Bolek (bmynars)]

Hi Colin,

I followed the link you provided to bug 216990. It fixed the issue. :-) Can I submit a RFC, though, to ensure that libpam-smbpass is installed by default, especially if pam modules are expecting it?

Many thanks for the help.

[Steve Langasek (vorlon)]

Thanks for following up, Bolek. I'm marking this bug as a duplicate of bug #216990.

As far as installing libpam-smbpass by default, this option was ruled out early on because NTLM password hashes are weaker than the standard md5 password hashes and should not be used unless a user explicitly opts for Samba filesharing. There are other options being considered here which should (once deployed) give satisfactory results.