[30208] in Kerberos
Re: Kerberos through a load balancer
daemon@ATHENA.MIT.EDU (David Konerding)
Thu Aug 7 12:10:08 2008
Message-ID: <4f0f0cb0808070908n230785b2nda56071273e3bdd4@mail.gmail.com>
Date: Thu, 7 Aug 2008 09:08:37 -0700
From: "David Konerding" <dakoner@gmail.com>
To: "Douglas E. Engert" <deengert@anl.gov>
In-Reply-To: <4840669A.6030202@anl.gov>
MIME-Version: 1.0
Content-Disposition: inline
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Previously, I wrote to the Kerberos list with a problem:
>>
>> We also have a BigIP load balancer that has a name; when people ssh or web
>> access that name, they get round-robin distributed across the cluster.
>> The LB supports Layer 3 and Layer 5 transparent proxying to the back end.
>>
>> We have noticed that if people log into nodes with their real hostname,
>> or web access a url using the real hostname of the server, everything
>> works as expected.
>> However, attempting to ssh into the load balancer address typically gives:
>>
>> debug1: Authentications that can continue:
>> publickey,gssapi-with-mic,keyboard-interactive
>> debug1: Next authentication method: gssapi-with-mic
>> debug1: Delegating credentials
>> debug1: Miscellaneous failure
>> Unknown code
>>
>> debug1: Trying to start again
>>
>
Douglas Engert added some comments:
>
> What version of SSH?
> What version of Kerberos?
> What OS? Some vendors might have a mod like I described above.
>
I've finally got a chance to get the system under test in a good state to
debug this.
Specifically, I am running on SuSE Linux Enterprise 10 SP1. The Kerberos is
krb5-1.4.3-19.17 (RPM from SLES10SP1). I built my own openssh, 5.1p1, but
the problem is the same with the SLES10SP1 included openssh.
I traced through the code and this time, the tcpdump and debugging code is
more useful.
Specifically, I am ssh'ing into a hostname/IP "bldtst-corp-lb" (the load
balancer's IP and hostname),
which is L2 forwarding my session onto an actual host, bldtst-corp.
The specific problem I see is what when "ssh_gssapi_check_mechanism" calls
into
ssh_gssapi_init_ctx, it first calls
"ssh_gssapi_import_name" with the hostname passed to ssh. So in this case,
it's bldtst-corp-lb. it seems the KDC responds with "PRINCIPAL UNKNOWN"
because
we never created a server key for that hostname.
As far as we can tell this is all normal behavior. What we don't know is if
we can salvage
this- IE, by adding a server key for bldtst-corp-lb and placing it on
bldtst-corp.
Dave
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
