Problem with kerberos and ssh.

Simon Wilkinson simon at sxw.org.uk
Wed Mar 1 14:14:55 EST 2006


>>  I would have asked what other libgss could there possibly be.  But
>>  then someone on the openssh mailing list pointed out that I should
>>  just bypass the libgssapi-0.7 stuff entirely

That was me - I cross posted my (somewhat lengthy) response here too,
but it has yet to appear (I suspect that the address I sent it from may
not be subscribed to this list).

The short version of that post is that the CITI libgssapi currently
breaks lots of things, and is best avoided. Thunderbird has now got
checks in place to make sure it doesn't use it by mistake, and I suspect
similar checks may be needed in any other program which dynamically
loads their GSSAPI support, or uses a mechanism other than krb5-config
to identify a suitable GSSAPI library.

I'm not sure why OpenSSH got bitten by this - as, providing you've got a
 krb5-config file, OpenSSH will use that to identify which library to use.

> Linking directly to libgssapi_krb5 is a hack and is generally not going
> to be a  portable solution.

It's a fairly well established hack. The CITI libgssapi only just
appeared in Linux, and doesn't appear to be in any of the BSDs (which
have Heimdal's libgssapi) Also, until GSSAPI contains standard provision
for saving delegated credentials, its exactly what you're going to need
to do. Once OpenSSH has accepted a context, it needs to be able to save
the credentials that have been passed through into a mechanism specific
credential cache. In the Kerberos case, it does this by calling
gss_krb5_copy_ccache() - which is provided by libgssapi_krb5.

Perhaps, once the proposed extensions to GSSAPI are standardized, and
implemented this will no longer be the case - but at the moment I can't
see how you can have a mechanism independent glue library without
sacrificing significant server side functionality.

Cheers,

Simon.



More information about the Kerberos mailing list