gssapi auth, and multihomed multinamed hosts

[Simon Wilkinson]

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 host at float.example.com. However, the server still  
thinks it's called 'fixed.example.com', and so will only accept  
GSSAPI connections for 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.  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.