At every login or sudo prompt, the server always rejects the password when it is first supplied, but accepts it the second time. I found this thread which describes what seems to be the same problem, but playing around with my /etc/pam.d/system-auth file along the lines of the solution described there didn't work for me. Changing the first instance of 'try_first_pass' to 'use_first_pass', for example, made login authentication fail continuously, as did removing 'nullok'. Does anyone know what needs to be changed to make the system accept correct passwords the first time around?


# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so

Edit: In response to a comment, here's /etc/pam.d/login:

auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth       include      system-auth
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
session    optional     pam_console.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open
session    required     pam_namespace.so
session    optional     pam_keyinit.so force revoke
session    include      system-auth
-session   optional     pam_ck_connector.so

Let me add, all I know about authorization is what I've been able to google in the last hour or so--I'm tackling this problem out of desperation because our IT guy hasn't. So please pitch your answers accordingly. I have a reasonable general familiarity with Linux.

Edit: Responding to another comment, here is what shows up in /var/log/secure during a typical login attempt (where the password was entered correctly both times). Info like server name and IP has been changed.

Oct 28 07:37:41 myserver sshd[944]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=asus-laptop-abc.def.ghi.edu  user=matt
Oct 28 07:37:41 myserver sshd[944]: pam_ldap: ldap_starttls_s: Operations error
Oct 28 07:37:43 myserver sshd[944]: Failed password for matt from 123.456.78.90 port 12345 ssh2
Oct 28 07:37:47 myserver sshd[944]: pam_sss(sshd:account): Access denied for user matt: 10 (User not known to the underlying authentication module)
Oct 28 07:37:47 myserver sshd[944]: Accepted password for matt from 123.456.78.90 port 12345 ssh2
Oct 28 07:37:47 myserver sshd[944]: pam_unix(sshd:session): session opened for user matt by (uid=0)

Interestingly, the above is different from what happens if I enter a genuinely incorrect password the first time, in that case there is this additional line after the first pam_ldap call:

Oct 28 08:13:13 myserver sshd[1054]: pam_ldap: error trying to bind as user "uid=matt,ou=People,dc=abc,dc=ghi,dc=edu" (Invalid credentials)

So the system knows the credentials are right in the former case, but fails the login anyway?! And here is what happens when I call use sudo, which also forces a double login (in this case to use nano to read /var/log/secure):

Oct 28 08:13:27 myserver  sudo: pam_unix(sudo:auth): authentication failure; logname=matt uid=1000 euid=0 tty=/dev/pts/2 ruser=matt rhost=  user=matt
Oct 28 08:13:32 myserver sudo:     matt : TTY=pts/2 ; PWD=/home_dir/home/matt ; USER=root ; COMMAND=/bin/nano /var/log/secure

Edit: This problem doesn't exist when I login as root! It accepts the password on the first try, /var/log/secure looks like this, which I presume is normal:

Oct 29 14:25:58 myserver sshd[7074]: Accepted password for root from 123.456.78.90 port 12345 ssh2
Oct 29 14:25:58 myserver sshd[7074]: pam_unix(sshd:session): session opened for user root by (uid=0)
  • the pam_system, isn't it included in lets say your /etc/pam.d/login? What does it look like? Did you try to remove "try_first_pass" after pam_unix - as at this point there is no password in the pam stack!
    – cornelinux
    Oct 27, 2014 at 16:05
  • It is very possible that your server has been compromised. Oct 27, 2014 at 16:20
  • 2
    Eh - ok well that's confusing. PAM and nsswitch should be set to one of either "ldap" or "sss", not a bit of both. Can you restore the pam.d links to their previous state (ie before your second-last post)? Can you see if /etc/sssd/sssd.conf looks like it has been configured with meaningful settings? Basically you need to work out if your host is using sssd or pam_ldap. You could also try (while logged on in a separate terminal as root) running "service sssd stop" and see if logons still function. It's hard to offer suggestions with the system half-configured.
    – Andy
    Oct 29, 2014 at 1:23
  • 1
    @Andy The sssd.conf file has clearly been manually configured, I put it here. It seems like the authorization specs are consistently ldap as opposed to sss throughout; I changed pam_sss to pam_ldap in password-auth to no effect. Stopping sssd also had no effect. Interestingly, this double-authentication doesn't happen if I log in as root, I've found, see my edit. I still want to solve the problem for user accounts though. Sorry it's such a mess, I am trying to clean up as I learn how. Oct 29, 2014 at 18:37
  • 1
    I know when using the Radius PAM module the first time a user tries to log in it fails, as the user needs to exist locally on the host as well (albeit with no password). Could something similar be happening, but the users aren't being stored? My PAM knowledge is limited, but a colleague has been looking at PAM/Radius recently and I remember reading about the local user accounts!
    – shearn89
    Feb 4, 2015 at 11:59

1 Answer 1


I don't have enough rep to comment it seems, so this is a bit of a shot in the dark attempt at an answer.

pam_ldap: ldap_starttls_s: Operations error

I have to wonder if this part of your log is indicating the culprit. My suspicion is that your ldap config is mishandling tls in some way that causes the connection to fail.

Notice the responses from each module:

pam_ldap: ldap_starttls_s: Operations error
pam_sss(sshd:account): Access denied for user matt: 10 (User not known to the underlying authentication module)
pam_unix(sshd:session): session opened for user matt by (uid=0)

So what we have here is ldap saying it failed due to error, sss saying it doesn't know who you are, and local auth saying successful.

Directions to consider:

  1. Are there any errors in the ldap server logs?
  2. If possible, can you disable TLS and see if that works?
  3. Does ldapsearch work?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .