OpenSSH problem on Solaris 8

[Nicolas.Williams@ubsw.com]

Ideally the acceptor name is irrelevant to the acceptor. After all, the ability to accept a sec context implies having the necessary and valid keytab entries available, and that is good enough IMHO. Such behaviour would be necessary on virtualized servers.

For the acceptor to accept GSS contexts without regard as to the acceptor name used by the initiator you need a patch to MIT krb5's GSS implementation. The idea is to call gss_accept_sec_context() with the default acceptor credential and later use gss_inquire_sec_context() to determine the actual acceptor name, if desired.

Nico
--  

> -----Original Message-----
> From: Steve Langasek [mailto:vorlon at dodds.net]
> Sent: Wednesday, May 22, 2002 11:28 AM
> To: Jacques A. Vidrine
> Cc: Marc; kerberos at mit.edu
> Subject: Re: OpenSSH problem on Solaris 8
> 
> 
> On Wed, May 22, 2002 at 08:32:55AM -0500, Jacques A. Vidrine wrote:
> > On Wed, May 22, 2002 at 01:42:54PM +0200, Marc wrote:
> > > Well that's strange because I have one:
> 
> > > bash-2.03# klist -k
> > > Keytab name: FILE:/etc/krb5/krb5.keytab
> > > KVNO Principal
> > > ---- 
> > > 
> --------------------------------------------------------------
> ------------
> > >     1 host/hostname.domain.com at REALM
> 
> > Is `hostname.domain.com' the same as the output of the hostname
> > command?
> 
> > If I recall correctly, Simon's modifications indirectly use
> > gethostname() to determine the server principal name to 
> use.  This is
> > different than what most Kerberos network applications do (they
> > typically use getsockname()).  It matters if your machine 
> has multiple
> > interfaces, or if for any other reason your hostname is 
> different than
> > the name you give the client.
> 
> > i.e.
> 
> >    client% ssh foo
> 
> >    server% hostname
> >    bar
> 
> > foo and bar must match.
> 
> > I sent Simon some patches some time ago to (a) allow one to specify
> > how to get the server name in the server (sshd) and (b) allow one to
> > specify a different name to use at the client (ssh) to handle such
> > cases, as well as tunneling and things of that nature where the
> > network name does not match the server name.  I can dig 
> them up if you
> > like.
> 
> I would love it if you could send these patches to me (or to 
> the list),
> because it would save me the trouble of writing them.  I have 
> a two-node
> high availability cluster here that I'd like to use kerberized ssh on,
> and it bugs me to no end that starting services on one of the 
> nodes (and
> bringing up the shared IP address) causes ssh to smell funny 
> on the node's
> real IP.  I'm always happy to accept a patch that'll save me 
> the time to 
> implement it myself. :)
> 
> Cheers,
> Steve Langasek
> postmodern programmer
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> http://mailman.mit.edu/mailman/listinfo/kerberos
> 

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.