error in auth.log when switch user -- pam_smbpass.so

For developers. I had the same error, also until i installed libpam-smbpass.

I don't use samba/cifs.

For the record, here is the error:
Apr 14 19:42:24 shinehard sudo: PAM unable to dlopen(/lib/security/pam_smbpass.so)
Apr 14 19:42:25 shinehard sudo: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
Apr 14 19:42:25 shinehard sudo: PAM adding faulty module: /lib/security/pam_smbpass.so
Apr 14 19:42:28 shinehard sudo: linshine : TTY=pts/8 ; PWD=/home/linshine ; USER=root ; COMMAND=/bin/su
Apr 14 19:42:28 shinehard sudo: pam_unix(sudo:session): session opened for user root by linshine(uid=0)
Apr 14 19:42:29 shinehard sudo: pam_unix(sudo:session): session closed for user root
Apr 14 19:42:29 shinehard su[9996]: PAM unable to dlopen(/lib/security/pam_smbpass.so)
Apr 14 19:42:29 shinehard su[9996]: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
Apr 14 19:42:29 shinehard su[9996]: PAM adding faulty module: /lib/security/pam_smbpass.so
Apr 14 19:42:29 shinehard su[9996]: Successful su for root by root
Apr 14 19:42:30 shinehard su[9472]: + pts/8 root:root

The error is cosmetic; libpam-smbpass isn't supposed to be installed by default, as I understand it. You can ignore this error.

Steve, didn't you say that the error didn't actually show up for you?

Yes the error it is only cosmetic, everything work well.

I add only another information, if help.

After the installation of the libpam-smbpass package when I unlock the screen saver , as normal user, I receive this error on ath.log file:

kcheckpass[8838]: pam_smbpass(kde:auth): Cannot access samba password database, not running as root.

Regards

The warning/error is only cosmetic, but should be avoided.
It only creates confusion and makes the logs less readable.

While technically 'harmless', even on a not so busy server (eg one that doesn't have libpam-smbpass installed by default) these messages become overwhelming and make it very difficult to see valid messages.

I've installed logcheck on one of my ubuntu servers recently to try to troubleshoot some intermittent problem and it's sending me pages and pages of this error and nothing else. Very annoying :(

Patch to lower the log severity when failing to open modules that aren't listed as required. Unfortunately, didn't make the cut-off for 8.04 so this is going to have to be 8.04.1 material (with corresponding change to the upload target in debian/changelog).

This patch looks dangerous, since it'd mask other legitimate reasons for not dlopening. While the module might not be required, this will make debugging a PITA.

I don't suppose this could be implemented as a module option - "auth optional pam_smbpass.so migrate missingok"?

(Obviously a fake module option that the core PAM core implements; the module itself can't, of course.)

I use logcheck too, and it would be very helpful if the package provided an ignore file that matches these reports, maybe as a stop-gap. I've attached one that works for me.

Just upgrade my Ubuntu server to 8.04 and every since the initial boot, I get the a new entry in /var/log/auth.log every five minutes. Apparently something in the default cron jobs is calling for pam_smbpass.so. My /var/log/auth.log file is nothing but the following...

Apr 26 06:17:01 localhost CRON[8473]: PAM unable to dlopen(/lib/security/pam_smbpass.so)
Apr 26 06:17:01 localhost CRON[8473]: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
Apr 26 06:17:01 localhost CRON[8473]: PAM adding faulty module: /lib/security/pam_smbpass.so
Apr 26 06:17:01 localhost CRON[8473]: pam_unix(cron:session): session opened for user root by (uid=0)
Apr 26 06:17:01 localhost CRON[8473]: pam_unix(cron:session): session closed for user root
Apr 26 06:25:01 localhost CRON[8505]: PAM unable to dlopen(/lib/security/pam_smbpass.so)
Apr 26 06:25:01 localhost CRON[8505]: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
Apr 26 06:25:01 localhost CRON[8505]: PAM adding faulty module: /lib/security/pam_smbpass.so
Apr 26 06:25:01 localhost CRON[8505]: pam_unix(cron:session): session opened for user root by (uid=0)
Apr 26 06:25:01 localhost CRON[8505]: pam_unix(cron:session): session closed for user root

I do not consider this a cosmetic bug. I can not longer mount shares on my NAS unit that mounted fine with the beta. I saved the fstab Fri before spending the weekend trying to get 8.04 installed properly.

Is this something that crept in between beta and GA?

here are the relevant lines in fstab

readyNAS1:/backup /mnt/backup nfs defaults 0 0
readyNAS1:/media /mnt/media nfs defaults 0 0
readyNAS1:/tbird_profile /mnt/email nfs defaults 0 0
readyNAS1:/VirtualMachines /mnt/vm nfs defaults 0 0

in the above, those mount points are defined to ReadyNAS as NFS mounts.I am actually able to access them through SAMBA, expanding the network places.

is there any way of turning this off, the error ?

On Sun, Apr 27, 2008 at 10:33:57PM -0000, waltc wrote:
> I do not consider this a cosmetic bug. I can not longer mount shares on
> my NAS unit that mounted fine with the beta. I saved the fstab Fri
> before spending the weekend trying to get 8.04 installed properly.

Mounting shares from a NAS unit is unrelated to this bug. Please file a
separate bug report for the problem you're experiencing.

Steve,
   I realize the manifestation of this bug is not mounting NAS shares. The PAM errors in the system logs I have are identical to those in this bug and the dup of this bug. Therefor I believe it is the same bug albeit a different action that caused the PAM Auth error. I did not send snippets of the system log as it would have been totally redundant with the exception of the 'action' being mount not su.

  It is the identical PAM error. It worked fine on Friday with the beta version of 8.04 prior to my clean install of the GA version. I merely saved off the /etc/fstab and pasted the mount points into the new fstab.

If you really would still like me to file a new bug, OK, but I am convinced the resolution to one will be the resolution to the other.

Thanks,

Walt

 -------------- Original message ----------------------
From: Steve Langasek <email address hidden>
> On Sun, Apr 27, 2008 at 10:33:57PM -0000, waltc wrote:
> > I do not consider this a cosmetic bug. I can not longer mount shares on
> > my NAS unit that mounted fine with the beta. I saved the fstab Fri
> > before spending the weekend trying to get 8.04 installed properly.
>
> Mounting shares from a NAS unit is unrelated to this bug. Please file a
> separate bug report for the problem you're experiencing.
>
> --
> error in auth.log when switch user -- pam_smbpass.so
> https://bugs.launchpad.net/bugs/216990
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Source Package "pam" in Ubuntu: In Progress
>
> Bug description:
> I am working on a kubuntu hardy (8.04) beta installed from scratch.
> Everything work well but when I switch user (su) I see this
> error in /var/log/auth.log file:
>
> : PAM unable to dlopen(/lib/security/pam_smbpass.so)
> : PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file:
> No such file or directory]
> : PAM adding faulty module: /lib/security/pam_smbpass.so
>
> The user switch is successfully done .
>
> The file pam_smbpass.so is not present on my systema and i have solved the
> problem installing the package: libpam-smbpass.
>
> Maybe a missed package ?
>
> Best Regards

I run a simple server, hosting and is this really needed ... i can't stand veiwing the log on auth.log
I want the error to go away. I don't believe i need SAMBA.

Apr 28 07:45:01 free CRON[24092]: PAM unable to dlopen(/lib/security/pam_smbpass.so)
Apr 28 07:45:01 free CRON[24092]: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
Apr 28 07:45:01 free CRON[24092]: PAM adding faulty module: /lib/security/pam_smbpass.so
Apr 28 07:45:01 free CRON[24092]: pam_unix(cron:session): session opened for user Dark by (uid=0)
Apr 28 07:45:01 free CRON[24096]: PAM unable to dlopen(/lib/security/pam_smbpass.so)
Apr 28 07:45:01 free CRON[24096]: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
Apr 28 07:45:01 free CRON[24096]: PAM adding faulty module: /lib/security/pam_smbpass.so
Apr 28 07:45:01 free CRON[24096]: pam_unix(cron:session): session opened for user Dark by (uid=0)
Apr 28 07:45:01 free CRON[24092]: pam_unix(cron:session): session closed for user Dark
Apr 28 07:45:01 free CRON[24096]: pam_unix(cron:session): session closed for user Dark
Apr 28 07:50:01 free CRON[24105]: PAM unable to dlopen(/lib/security/pam_smbpass.so)
Apr 28 07:50:01 free CRON[24105]: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
Apr 28 07:50:01 free CRON[24105]: PAM adding faulty module: /lib/security/pam_smbpass.so
Apr 28 07:50:01 free CRON[24105]: pam_unix(cron:session): session opened for user Dark by (uid=0)
Apr 28 07:50:01 free CRON[24109]: PAM unable to dlopen(/lib/security/pam_smbpass.so)
Apr 28 07:50:01 free CRON[24109]: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
Apr 28 07:50:01 free CRON[24109]: PAM adding faulty module: /lib/security/pam_smbpass.so
Apr 28 07:50:01 free CRON[24109]: pam_unix(cron:session): session opened for user Dark by (uid=0)
Apr 28 07:50:01 free CRON[24105]: pam_unix(cron:session): session closed for user Dark
Apr 28 07:50:01 free CRON[24109]: pam_unix(cron:session): session closed for user Dark
Apr 28 07:55:01 free CRON[24145]: PAM unable to dlopen(/lib/security/pam_smbpass.so)
Apr 28 07:55:01 free CRON[24145]: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
Apr 28 07:55:01 free CRON[24145]: PAM adding faulty module: /lib/security/pam_smbpass.so
Apr 28 07:55:01 free CRON[24146]: PAM unable to dlopen(/lib/security/pam_smbpass.so)
Apr 28 07:55:01 free CRON[24146]: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
Apr 28 07:55:01 free CRON[24146]: PAM adding faulty module: /lib/security/pam_smbpass.so
Apr 28 07:55:01 free CRON[24145]: pam_unix(cron:session): session opened for user Dark by (uid=0)
Apr 28 07:55:01 free CRON[24146]: pam_unix(cron:session): session opened for user Dark by (uid=0)
Apr 28 07:55:01 free CRON[24145]: pam_unix(cron:session): session closed for user Dark
Apr 28 07:55:01 free CRON[24146]: pam_unix(cron:session): session closed for user Dark

i need help with this

ims, this is easily worked around by removing or commenting out the following line from /etc/pam.d/common-password:

password optional pam_smbpass.so nullok use_authtok use_first_pass

waltc, this is definately unrelated, as this is purely a warning from the PAM stack saying that it cannot load the pam_smbpass.so module which has nothing to do with NAS mounting whatsoever.

back to discussion about this bug...
What needs to occur for this ideally is that debconf would be used to manage common-password instead of having it statically in the libpam-runtime package. This way if you install libpam-smbpass, you'd get the needed entry in the file and if it isn't, it wouldn't be present, thus not causing this warning.

I found that I could no longer VNC into a recently upgraded Gutsy to Hardy. I would receive a password prompt, but continue to get authentication errors.

Installing libpam-smbpass (sudo apt-get install libpam-smbpass) immediately fixed the problem.

You can work around this, by commenting out the pam_smbpass.so related lines in /etc/pam.d/common-auth and /etc/pam.d/common-password.

Thanks, I tested that, and that does work.

However, this will be an issue for those that upgrade from Gutsy to Hardy (as I found out) and suddenly find that they can no longer log into their machine via VNC. Perhaps a patch issuing new /etc/pam.d/common-auth and /etc/pam.d/common-password with the pam_smbpass.so related lines commented out would be a better solution?

On Mon, Apr 28, 2008 at 11:58:20AM -0000, waltc wrote:
> Steve,
> I realize the manifestation of this bug is not mounting NAS shares. The
> PAM errors in the system logs I have are identical to those in this bug
> and the dup of this bug. Therefor I believe it is the same bug albeit a
> different action that caused the PAM Auth error.

It isn't. Everyone is experiencing this PAM error, which has no bearing on
mounting NAS shares. Please file a separate bug.

About this issue... it's very serious and maybe it can hangup your system during a brute force attack over SSH, look my example:

I have installed Ubuntu 8.04, with SSH open to world, but just I have the password.

After turns up my IP addres (public), in my /var/log/auth.log I can see a lot of incoming brute force attack:

...........
Apr 29 15:53:46 srv33 sshd[5945]: Invalid user test from 218.22.9.118
Apr 29 15:53:46 srv33 sshd[5945]: PAM unable to dlopen(/lib/security/pam_smbpass.so)
Apr 29 15:53:48 srv33 sshd[5945]: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
Apr 29 15:53:48 srv33 sshd[5945]: PAM adding faulty module: /lib/security/pam_smbpass.so
Apr 29 15:53:48 srv33 sshd[5945]: pam_unix(sshd:auth): check pass; user unknown
Apr 29 15:53:48 srv33 sshd[5945]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.22.9.118
Apr 29 15:53:48 srv33 sshd[5945]: Failed password for invalid user test from 218.22.9.118 port 16679 ssh2
Apr 29 15:53:52 srv33 sshd[6024]: Invalid user guest from 218.22.9.118
Apr 29 15:53:54 srv33 sshd[6024]: PAM unable to dlopen(/lib/security/pam_smbpass.so)
Apr 29 15:53:54 srv33 sshd[6024]: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
Apr 29 15:53:54 srv33 sshd[6024]: PAM adding faulty module: /lib/security/pam_smbpass.so
Apr 29 15:53:54 srv33 sshd[6024]: pam_unix(sshd:auth): check pass; user unknown
Apr 29 15:53:54 srv33 sshd[6024]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.22.9.118
Apr 29 15:53:55 srv33 sshd[6024]: Failed password for invalid user guest from 218.22.9.118 port 1853 ssh2
Apr 29 15:53:59 srv33 sshd[6053]: Invalid user admin from 218.22.9.118
Apr 29 15:53:59 srv33 sshd[6053]: PAM unable to dlopen(/lib/security/pam_smbpass.so)
Apr 29 15:53:59 srv33 sshd[6053]: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
Apr 29 15:53:59 srv33 sshd[6053]: PAM adding faulty module: /lib/security/pam_smbpass.so
Apr 29 15:53:59 srv33 sshd[6053]: pam_unix(sshd:auth): check pass; user unknown
Apr 29 15:53:59 srv33 sshd[6053]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.22.9.118
Apr 29 15:54:00 srv33 sshd[6053]: Failed password for invalid user admin from 218.22.9.118 port 53665 ssh2
.......

 And during this attacks, my load avarege goes to sky, arround 8.50, even 12.3 of high load... with no daemons, only ssh running! No apache, no mysql, nothing.

... seconds after installing "aptitude libpam-smbpass" my system works nicely, with low load average again, even if "under ssh attack"!

So, to solve this problem, I see to options:

1- Disable pam_smbpass in common-auth and common-password under /etc/pam.d or;
2- Put a dependency of libpam-smbpass in something like ubuntu-standard or even ubuntu-minimal.

 I prefer the first one, I don't use Samba.

Regards,
Thiago

Until common-password and common-auth are controlled by debconf regarding adding in the optional modules that make sense, I'm agreeing with Thiago here, just disable pam_smbpass from the configuration.

Gary,

 There is a lot of people thinking this is a Samba or CUPS BUG! I can see in other messages through bugs...

 This must be solved, in a simple way, because PAM is hanging up a lots of programs that's uses it!

 Now I think that this is a internal PAM BUG, not a simple configuration issue, when "dlopen" can't open a .so file, it [PAM] must manage this situation avoiding causing problems on other stuff on the system. But instead, PAM makes entire system down with high load in some situations.

I agree that this is a problem, however THIS particular report issue is regarding the flood of messages to the log which IS a configuration issue.

The load issue you're experiencing is a seperate, but more serious issue that needs a seperate bug opened for.

I know very little about debconf so do not understand the technical issue alluded to above regarding pam and debconf.

However, I do not think it should be in the default configuration that smb passwords maybe used to login - that is a specific requirement that should not be enabled by default.

I guess that the debconf problem is that when libpam-smbpass is installed it cannot update common-auth?

I suspect this issue is related to something causing one of my servers to hang when serving files through samba. Certainly it is the only logged error, however as the whole machine hangs i may be losing log data. Have installed libpam-smbpass and am waiting to see if the machine hangs again.

I wonder whether part of the problem is in the updating (or the lack of updating) config files during the hardy upgrade.

NoOp,

On Mon, Apr 28, 2008 at 08:33:30PM -0000, NoOp wrote:

> However, this will be an issue for those that upgrade from Gutsy to
> Hardy (as I found out) and suddenly find that they can no longer log
> into their machine via VNC. Perhaps a patch issuing new /etc/pam.d
> /common-auth and /etc/pam.d/common-password with the pam_smbpass.so
> related lines commented out would be a better solution?

If you're unable to log in via VNC, then that's a much more serious error
and one that's not at all explained by these log errors: the absence of
this "optional" module should not cause any authentication failures, and it
was on that basis that the change was made to enable this module.

Please open a separate bug report about this issue and provide a link to it
here. We will need to pin down this VNC problem, which may warrant rolling
back the PAM config changes; the logging issue itself should be fixable with
a small patch, but I currently have no explanation for why you would
experience login failures with VNC that would be fixed by installing
libpam-smbpass.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

On 05/07/2008 01:55 PM, Steve Langasek wrote:
> NoOp,
>
> On Mon, Apr 28, 2008 at 08:33:30PM -0000, NoOp wrote:
>
>> However, this will be an issue for those that upgrade from Gutsy to
>> Hardy (as I found out) and suddenly find that they can no longer log
>> into their machine via VNC. Perhaps a patch issuing new /etc/pam.d
>> /common-auth and /etc/pam.d/common-password with the pam_smbpass.so
>> related lines commented out would be a better solution?
>
> If you're unable to log in via VNC, then that's a much more serious error
> and one that's not at all explained by these log errors: the absence of
> this "optional" module should not cause any authentication failures, and it
> was on that basis that the change was made to enable this module.
>
> Please open a separate bug report about this issue and provide a link to it
> here. We will need to pin down this VNC problem, which may warrant rolling
> back the PAM config changes; the logging issue itself should be fixable with
> a small patch, but I currently have no explanation for why you would
> experience login failures with VNC that would be fixed by installing
> libpam-smbpass.
>

No clue. I just tested and it now seems to be fine.

To test I ensured that libpam-smbpass was not installed on the target
machine (this is the one with the Gutsy to Hardy upgrade), and that the
edited /etc/pam.d/common-auth and /etc/pam.d/common-password
pam_smbpass.so lines were un-commented (put them back). Rebooted the
target machine and now can VNC into it just fine; both from a Gutsy
machine and a fresh install (fully up to date) Hardy machine. Both using
the Terminal Server Client w/xvnc4viewer.

So, I can't seem to reproduce. Perhaps it was a case of VNC gremlins?
I'll wait until I upgrade another machine from Gutsy to Hardy and if I
can reproduce, then I'll file a separate bug.

I was experiencing the same reports (every minute or so) in my desktop machine (connected to a LAN via router) but seems that reports stopped after i configured my firewall (guarddog) to stop logging errors. Indeed upgrade was from Gutsy to Hardy.

CORRECTION: log reports did not stop after disabling logging (and not logging errors as mistakenly mentioned above). They just reduced in frequency (every 30 mins).

Hello there,

I get flooded with security warning mails from logcheck since upgrading my servers to Hardy, caused by this bug.

This is not cosmetic as it makes logcheck useless for me, which is intended to filter the serious log entries for me. So not only cosmetic but a security risk as I will possibly not see real serious log entries even using logcheck if I get a security warning mail every 5 min with dozens of log lines.

any ETA on this being fixed?

I am also seeing these entries on Hardy. I noticed it after trying to resume my session and the system would not respond. The keyboard did work and I was able to login after using Alt+Backspace to restart X.

To fix that, just comment out two lines in two files in /etc/pam.d:

commented line in common-auth:
#auth optional pam_smbpass.so migrate

commented line in common-password:
#password optional pam_smbpass.so nullok use_authtok use_first_pass

 All my 8.04 servers have now this lines commented out. SSH works fine and no more high load average under brute force attacks.

Regards,
Thiago

Did you check your log files? I did that initially and the errors were
still appearing there.

On Thu, May 15, 2008 at 11:43 AM, Thiago Camargo Martins Cordeiro <
<email address hidden>> wrote:

> To fix that, just comment out two lines in two files in /etc/pam.d:
>
> commented line in common-auth:
> #auth optional pam_smbpass.so migrate
>
> commented line in common-password:
> #password optional pam_smbpass.so nullok use_authtok use_first_pass
>
> All my 8.04 servers have now this lines commented out. SSH works fine
> and no more high load average under brute force attacks.
>
> Regards,
> Thiago
>
> --
> error in auth.log when switch user -- pam_smbpass.so
> https://bugs.launchpad.net/bugs/216990
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--

Bolek,
Monmouth Junction, NJ

Yes. The errors are appearing in the log files. Thanks.

On Thu, May 15, 2008 at 3:27 PM, Bolek <email address hidden> wrote:

> Did you check your log files? I did that initially and the errors were
> still appearing there.
>
> On Thu, May 15, 2008 at 11:43 AM, Thiago Camargo Martins Cordeiro <
> <email address hidden>> wrote:
>
> > To fix that, just comment out two lines in two files in /etc/pam.d:
> >
> > commented line in common-auth:
> > #auth optional pam_smbpass.so migrate
> >
> > commented line in common-password:
> > #password optional pam_smbpass.so nullok use_authtok use_first_pass
> >
> > All my 8.04 servers have now this lines commented out. SSH works fine
> > and no more high load average under brute force attacks.
> >
> > Regards,
> > Thiago
> >
> > --
> > error in auth.log when switch user -- pam_smbpass.so
> > https://bugs.launchpad.net/bugs/216990
> > You received this bug notification because you are a direct subscriber
> > of a duplicate bug.
> >
>
>
> --
>
> Bolek,
> Monmouth Junction, NJ
>
>
> ** Attachment added: "unnamed"
> http://launchpadlibrarian.net/14545290/unnamed
>
> --
> error in auth.log when switch user -- pam_smbpass.so
> https://bugs.launchpad.net/bugs/216990
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Alexi Helligar, Information Architect
Mojeaix IT Solutions | for small and medium business
"Plan IT, Own IT, Use IT, Love IT"
416 925 8844 tel | 416 352 1952 fax
www.mojeaix.com

Yeah, for sure! My log files are clean now, look:

My log before comment out:
.....
May 15 17:14:34 macbook-tcmc sshd[9105]: Invalid user teste from 10.1.10.200
May 15 17:14:34 macbook-tcmc sshd[9105]: PAM unable to dlopen(/lib/security/pam_smbpass.so)
May 15 17:14:34 macbook-tcmc sshd[9105]: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
May 15 17:14:34 macbook-tcmc sshd[9105]: PAM adding faulty module: /lib/security/pam_smbpass.so
May 15 17:14:34 macbook-tcmc sshd[9105]: Failed none for invalid user teste from 10.1.10.200 port 58691 ssh2
May 15 17:14:37 macbook-tcmc sshd[9105]: pam_unix(sshd:auth): check pass; user unknown
May 15 17:14:37 macbook-tcmc sshd[9105]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=fileserver.office.worldweb.com.br
May 15 17:14:39 macbook-tcmc sshd[9105]: Failed password for invalid user teste from 10.1.10.200 port 58691 ssh2
....

And after comments done:
.....
May 15 17:16:19 macbook-tcmc sshd[9115]: Invalid user teste from 10.1.10.200
May 15 17:16:19 macbook-tcmc sshd[9115]: Failed none for invalid user teste from 10.1.10.200 port 58692 ssh2
May 15 17:16:20 macbook-tcmc sshd[9115]: pam_unix(sshd:auth): check pass; user unknown
May 15 17:16:20 macbook-tcmc sshd[9115]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=fileserver.office.worldweb.com.br
May 15 17:16:22 macbook-tcmc sshd[9115]: Failed password for invalid user teste from 10.1.10.200 port 58692 ssh2
.....

root@macbook-tcmc:/etc/pam.d# grep pam_smbpass *
common-auth:#auth optional pam_smbpass.so migrate
common-password:#password optional pam_smbpass.so nullok use_authtok use_first_pass

Regards,
Thiago

Attached is an alternate solution for this issue, following Colin's suggestion of a 'missingok' option.

I'm not altogether happy with this as a solution because up until now the module option list has been entirely pass-through by libpam, but the previous fix I proposed is also inadequate because all logging that uses the 'auth' facility, including debug logging, is written to /var/log/auth.log by default, so lowering the log severity of these messages is insufficient to reduce the log spam; and dropping all such log messages for all 'optional' modules would be a significant hindrance to debugging.

So I think we should go ahead with this second patch under the circumstances, and solve this problem correctly for intrepid using module hooks.

This seems like a good option under the circumstances. Have you talked with Thorsten Kukuk on a way that will be supported by upstream?

This bug was fixed in the package pam - 0.99.7.1-5ubuntu7

---------------
pam (0.99.7.1-5ubuntu7) intrepid; urgency=low

  * debian/patches-applied/ubuntu-no-error-if-missingok: add a new, magic
    module option 'missingok' which will suppress logging of errors by
    libpam if the module is not found.
  * debian/local/common-{auth,password}, debian/libpam-runtime.postinst:
    Use the new 'missingok' option by default for pam_smbpass, to
    correct the problem of very loud logging introduced in the previous
    upload when libpam-smbpass is not installed. LP: #216990.

 -- Steve Langasek <email address hidden> Tue, 22 Apr 2008 18:53:37 +0000

On Fri, May 16, 2008 at 01:19:32AM -0000, Gary Greene wrote:
> This seems like a good option under the circumstances. Have you talked
> with Thorsten Kukuk on a way that will be supported by upstream?

The proposed solution is not suitable for inclusion upstream, and the
intended long-term solution will not require any changes to upstream code.

Accepted into -proposed, please test and give feedback here

Nice!

A fresh LTS install with proposed updates enabled, solve this issue on my system.

I do not have libpam-smbpass installed and my logs are now clear with "missingok" option.

Thank you!

I'll test this next week when our internal unstable tree is synced against the Hardy repo.

This -proposed package fixed up all my system. For others with the same problem though note that you will probably need to restart CRON and possibly other services to make the problem go away.

Copied to hardy-updates.

sclo,

You did not explain why you reassigned this bug to a different package and assigned it to yourself. I think you've made some mistake here; this bug is definitely not a bug in libapache2-mod-auth-pam, and is already resolved.

howdy. i am runing 8.04 with _all_ repositoryes enabled but there is no such fix available. it is about 3 months now from the fix being copyed to -updates, but it is not there. i really nedd this bug fixed for good. on Hardy since i do not intend to upgrade my systems to Intrepid. please check and fix this for real!

"Justan",

Do you have the libpam-smbpass package installed?

This bug was filed about spurious log messages that users were seeing when libpam-smbpass is not installed.

Unfortunately, after fixing this with the magic "missingok" option, users who *do* install libpam-smbpass will instead get warning messages about the "missingok" option being unknown to pam_smbpass.so.

This would need to be fixed with an SRU of samba as well, not just pam (which is the package that has been fixed to date).

I need to note that if your /etc/pam.d/common-* config files were modified locally, you will have to fix them manually and wont be prompted to merge your changes with the new version as these files aren't conffiles and the only logic in libpam-runtime.postinst is to upgrade conffiles if their md5sum didn't change.

so here we are, many months later, and the problem is still not solved even though it should be trivial to fix. I recently installed Ubuntu Server and the default install does not include samba which is good but my log files are being flooded with this bogus error msg which is very bad. DoS anyone?

The actual fix is totally trivial, just comment out one line in each of two different files.

What I see above looks like some pretty complicated suggested fixes being proposed to something that would benefit from being kept simple.

Why not split the config file? after all it is a ".d" directory that should be able to support the use separate config files for each app. So put all the samba related config options in a samba specific file and only install that file when samba is installed. Bottom line is that an App Specific config should not be in a "common" shared config file.

Proposed Changes:

Remove:
  From File: /etc/pam.d/common-password
  Line: password optional pam_smbpass.so nullok use_authtok use_first_pass

  From File: /etc/pam.d/common-auth
  Line: auth optional pam_smbpass.so migrate

Add:
  New File: /etc/pam.d/samba-options
  Line: password optional pam_smbpass.so nullok use_authtok use_first_pass
  Line: auth optional pam_smbpass.so migrate

End Of Problem... no code changes or new config flags needed.

codeslinger, this bug has been closed as "fix released" many months ago. Are you using the hardy-updates packages?

Also, juggling configuration files in an update is a no-go area, especially not with something as critical as PAM modules. Changing them during an update automatically is on the very other end on the "trivial" scale.

Dont think this is fixed properly:

I am still having this problem on 9.04 for upgraded and new installation.

On my upgraded amd64 I have libpam-smbpass installed and it is the lastest version.

On my new install 32bit laptop I dont have libpam-smbpass installed and there are no entries for pam_smbpass.so in common-auth (auth optional pam_smbpass.so migrate) and no entries in common-password(password optional pam_smbpass.so nullok use_authtok use_first_pass).

Log Snippet:

May 24 09:10:01 scatha CRON[5026]: pam_unix(cron:session): session opened for user root by (uid=0)
May 24 09:10:01 scatha dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.35" (uid=1000 pid=3902 comm="/usr/lib/indicator-applet/indicator-applet --oaf-a") interface="org.freedesktop.DBus.Properties" member="Get" error name="(unset)" requested_reply=0 destination=":1.50" (uid=0 pid=5026 comm="/USR/SBIN/CRON "))
May 24 09:10:02 scatha CRON[5026]: pam_unix(cron:session): session closed for user root

STILL getting this (or a variant thereof) in 11.04

PAM adding faulty module: pam_smbpass.so
PAM unable to dlopen(pam_smbpass.so): libgpg-error.so.0: failed to map segment from shared object: Cannot allocate memory

Not a variant at all. You have a completely unrelated issue.

> Cannot allocate memory

That doesn't look like an OS bug at all, it looks like your system is out of memory.

While trying to work out why a colleague is having problems logging in, I too noticed this on a natty install:
Dec 7 09:18:26 millhouse sudo: PAM unable to dlopen(pam_smbpass.so): /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory
Dec 7 09:18:26 millhouse sudo: PAM adding faulty module: pam_smbpass.so

/etc/pam.d/common.password contains:
password optional pam_smbpass.so nullok use_authtok use_first_pass missingok

Anyone seeing such issues in releases later than Ubuntu intrepid most likely has a locally-broken PAM config, not an Ubuntu bug. Please see the Ubuntu forums, askubuntu.com, or another support forum for assistance.