gssapi auth, and multihomed multinamed hosts

[scanell]

   I can attest to issues with a multi homed host.... I had one with a
   kerberos server.  I would have traffic
   come in on one IP but respond back on another IP which broke all
   transactions from client and server,
   so it wouldn't surprise me if the reverse is true and you will
   experience the same problems.
   Steve
   Simon Wilkinson wrote:

On 6 Jun 2007, at 16:55, Michael B Allen wrote:
  

I have a Solaris 10 server with two ip addresses: "fixed.example.com"
and "float.example.com". The latter is an IP address that the server
sometimes assumes as part of its role in a high-availability cluster.

I have compiled my own openssh+gssapi version of sshd, and have got
ssh single-sign-on working fine (both windows secureCRT, a patched
version of Putty, and also the unix openssh clients) . So far so  
good.

It is now time to get gssapi auth to working with the
"float.example.com" address.

Can I expect to just add the keytab for "float.example.com" into / 
etc/
krb5.keytab and expect everything to be OK?
      

I don't have first hand knowledge of this particular scenario but from
what I know about GSSAPI it should work fine. GSSAPI works by name so
provided the key on the KDC associated with the service principal  
matches
the key in the keytab used by sshd then it should work.
    

It's a little more complicated than that. With GSSAPI, both the  
client and the server have to use the same service principal at  
either end of the connection. They must decide upon what to use  
independently, before the connection is established. Typically these  
are based around the service name ('host' in this case), and the  
hostname of the server being contacted. The OpenSSH client picks the  
target service principal based on the hostname typed by the user, the  
server picks its service principal based on the result of gethostname 
(). The MIT GSSAPI libraries currently use DNS to canonicalise these  
names - which is why 'ssh duffus' still works.

There's further confusion that can arise through the use of 'clever'  
DNS configuration, in particular if the host is part of a round-robin  
DNS cluster. From your description, I'm assuming that  
'float.example.com' will only ever point at one IP at a time, and  
that each of those IPs resolve back as 'float.example.com', so the  
round-robin issues won't apply.

So, in your case you will do 'ssh float.example.com', and (providing  
your DNS is correctly setup) the client will attempt to open a GSSAPI  
connection to [1]host at float.example.com. However, the server still
thinks it's called 'fixed.example.com', and so will only accept
GSSAPI connections for [2]host at fixed.example.com. Your GSSAPI connection
will, therefore, fail.

What you need is a way of telling the OpenSSH server to be more
forgiving in it's list of acceptors. There's a patch in their bug
tracking system that will do this.  [3]http://bugzilla.mindrot.org/
attachment.cgi?id=1182 adds a new configuration directive
'GSSAPIStrictAcceptorCheck'. If you set this to 'no', then any
principal in the keytab of your server will be able to act as an
acceptor. If you're using this option, you need to be careful which
principals are in the default keytab, but apart from that, it should
solve your problem.

Cheers,

Simon.

________________________________________________
Kerberos mailing list           [4]Kerberos at mit.edu
[5]https://mailman.mit.edu/mailman/listinfo/kerberos



--
Stephen E. Canell
Sr Engineer, UNIX System Administrator
Institutional Business Systems
Jet Propulsion Laboratory
4800 Oak Grove Drive
Pasadena, Calif. 91109
Office: (818) 354-1731
Cell: (818) 653-8303

References

   1. mailto:host at float.example.com
   2. mailto:host at fixed.example.com
   3. http://bugzilla.mindrot.org/
   4. mailto:Kerberos at mit.edu
   5. https://mailman.mit.edu/mailman/listinfo/kerberos