OpenSSH and Kerberos / Active Directory authentication problems: Credentials cache permission incorrect / No Credentials Cache found

[Douglas E. Engert]

Matthias Gerstner wrote:

> Douglas E. Engert wrote:
> 
> 
>>This sounds like our site, AD for the KDCs, and OpenAFS, but we have some
>>extra pam routines, pam_afs2 and pam_krb5_ccache, for systems where the vendor's
>>pam_krb5 does not know about AFS.
> 
> 
> In my case it's part of the infrastructure at my university. We're
> running the Kerberos/OpenAFS setup for about three months now on about
> 100 clients with Gentoo Linux.
> On the pam side we use pam_krb5 for authentication and
> pam_openafs_session from debian for getting AFS tokens during login.

During login using a password, Kerberos should get you two tickets,
one it the ticket granting ticket, the other is a service ticket for the local
host. The second ticket is need to avoid an attack where a user replaces
the network, and the KDC with ther own version then use the password
stored in their KDC to login to the host. This attack will not
work if the host tries to get the second ticket, as it holds the
real key for the host in the krb5.keytab, and can detect a bogus
KDC.


The krb5.keytab may also be called a servtab, The name has changed
over the years.


I bet that with the pam_krb5 you have not set the validate option
or some thing similiar. This option does the above check. On a peronal
workstaion, you may be willing to live with the above attack.

OpenSSH gets the  service ticket. The man sshd_config states
in the kerberosAuthentication sesion that you must have a servtab.

Also if you use gssapi for authenticaiton you must have the
krb5.keytab or servtab as well.

> 
> We're still gaining experience with this setup. It's running
> surprisingly stable after a hard time for setting up the whole thing.
> Only the OpenSSH issue is causing some headache now.
> 
> 
>>>--
>>>-bash: GSSAPI Error: Miscellaneous failure (No Credentials cache found)
>>>--
>>>
>>
>>
>>Does the host have a host/<fqdn>@<REALM> principal in the krb5.keytab?
> 
> 
> No there's no such keytab entry on the OpenSSH server. Is it needed?

Yes see above.

> 
> I'm sorry that I'm not too familiar with kerberos as I first began
> working with it related to the mentioned infrastructure setup.
> 
> I didn't think that there's needed any additional kerberos setup /
> communication when wanting to login via a ssh server.
> 
> 
>>>Also the variable KRB5CCNAME isn't defined. I've investigated about this
>>>problem already on the net and tried different setups and approaches but
>>>to no avail. I need the kerberos5 ticket for use of OpenAFS.
>>>

Once you get the krb5.keytab setup, this should also work. The problems
where prior to 3.9 I believe.

>>
>>
>>DOes it write it to some other location?
> 
> 
> I don't see a trace of the kerberos ticket. klist does not recognize
> anything. The only thing I can imagine is that OpenSSH is keeping the
> ticket in memory as I've read in some older postings on the net.
> 
> And there have also been discussed issues about the KRB5CCNAME
> environment variable being defined too late in the pam processing when
> using OpenSSH. But this postings are mostly rather old and I guess these
> problems are fixed in the meantime.
> 
> But my problem may be somehow similar to the before mentioned ones.
> 
> 
>>Yes it is critical. It is an authorization check that says this
>>user principal is allowed to use this local unix account.
>>
>>It looks at the ~/.k5login and the  krb5.conf  [realm] auth_to_local
>>variables to do test the mapping.
>>
>>By default, if the kerberos principal is user at realm  and the local account
>>is username and user == username  and realm == default-realm-of-host,
>>then krb5_kuserok does not need to check the .k5login.
>>
>>(With AD the realm is the uppercase of the AD domain name, fully qualified)
> 
> 
> These conditions all apply to my setup. The AD domain name is the
> default realm in krb5.conf and unix usernames are the same as the
> kerberos usernames.
> 
> krb5.conf:
> --
> [libdefaults]
> 	default_realm = SOME.DOMAIN.DE
> [,,,]
> 
> kinit in66666
> Password for in66666 at SOME.DOMAIN.DE
> [...]
> 
> id in66666
> uid=66666(in66666) [...]
> 
> So everything should be allright with krb5_kuserok ...
> 
> Thanks so far,
> 
> Matthias Gerstner
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444