krb5 problem: KRB5CCNAME is ""; possible fix for OpenSSH 3.0.2p1

[Mark Wagner]

I'm using a OpenSSH 3.0.2p1 with the krb5 patch from
<http://www.sxw.org.uk/computing/patches/openssh.html>.

I'm getting KRB5CCNAME set to "" even though
<http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=98269278629018&w=2>
mentions fixing it. This causes things like kinit to
fail with a somewhat uninformative error message.

The relevant sshd_config lines I use are:

# To change Kerberos options
KerberosAuthentication yes
KerberosOrLocalPasswd yes
#AFSTokenPassing no
KerberosTicketCleanup yes

# Kerberos TGT Passing does only work with the AFS kaserver
KerberosTgtPassing no

I'm using MIT Kerberos.

As far as I can tell (after scanning the code for a few hours
and I'm not a programmer) the problem is in auth_krb5_password.

    244         problem = krb5_cc_resolve(authctxt->krb5_ctx, "MEMORY:",
    245             &authctxt->krb5_fwd_ccache);

the name "MEMORY:" seems to cause krb5_cc_get_name at

    287         authctxt->krb5_ticket_file = (char *)krb5_cc_get_name(authctxt->        krb5_ctx, authctxt->krb5_fwd_ccache);

to return "" rather than NULL, so that sesssion.c sets KRB5CCNAME
in the shell environment to "" in lines 1294-1296.

I've tried two changes that seem to fix the problem. The first is
a simple hack of replacing line 287 with

    287         authctxt->krb5_ticket_file = NULL.

The second is to replace lines 244 and 245 with

   244  {
   245          char ccname[35];
   246
   247          snprintf(ccname, sizeof(ccname), "FILE:/tmp/krb5cc_%d", authctxt->pw->pw_uid);
   248          problem = krb5_cc_resolve(authctxt->krb5_ctx, ccname,
   249              &authctxt->krb5_fwd_ccache);
   250  }

(The security implications of the latter make me nervous. I hope Kerberos
is handling writing to /tmp carefully and there isn't some interaction
between sshd and Kerberos such that the file is read as root and the
user can tell sshd to look at an arbitrary file.)

I do not subscribe to this list but I will check the archive for
responses.

-- 
Mark Wagner markwag at u.washington.edu
University of Washington Medical Center
Unix System Administrator, Radiation Oncology and Radiology