Hide Forgot
Description of problem: I can't login to my x86_64 machine, not locally and not over ssh. My account is managed by LDAP. I can login to root (in files), and I can login to other machines on the net (same LDAP setup, either up-to-date Aurora Corona or CentOS 4.4). Version-Release number of selected component (if applicable): pam-0.99.7.0-2.fc7 How reproducible: Always Steps to Reproduce: 1. 2. 3. Actual results: Via ssh, in /var/log/secure: Jan 23 17:14:17 quelen sshd[3680]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=laptop13.inf.utfsm.cl user=vonbrand Jan 23 17:14:19 quelen sshd[3680]: Failed password for vonbrand from 200.1.19.201 port 55735 ssh2 Jan 23 17:14:29 quelen last message repeated 2 times Jan 23 17:14:29 quelen sshd[3681]: Connection closed by 200.1.19.201 On tty1: Jan 23 17:16:38 quelen login: pam_unix(login:auth): authentication failure; logn ame=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost= user=vonbrand Jan 23 17:16:40 quelen login: FAILED LOGIN 1 FROM (null) FOR vonbrand, Authentic ation failure I've been known to mistype my password, but not this many times in a row. Expected results: Additional info: It seems the updated pam still let the infamous ssh scanners enter the tomcat account (with !! in /etc/shadow). Need to confirm if they left some backdoor.
BTW, I can "su - vonbrand" just fine, and "finger vonbrand" and "ls ~vonbrand" work too, so it isn't that just that access to the account data is hosed. /etc/nsswitch has: passwd: files ldap shadow: files ldap group: files ldap
> It seems the updated pam still let the infamous ssh scanners enter the tomcat > account (with !! in /etc/shadow). Need to confirm if they left some backdoor. That would be pretty bad, but I cannot reproduce that problem anymore here. Probably they installed some backdoor. You also cannot know for sure whether there is no local exploit with which they got to root account then. So it would be better to reinstall the system from scratch. For the main topic of this bug report - I tried to reproduce and it seems to work fine here. I have some questions - do you use pam_ldap in the pam configuration? And can you change the password in LDAP and try whether the new one works? If the old password isn't too valuable for you could also mail that password to me along with the 'getent shadow vonbrand' and 'getent passwd vonbrand' output so I could do more tests.
Hummm... /etc/pam.d/system-auth{,-ac} don't even mention pam_ldap, in fact, that string doesn't match anything in /etc/pam.d/*. I did set up LDAP authentication with authconfig-tui (authconfig-5.3.13-1.fc7), just double-checked. Seems that one is broken... What should the configuration look like? The examples with nss_ldap-253-4 are wildly out of date...
I have tested the LDAP authentication checkbox with authconfig-tui (although the tui is deprecated) and it seems to work fine here with authconfig-5.3.13-1.fc7. 1. What your /etc/sysconfig/authconfig contains? 2. If it contains USELDAPAUTH=no - are you sure you have checked the 'Use LDAP Authentication' check box and not only the 'Use LDAP' one? 3. If it is checked properly. Can you try to uncheck it and then check it again if it helps? The pam config should look like: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.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_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 password sufficient pam_unix.so md5 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
2. USELDAPAUTH=yes Unchecking "Use LDAP Authentication", OKing, and running it again, this time checking it, fixed both local and ssh login. authconfig-tui is broken. Why is it deprecated? Not every machine has X and stuff, and using plain authconfig is rather confusing. The poor sysadmin needs help here, and this doesn't just fix one configuration file but touches many of them. 3. The pam_ldap line was missing, as I suspected. Thank you very much!
The question is why got the system-auth-ac broken and when. I am afraid that without this information it's hard to fix that problem. I'm also curious how the pam upgrade is related to that problem or not.
The machine had LDAP logins from the beginning, maybe the latest PAM update broke it? It's the closest change (time-wise) that I remember.
Some more questions. Does getent passwd vonbrand and getent shadow vonbrand show something meaningful in the password hash field? And if yes, if you create a new local test user with that password hash, can you log in to this user with your password? Also in the process of fixing the hole with !! accounts did you remove pam and installed another version or just always upgraded (never mind if with rpm --oldpackage)?
Sorry, can't check now (machine is turned off for vacations here). I "fixed" that one by shutting off net access (iptables allowing only local incoming traffic). Only rpm updates.
This is impossible to fix without a reproducer. Perhaps it was some intermittent glitch in authconfig or other thing. Closing as CANTFIX.