0

It is taking several attempts for users to SSH to several 64-bit Ubuntu machines which are using sssd to authenticate.

The following will happen from 0-6 times in a row before the user is allowed to log in:

ssh [email protected]
[email protected]'s password:
Connection closed by 10.13.63.101

It takes several seconds for the Connection closed by 10.13.63.101 error to occur.

Here is a sample from /var/log/auth.log which shows a failure followed by a success:

sshd[7098]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x  user=User
sshd[7098]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=User
sshd[7098]: pam_sss(sshd:account): Access denied for user User: 4 (System error)
sshd[7098]: Failed password for bob from x.x.x.x port 54817 ssh2
sshd[7098]: fatal: Access denied for user bob by PAM account configuration [preauth]
sshd[7106]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x  user=bob
sshd[7106]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=bob
sshd[7106]: Accepted password for bob from x.x.x.x port 54826 ssh2
sshd[7106]: pam_unix(sshd:session): session opened for user User by (uid=0)
systemd-logind[529]: Removed session 69.
systemd-logind[529]: New session 70 of user bob.

It seems the important line is the third one from the above output:

sshd[7098]: pam_sss(sshd:account): Access denied for user User: 4 (System error)

According to sssd's official wiki (https://fedorahosted.org/sssd/wiki/Troubleshooting):

System Error is an "Unhandled Exception" during authentication. It can either be an SSSD bug or a fatal error during authentication.

The sssd package is up to date:

$ sudo apt-get install sssd
sssd is already the newest version.

So far this is only affecting a very small sample of our systems (~4 of dozens).

Update:

It appears the sssd logs are either empty or months old.

bob@system:/var/log/sssd$ ls -l
total 16
-rw------- 1 root root   0 Jan 26  2015 ldap_child.log
-rw------- 1 root root   0 Jan 26  2015 sssd_LDAP.log
-rw------- 1 root root   0 Aug  5 06:49 sssd.log
-rw------- 1 root root 268 Aug  4 16:24 sssd.log.1
-rw------- 1 root root 158 Jun 15 11:47 sssd.log.2.gz
-rw------- 1 root root 139 May 25 13:17 sssd.log.3.gz
-rw------- 1 root root 139 May 11 11:08 sssd.log.4.gz
-rw------- 1 root root   0 Jan 26  2015 sssd_nss.log
-rw------- 1 root root   0 Jan 26  2015 sssd_pam.log
3
  • 1
    hunting for more verbose logs from SSSD should give you more clue what is going on there.
    – Jakuje
    Oct 1, 2015 at 15:42
  • @Jakuje It appears those logs are either empty or old.
    – D34DM347
    Oct 1, 2015 at 15:53
  • 1
    You need to explicitly add debug_level=<N> to the domain section, SSSD doesn't log anything by default. That should also be documented in the troubleshooting page -- if not, the page needs fixing.
    – jhrozek
    Oct 2, 2015 at 7:14

0

You must log in to answer this question.

Browse other questions tagged .