Here's an excerpt from our standard /etc/krb5.conf file: [appdefaults] pam = { EXAMPLE.ORG = { ccache_dir = /ccache } } The /ccache directory is a tiny tmpfs filesystem that is mounted mode 01333: $ ls -lsad /ccache 0 d-wx-wx-wt 2 root root 40 Feb 25 17:16 /ccache Locating the credential cache files in this directory offers an additional level of privacy over using /tmp (the default value for ccache_dir), because users cannot enumerate the directory contents to see who has credentials cached on the host. Since the cache files are created via mkstemp() using a template of %d/krb5cc_%U_XXXXXXXXXX, guessing the names of cache files is extremely difficult. With the above configuration on a RHEL 5Server host, and PAM on the host configured to use the pam_krb5 module, if I log in via any service EXCEPT openssh, the credential cache is properly located in /ccache. But if I login via openssh (which is by far the most frequent login method), the credential cache is located in /tmp: $ ssh -o PreferredAuthentications=gssapi-with-mic -o GSSAPIDelegateCredentials=yes rhel5box.example.org 'echo $KRB5CCNAME' FILE:/tmp/krb5cc_1000_evOyW24345 So, somehow, openssh overrides or ignores the ccache_dir setting. As with bug 486256, Fedora 10 does the right thing: when I log into my Fedora 10 host via openssh with the same configuration, the credential cache is properly located in /ccache: $ ssh -o PreferredAuthentications=gssapi-with-mic -o GSSAPIDelegateCredentials=yes f10box.example.org 'echo $KRB5CCNAME' FILE:/ccache/krb5cc_4524_pnNKCc RHEL5 packages: openssh-4.3p2-29.el5.x86_64 pam-0.99.6.2-4.el5.x86_64 pam_krb5-2.2.14-10.x86_64 F10 packages: openssh-5.1p1-3.fc10.x86_64 pam-1.0.2-2.fc10.x86_64 pam_krb5-2.3.2-1.fc10.x86_64
Cross-filed as Red Hat Service Request 1901382.
An update from bug 486256: if one also sets "use_shmem = sshd" in the "pam" section of [appdefaults], then keyboard-interactive authentication will obey the ccache_dir. This makes no difference for gssapi-with-mic and password authentication, however; they use /tmp regardless of whether use_shmem is set.
gssapi-with-mic I understand, as it doesn't go through PAM to acquire the forwarded credentials, so the PAM module isn't what's determining where the ccache ends up. sshd would have to expose an option of its own to provide a way to control that behavior. Password authentication, if "KerberosAuthentication" is enabled in the server, appears to be attempted outside of PAM first. Can you set "debug = true" in the [appdefaults] "pam" section, modify /etc/syslog.conf so that debug messages are saved to a file ("*.* /var/log/debug" would do the trick), restart syslogd, attempt the login, and either paste or attach the log messages you get on the system that doesn't behave correctly, along with its sshd_config file?
Ok, I figured out what is happening: when pam_krb5 runs for the account service, more recent pam_krb5 modules are actually copying the credentials from the stash file that sshd creates (see the log excerpt I'll attach momentarily). Also, I was incorrect: both password and keyboard-interactive authentication obey the ccache_dir setting. Here's the openssh code that creates the credential cache (in auth-krb5.c): krb5_error_code ssh_krb5_cc_gen(krb5_context ctx, krb5_ccache *ccache) { int tmpfd, ret; char ccname[40]; mode_t old_umask; ret = snprintf(ccname, sizeof(ccname), "FILE:/tmp/krb5cc_%d_XXXXXXXXXX", geteuid()); if (ret < 0 || (size_t)ret >= sizeof(ccname)) return ENOMEM; old_umask = umask(0177); tmpfd = mkstemp(ccname + strlen("FILE:")); Notice that the credential cache file is completely hardcoded. I think the best solution here is for sshd to provide an option to change the location of the credential cache. I'll write a patch to do so and see if upstream is willing to take it.
Created attachment 334581 [details] pam_krb5 debug syslog messages This shows that recent versions of pam_krb5 copy the Kerberos credentials that sshd creates in /tmp to the location specified by ccache_dir and ccname_template. (Look at the 10 lines or so following the "checking for externally-obtained v5 credentials" line.)
(In reply to comment #4) > Ok, I figured out what is happening: when pam_krb5 runs for the account > service, more recent pam_krb5 modules are actually copying the credentials from > the stash file that sshd creates (see the log excerpt I'll attach momentarily). Oh, right. We also turned on "external" by default for sshd at about the same time, so that it could use forwarded credentials to obtain AFS tokens (if you're using AFS, anyway). I haven't looked lately, but sshd is still managing the ccache it creates in /tmp, and having pam_krb5 create another one doesn't cause that to stop happening.
(In reply to comment #4) > I think the best solution here is for sshd to provide an option to change the > location of the credential cache. I'll write a patch to do so and see if > upstream is willing to take it. Have you written the patch, if so can you refer it in mindrot bz?
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. After consideration, Red Hat does not plan to incorporate the suggested capability in a future release of RHEL 5. If you would like Red Hat to re-consider your feature request beyond RHEL 5, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.