On Tue, Sep 18, 2012 at 07:37:30AM -0700, Caio James wrote:
Greetings,
I'm running a file transfer server inside of my business with some decent traffic
(but not what I would call heavy traffic).
Users use SFTP to transfer files. A couple of times per day, one or two of my users (not
all of them) experience issues logging in. These users are local users, not LDAP.
/var/log/secure shows the following:
> Sep 18 08:17:04 radvma29 sshd[27378]: pam_unix(sshd:session): session opened for
user wwbi by (uid=0)
> Sep 18 08:27:04 radvma29 sshd[27378]: pam_sss(sshd:session): Request to sssd failed.
Timer expired
I think there's two issues really. I suspect one of them would be
PAM configuration.
Can you check which file is included from /etc/pam.d/sshd (it should be
password-auth) and then paste how the "session" stack looks like in that
file? I would expect that local users would not reach the pam_sss module at
all.
I suspect the second issue (that you're getting the "Timer expired" error)
would be a bug in the sssd_pam responder process. However, I don't have
enough information right now to debug the problem completely.
Can you put "debug_level" = 6 into the [pam] and [domain/default] sections,
restart the SSSD and paste the relevant contents (sanitized if needed)
of /var/log/sssd/sssd_default.log and/or /var/log/sssd/sssd_pam.log ?
Can you also check the number of files that the sssd_pam process has when
it misbehaves?
# lsof -p $(pidof sssd_pam) | wc -l
# lsof -p $(pidof sssd_pam) | grep pipes | wc -l
The user's connection is subsequently dropped, and they're not able to login
until sssd is restarted. The sssd log doesn't seem to show any anomaly.
I've got sssd scheduled to restart twice per day with cron, but the traffic is
increasing and users are now experiencing this more frequently.
I'm running Oracle Linux 6.3.
> [root@radvma29 ~]# sssd --version
> 1.8.0
My sssd.conf is below. Note that we do connect to an LDAP server insecurely. We're
working with our IT team to fix this but it's a few months away:
I would urge you to fix this ASAP. Anyone can sniff your passwords in
cleartext now. This is very dangerous.
> [sssd]
> config_file_version = 2
> services = nss, pam
> debug_level = 5
> domains = default
>
> [nss]
>
> [pam]
> cache_credentials = true
>
> [domain/default]
> ldap_auth_disable_tls_never_use_in_production = true
> access_provider = simple
> auth_provider = ldap
> chpass_provider = ldap
> cache_credentials = True
> krb5_realm =
EXAMPLE.COM
> ldap_search_base = dc=mybusiness,dc=com
> id_provider = ldap
> ldap_uri =
ldap://od.mybusiness.com/
> krb5_kdcip =
kerberos.example.com
^^ You can migrate to using krb5_server instead. It's basically just a new
name for the same option. krb5_kdcip might be obsoleted at some point in
the future.
> ldap_tls_cacertdir = /etc/openldap/cacerts
Thank you for any direction that you can point me.
Caio