Wrong principal in request using virt interface

[petesea@bigfoot.com]

On Mon, 29 Jan 2007, Christopher D. Clausen wrote:

> petesea at bigfoot.com wrote:
>> On Mon, 29 Jan 2007, Christopher D. Clausen wrote:
>>> Can you simply fail-over using the same IP on both interfaces?  (I
>>> believe there is a bonding module in Linux that can do this.)
>>
>> The point of the virt interface is so it can be moved to a different 
>> host. If the virt interface has the same IP as the real interface, then 
>> it couldn't be moved to another host.  In other words, the "fail-over" 
>> is to fail over to a completely separate host, not a separate interface 
>> on the same host.
>
> Uhh, can I ask why you are doing this?  Kerberos already has a 
> master/slave architecture.  There is no need to "cluster" Kerberos 
> servers in the manner you describe.  Just setup multiple slave servers.
>
> I thought you wanted more reliable KDCs by having redundant network 
> interfaces.

Sorry, I guess I wasn't very clear.  The servers aren't KDCs, they are 
CVS/Subversion servers accessed via OpenSSH using GSSAPI Authentication 
and GSSAPI Key Exchange.

In the very simplest case we would have 2 hosts -- one for CVS and one 
for Subversion.  If one of the hosts fails, the service running on that 
host (eg CVS) can be moved to the other host simply by remounted the 
filesystem and moving the virtual interface.  From the clients perspective 
all they will (hopefully) notice is a slight delay, after which the same 
data will be available via the same hostname and IP address.

The reason I originally posted this to the Kerberos list is because I 
assumed it was related to the Kerberos library since that's where the 
error originated.

But now it appears the solution is upgrading to OpenSSH 4.5p1 along with 
the associated GSSAPI Key Exchange patch.  The 4.5p1 GSSKEX patch supports 
a new config option (introduced in 4.4p1) "GSSAPIStrictAcceptorCheck=no" 
which, according to the man page:

   ... If 'no' then the client may authenticate against any service key
   stored in the machine's default store.  This facility is provided to
   assist with operation on multi home machines. ...

After initial testing, it appears this will solve the problem I'm seeing.