You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Wolgemuth Greg <wo...@eseri.com> on 2010/11/01 18:36:14 UTC
Failures when using SASL with GSSAPI on C++ broker
Hi everyone
I'm trying to use GSSAPI for authentication between clients and brokers,
and I'm consistently running into errors.
I'm running two Fedora 13 machines, with up-to-date packages. I've
tested the Kerberos system on both boxes, and have no problems kiniting,
or using other GSSAPI authenticated services (postgres, for one
example). I've double-checked the DNS system, and all hostnames and IPs
are matching up correctly. One box runs qpidd, the other runs the
clients I've written. The qpidd has been built from trunk, SVN revision
1029755.
The error I see come up on the client side is:
qpid.messaging.exceptions.ConnectionError: connection-forced: Authentication failed(320)
On the other side, at the qpidd I see the following pop up in the log:
Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug RECV [10.80.0.51:38798] INIT(0-10)
Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug External ssf=0 and auth=
Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug min_ssf: 0, max_ssf: 256, external_ssf: 0
Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 info SASL: Mechanism list: GSSAPI
Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug SASL: Starting authentication with mechanism: GSSAPI
Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 warning Failed to retrieve sasl username
Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 info SASL: Authentication failed (no username available):SASL(-6): can't request info until later in exchange: Information that was requested is not yet available.
Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug Exception constructed: Authentication failed
Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 warning Failed to retrieve sasl username
Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug DISCONNECTED [10.80.0.51:38798]
I see the same problem when I try to use `qpid-python-test` instead of my own clients.
My client is using a slightly older version of trunk (about two weeks old), but I've got a hunch this is a problem on the daemon side.
When I examine the list of keytabs left on the client, I can see that it has established communication with the daemon.
Examining the logs on my KDC shows everything looks normal, as well.
The frustrating part of this is that everything was working last week, and nothing changed in my environment in the interim in the meantime.
Thanks,
Greg
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Failures when using SASL with GSSAPI on C++ broker
Posted by Wolgemuth Greg <wo...@eseri.com>.
Having sent a message to the mailing list and wasted the time of others,
I tracked the problem to the /etc/hosts file of the node hosting qpidd,
which listed "127.0.0.1 localhost.localdomain localhost" ahead of the
listing for its proper FQDN. Using `hostname -f` still listed the FQDN
which threw me off the scent. The problem must have come up
when /etc/hosts got regenerated after a reboot.
Changing /etc/hosts so that 127.0.0.1 only refers to the FQDN restored
GSSAPI functionality.
On Mon, 2010-11-01 at 16:59 -0400, Ken Giusti wrote:
> Hi Greg,
>
> I've tried to repro the problem you are seeing on my local machine using SVN revision 1029793... no avail.
>
> For my client, I am using qpid-perftest on the same physical system as I am running qpidd - can you try that and see if it works? E.g:
>
> qpid/cpp/src/tests/qpid-perftest -b $FQDN --mechanism GSSAPI --username $USERNAME --tx 1 --count 1
>
> fyi, I'm running a simple broker setup - a single broker directly from my repo:
>
> ./qpidd --auth yes --realm $REALM
>
> let me know what you find,
>
> -K
>
> ----- "Wolgemuth Greg" <wo...@eseri.com> wrote:
>
> > Hi everyone
> >
> > I'm trying to use GSSAPI for authentication between clients and
> > brokers,
> > and I'm consistently running into errors.
> >
> > I'm running two Fedora 13 machines, with up-to-date packages. I've
> > tested the Kerberos system on both boxes, and have no problems
> > kiniting,
> > or using other GSSAPI authenticated services (postgres, for one
> > example). I've double-checked the DNS system, and all hostnames and
> > IPs
> > are matching up correctly. One box runs qpidd, the other runs the
> > clients I've written. The qpidd has been built from trunk, SVN
> > revision
> > 1029755.
> >
> > The error I see come up on the client side is:
> >
> > qpid.messaging.exceptions.ConnectionError: connection-forced:
> > Authentication failed(320)
> >
> > On the other side, at the qpidd I see the following pop up in the
> > log:
> >
> > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug RECV
> > [10.80.0.51:38798] INIT(0-10)
> > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug External
> > ssf=0 and auth=
> > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug min_ssf:
> > 0, max_ssf: 256, external_ssf: 0
> > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 info SASL:
> > Mechanism list: GSSAPI
> > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug SASL:
> > Starting authentication with mechanism: GSSAPI
> > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 warning Failed
> > to retrieve sasl username
> > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 info SASL:
> > Authentication failed (no username available):SASL(-6): can't request
> > info until later in exchange: Information that was requested is not
> > yet available.
> > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug Exception
> > constructed: Authentication failed
> > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 warning Failed
> > to retrieve sasl username
> > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug
> > DISCONNECTED [10.80.0.51:38798]
> >
> > I see the same problem when I try to use `qpid-python-test` instead of
> > my own clients.
> >
> > My client is using a slightly older version of trunk (about two weeks
> > old), but I've got a hunch this is a problem on the daemon side.
> > When I examine the list of keytabs left on the client, I can see that
> > it has established communication with the daemon.
> > Examining the logs on my KDC shows everything looks normal, as well.
> >
> > The frustrating part of this is that everything was working last week,
> > and nothing changed in my environment in the interim in the meantime.
> >
> > Thanks,
> >
> > Greg
> >
> >
> >
> > ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:users-subscribe@qpid.apache.org
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Failures when using SASL with GSSAPI on C++ broker
Posted by Ken Giusti <kg...@redhat.com>.
Hi Greg,
I've tried to repro the problem you are seeing on my local machine using SVN revision 1029793... no avail.
For my client, I am using qpid-perftest on the same physical system as I am running qpidd - can you try that and see if it works? E.g:
qpid/cpp/src/tests/qpid-perftest -b $FQDN --mechanism GSSAPI --username $USERNAME --tx 1 --count 1
fyi, I'm running a simple broker setup - a single broker directly from my repo:
./qpidd --auth yes --realm $REALM
let me know what you find,
-K
----- "Wolgemuth Greg" <wo...@eseri.com> wrote:
> Hi everyone
>
> I'm trying to use GSSAPI for authentication between clients and
> brokers,
> and I'm consistently running into errors.
>
> I'm running two Fedora 13 machines, with up-to-date packages. I've
> tested the Kerberos system on both boxes, and have no problems
> kiniting,
> or using other GSSAPI authenticated services (postgres, for one
> example). I've double-checked the DNS system, and all hostnames and
> IPs
> are matching up correctly. One box runs qpidd, the other runs the
> clients I've written. The qpidd has been built from trunk, SVN
> revision
> 1029755.
>
> The error I see come up on the client side is:
>
> qpid.messaging.exceptions.ConnectionError: connection-forced:
> Authentication failed(320)
>
> On the other side, at the qpidd I see the following pop up in the
> log:
>
> Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug RECV
> [10.80.0.51:38798] INIT(0-10)
> Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug External
> ssf=0 and auth=
> Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug min_ssf:
> 0, max_ssf: 256, external_ssf: 0
> Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 info SASL:
> Mechanism list: GSSAPI
> Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug SASL:
> Starting authentication with mechanism: GSSAPI
> Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 warning Failed
> to retrieve sasl username
> Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 info SASL:
> Authentication failed (no username available):SASL(-6): can't request
> info until later in exchange: Information that was requested is not
> yet available.
> Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug Exception
> constructed: Authentication failed
> Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 warning Failed
> to retrieve sasl username
> Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug
> DISCONNECTED [10.80.0.51:38798]
>
> I see the same problem when I try to use `qpid-python-test` instead of
> my own clients.
>
> My client is using a slightly older version of trunk (about two weeks
> old), but I've got a hunch this is a problem on the daemon side.
> When I examine the list of keytabs left on the client, I can see that
> it has established communication with the daemon.
> Examining the logs on my KDC shows everything looks normal, as well.
>
> The frustrating part of this is that everything was working last week,
> and nothing changed in my environment in the interim in the meantime.
>
> Thanks,
>
> Greg
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org