kerberos authentication failing through load balancer

[David Konerding]

Hi,

We are doing ssh load balancing to a cluster through a load balancer that
forwards port 22.
"host" bldtst-corp-lb round-robin distributes sessions to backend hosts like
"bldtst-corp-1", etc.

When we try to use Kerberos authentication for passwordless ssh, it works
fine if we ssh straight to a host,
but if we go through the load balancer we have a problem- ssh reports
"Unknown code- miscellaneous faillure".

I traced this deep into the code.  The problem is that the server, during
ssh_gssapi_accept_ctx, calls into GSSAPI,
which in Kerberos compares the principles.  The compare that fails and
returns an error code back to ssh
appears to be "bldtst-corp-lb" vs. bldtst-corp-1.  If I force
krb5_princ_compare to return true instead
of false, the server accepts the client's creds and the user can log in with
no password.
I imagine this check is on purpose for the server to ensure that it has a
valid service key for the hostname
being contacted.

We have installed keys for the server, as well as the hostname of the load
balancer, into the target node.

Here is the traceback into Kerberos which is where the auth fails:
#0  krb5_principal_compare (context=0x582e40, princ1=0x583f40,
princ2=0x5845e0) at princ_comp.c:102
#1  0x00002b03996bbead in krb5_rd_req_decoded_opt (context=0x582e40,
auth_context=0x7fff11e6db78, req=0x584690, server=0x583f40, keytab=0x582f00,
ap_req_options=0x0, ticket=0x7fff11e6db70,
    check_valid_flag=1) at rd_req_dec.c:95
#2  0x00002b03996bc5f9 in krb5_rd_req_decoded (context=0x582e40,
auth_context=0x7fff11e6db78, req=0x584690, server=0x583f40, keytab=0x582f00,
ap_req_options=0x0, ticket=0x7fff11e6db70)
    at rd_req_dec.c:343
#3  0x00002b03996bbd63 in krb5_rd_req (context=0x582e40,
auth_context=0x7fff11e6db78, inbuf=0x7fff11e6dbf0, server=0x583f40,
keytab=0x582f00, ap_req_options=0x0, ticket=0x7fff11e6db70)
    at rd_req.c:101
#4  0x00002b039954032f in krb5_gss_accept_sec_context
(minor_status=0x582274, context_handle=0x582278,
verifier_cred_handle=0x583f90, input_token=0x7fff11e6ddb0,
input_chan_bindings=0x0,
    src_name=0x582298, mech_type=0x7fff11e6dd60,
output_token=0x7fff11e6ddc0, ret_flags=0x7fff11e6dda8, time_rec=0x0,
delegated_cred_handle=0x5822a0) at accept_sec_context.c:405
#5  0x00002b039954ceeb in gss_accept_sec_context (minor_status=0x582274,
context_handle=0x582278, verifier_cred_handle=0x583f90,
input_token=0x7fff11e6ddb0, input_chan_bindings=0x0,
    src_name=0x582298, mech_type=0x7fff11e6dd60,
output_token=0x7fff11e6ddc0, ret_flags=0x7fff11e6dda8, time_rec=0x0,
delegated_cred_handle=0x5822a0) at krb5_gss_glue.c:45
#6  0x00000000004257d4 in ssh_gssapi_accept_ctx (ctx=0x582270,
recv_tok=0x7fff11e6ddb0, send_tok=0x7fff11e6ddc0, flags=0x7fff11e6dda8) at
gss-serv.c:155
#7  0x0000000000425089 in input_gssapi_token (type=61, plen=7,
ctxt=0x57dfa0) at auth2-gss.c:151
#8  0x0000000000441726 in dispatch_run (mode=0, done=0x57dfa0,
ctxt=0x57dfa0) at dispatch.c:99
#9  0x0000000000414c17 in do_authentication2 (authctxt=0x57dfa0) at
auth2.c:169
#10 0x000000000040a41a in main (ac=5, av=0x572030) at sshd.c:1860