Description of problem: Qpid python client fails GSSAPI authentication because it hangs with message: qc_client.py --conn-auth-mechanism GSSAPI -p 55537 --user MizoSVdCxpRw94eNaT7AOSkyjtjJNaBR3v0u --broker mrg-qe-02.lab.eng.brq.redhat.com Exception in thread Thread-1: Traceback (most recent call last): File "/usr/lib64/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib64/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib/python2.4/site-packages/qpid/connection.py", line 179, in run self.delegate.received(op) File "/usr/lib/python2.4/site-packages/qpid/delegates.py", line 52, in received getattr(self, op.NAME)(ch, op) File "/usr/lib/python2.4/site-packages/qpid/delegates.py", line 213, in connection_start raise Closed("SASL error: %s" % self.sasl.getError()) Closed: SASL error: Error in sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Failure: no serverFQDN Version-Release number of selected component (if applicable): [root@mrg-qe-02 qpid_ptest_authentication_krb5]# rpm -qa | grep -E '(sasl|qpid|qmf)' | sort -u cyrus-sasl-2.1.22-5.el5_4.3 cyrus-sasl-devel-2.1.22-5.el5_4.3 cyrus-sasl-gssapi-2.1.22-5.el5_4.3 cyrus-sasl-lib-2.1.22-5.el5_4.3 cyrus-sasl-plain-2.1.22-5.el5_4.3 python-qmf-0.7.930108-1.el5 python-qpid-0.7.930108-1.el5 python-saslwrapper-0.1.897961-3.el5 qmf-0.7.929717-1.el5 qmf-devel-0.7.929717-1.el5 qpid-cpp-client-0.7.929717-1.el5 qpid-cpp-client-devel-0.7.929717-1.el5 qpid-cpp-client-devel-docs-0.7.929717-1.el5 qpid-cpp-client-ssl-0.7.929717-1.el5 qpid-cpp-mrg-debuginfo-0.7.929717-1.el5 qpid-cpp-server-0.7.929717-1.el5 qpid-cpp-server-cluster-0.7.929717-1.el5 qpid-cpp-server-devel-0.7.929717-1.el5 qpid-cpp-server-ssl-0.7.929717-1.el5 qpid-cpp-server-store-0.7.929717-1.el5 qpid-cpp-server-xml-0.7.929717-1.el5 qpid-java-client-0.7.918215-1.el5 qpid-java-common-0.7.918215-1.el5 qpid-tools-0.7.930108-1.el5 ruby-qpid-0.7.904654-1.el5 ruby-saslwrapper-0.1.897961-3.el5 saslwrapper-0.1.897961-3.el5 saslwrapper-devel-0.1.897961-3.el5 How reproducible: 100% Steps to Reproduce: 1. set-up kerberos environment & kinit 2. start qpidd in authentication mode 3. run attached testing client qc_client.rb qc_client.py --conn-auth-mechanism GSSAPI -p <port> \ --user <exiting-user-id> --broker <broker-host> Actual results: Client GSSAPI authentication fails/hangs. Expected results: Client GSSAPI authentication should succeed. Additional info: qc_client.py --conn-auth-mechanism GSSAPI -p 55537 --user MizoSVdCxpRw94eNaT7AOSkyjtjJNaBR3v0u --broker mrg-qe-02.lab.eng.brq.redhat.com Exception in thread Thread-1: Traceback (most recent call last): File "/usr/lib64/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib64/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib/python2.4/site-packages/qpid/connection.py", line 179, in run self.delegate.received(op) File "/usr/lib/python2.4/site-packages/qpid/delegates.py", line 52, in received getattr(self, op.NAME)(ch, op) File "/usr/lib/python2.4/site-packages/qpid/delegates.py", line 213, in connection_start raise Closed("SASL error: %s" % self.sasl.getError()) Closed: SASL error: Error in sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Failure: no serverFQDN broker log: 2010-04-13 04:11:47 debug RECV [10.34.33.55:36410] INIT(0-10) 2010-04-13 04:11:47 debug External ssf=0 and auth= 2010-04-13 04:11:47 debug min_ssf: 0, max_ssf: 256, external_ssf: 0 2010-04-13 04:11:47 info SASL: Mechanism list: LOGIN PLAIN ANONYMOUS GSSAPI 2010-04-13 04:11:55 debug periodic update management snapshot: packages: 2 objects: 13 new objects: 0 2010-04-13 04:12:05 debug periodic update management snapshot: packages: 2 objects: 13 new objects: 0 <client killed, because of hang, no message in qpidd log>
Created attachment 406193 [details] The authentication testing client All test above ran on RHEL 5.5 i386/x86_64 as this is currently the only OS which supports python client GSSAPI authentication.
Correction of comment #0 (Description): Steps to Reproduce: 1. set-up kerberos environment & kinit 2. start qpidd in authentication mode 3. run attached testing client qc_client.py <---
This behavior is still present on (beta1) packages: saslwrapper-0.1.934605-1.el5 python-saslwrapper-0.1.934605-1.el5 python-qpid-0.7.934605-1.el5 qpid-cpp-server-0.7.935473-1.el5 The current client does this for authentication: # client to broker connect method - doing the connection # ------------------------------------------------------------------------- def connect(self): try: self.socket = qpid.util.connect(self.options.broker_host, self.options.broker_port); self.connection = Connection( sock = self.socket, sasl_service = self.options.conn_auth_service, sasl_min_ssf = self.options.conn_auth_min_ssf, sasl_max_ssf = self.options.conn_auth_max_ssf, heartbeat = self.options.conn_heartbeat, locale = self.options.conn_locale ); # optional authentication assignments if(self.options.auth_user != None): self.connection.username = self.options.auth_user; if(self.options.auth_pass != None): self.connection.password = self.options.auth_pass; if(self.options.conn_auth_mechanism != None): self.connection.mechanism = self.options.conn_auth_mechanism; self.connection.start(); self.session = self.connection.session(str(uuid4())); Rafael, could you possibly review whether this list created socket conn.user = ... conn.mechanism = 'GSSAPI' conn.start() is enough to SASL GSSAPI authenticate with broker. I believe the issue is that FQDN of machine where kerberos daemon is running is missing. The questions: - do I need to set that? I believe it might default to current machine, reasonable? - If I need to set that, tell me how please. There is no documentation about that at the moment, that why I ask.
I think you do need to set that. Try using the host keyword arg for the Connection constructor. Also, looking at the code I don't think the service, min_ssf, and max_ssf are prefixed with sasl_ for the old client. Apologies for being a bit vague here, I didn't add sasl to the old client, so I'm not quite as familiar with how its wired up as I am with the new API.
For the old client you need to do something like the following: socket = connect(host, port) connection = Connection (sock=socket, host=host, service="qpidd") connection.start() session = connection.session(str(uuid4())) i.e. you need to specify fqdn in the host keyword arg and qpidd as the value to the service key word arg to connection constructor. Using that approach (and after a kinit) it works for me.
Created attachment 408699 [details] a very simple test case Basically a modified version of declare_queues from the direct example. Ff you pass the fully qualified hostname of the server to this as the first arg it should work for GSSAPI if properly configured (i.e. if e.g. perftest is also passing using GSSAPI).
The issue was in connection.host, which was not set. Closing this bug as CLOSED/NOTABUG plus filling another documentation bug 585853 about incomplete/missing qpid python client kerberos docu.