Hi Franky, On Thu, Sep 11, 2014 at 01:08:09PM +0200, Franky Van Liedekerke wrote: > On Thu, Sep 11, 2014 at 11:40 AM, Franky Van Liedekerke > <liede...@telenet.be> wrote: > > After doing tcpdump on both servers (no ldap errors anywhere in the > > ldap logs), I see that the ldap server sends out resets and the > > clients connecting to haproxy. This might be related to one another. > > Each client seems to send 2 RST packets at the end of a LDAP TLS > > session (over port 389), does that sound familiar? > > > > Franky > > Ok, after much trial and error, I pinned it down to the following: we > have lots of servers doing ldap lookup for authentication, also when > connecting via ssh. Now on EL5 servers this auth is done via a call to > /usr/libexec/openssh/ssh-ldap-wrapper. > Apparently this binary causes the resets to be shown in the haproxy > error logs. I switched to the sssd version for EL5 servers, but that > version did not include ssh-keys support, so the resets persisted. > Again to the internet for the rescue: the version 1.9.6 for el5 can be > found at > http://copr-be.cloud.fedoraproject.org/results/sgallagh/sssd-1.9-rhel5/epel-5-x86_64 > , and that version does support ssh correctly. Installing it, changing > the ssh config et voila: no more resets. > So the bug is in the ssh-ldap-wrapper, but I understand that doing a > RST at the end is not bad, just not "good" either ... the side-effect > of the new sssd is that much less ldap queries are made (as sudo and > ssh use sssd too then), but I'll leave it up to the management to > decide wether or not to go for that solution.
Thanks for sending the details of your diagnostic. As you say, RST are not necessarily bad. When a client closes first, it has two options : - either send RST - or have the source port unusable for 2 minutes. Most of the time you chose the first option. In your case since you were seeing SD flags, it means the reset came fro mthe server, maybe the client was speaking inappropriately on the connection, causing the server to abort it. If so, it proves that the behaviour was properly chosen, because it allowed you to detect the anomaly in the logs and to fix it, which is quite good. Regards, Willy
