Description of problem: As part of the Fedora 18 features https://fedoraproject.org/wiki/Features/KRB5CacheMove and https://fedoraproject.org/wiki/Features/KRB5DirCache, we'd like to have sshd store a user's Kerberos credentials in the per-user /run/user/$UID directory. Specifically, instead of using "FILE:/tmp/krb5cc_%d_XXXXXXXXXX" and generating a file name based on it, I'd suggest first attempting "DIR:/run/user/%d/krb5cc_XXXXXXXX", possibly falling back to the current template if that doesn't work for some reason (such as /run/user not being there). It's a bit more complicated, but hopefully not too much so. Version-Release number of selected component (if applicable): openssh-6.0p1-1.fc18 How reproducible: Authenticate to sshd using either GSSAPIAuthentication with delegation enabled from the client, or with KerberosAuthentication. $KRB5CCNAME should point to a location under /run/user/%d, preferably of type "DIR:".
To clarify, the complications I alluded to include: * In krb5 1.10, the libraries don't create the directory if it doesn't exist when you go to initialize a ccache with krb5_cc_resolve() and krb5_cc_initialize(), but 1.11's libraries will. The 1.11 release is currently scheduled for after the F18 freeze, so if we make this change we'll have to at least do the mkdir() from inside of sshd. * The library's krb5_cc_destroy() may leave other files and the directory around, even when it returns successfully. The best you can probably do is remove files named "primary" or which have names that start with "tkt" from the directory, and then attempt to rmdir() the directory itself, either after or instead of calling krb5_cc_resolve()/krb5_cc_destroy().
Any news here? I'm trying to get a better idea of where we are for the feature in general.
I'm sorry, I've had something else to do but I'll look at it tommorow.
I've found an issue while I was testing sshd with sssd and kerberos authentication. /run/user/<UID> directory is created by pam_systemd which is run during session part of pam after authentication. So I see several pam_krb5 error messages before pam_systemd is run: Sep 6 18:19:14 rawhide sshd[2137]: pam_krb5[2137]: TGT verified Sep 6 18:19:14 rawhide sshd[2139]: pam_krb5[2139]: error copying credentials from "MEMORY:_pam_krb5_tmp_s_plautrba" to "FILE:/run/user/13558/krb5cc_fcLQBI" for the user Sep 6 18:19:14 rawhide sshd[2137]: pam_krb5[2137]: authentication succeeds for 'plautrba' (plautrba) Sep 6 18:19:14 rawhide sshd[2140]: pam_krb5[2140]: error copying credentials from "MEMORY:_pam_krb5_tmp_s_plautrba" to "FILE:/run/user/13558/krb5cc_lo7G1P" for the user Sep 6 18:19:14 rawhide sshd[2137]: Accepted password for plautrba from 192.168.122.1 port 54816 ssh2 Sep 6 18:19:14 rawhide sshd[2137]: pam_systemd(sshd:session): Asking logind to create session: uid=13558 pid=2137 service=sshd type=tty seat= vtnr=0 tty=ssh display= remote=yes remote_user= remote_host=master.virt ... It might be same for GSSAPIAuthentication but I can't confirm it right now and I'll do more investigation.
(In reply to comment #4) > I've found an issue while I was testing sshd with sssd and kerberos > authentication. > /run/user/<UID> directory is created by pam_systemd which is run during > session part of pam after authentication. > So I see several pam_krb5 error messages before pam_systemd is run: Yes, the changes to pam_krb5 are currently in-progress as well. But then if you're dealing with PasswordAuthentication you probably want to be turning on KerberosAuthentication rather than letting pam_krb5 deal with creating them. > It might be same for GSSAPIAuthentication but I can't confirm it right now > and I'll do more > investigation. Right, the cases I expect sshd to need to be updated for are the ones where it's directly creating credential caches, in contrast to cases where it's letting PAM do it (pam_krb5, pam_sss, maybe pam_winbind) - that's the PasswordAuthentication-with-KerberosAuthentication and GSSAPIAuthentication methods, unless I'm missing something. The docs for KerberosAuthentication tell me that the SSH server will need a keytab while testing it, and that's true for GSSAPIAuthentication as well. Probably the least manually-intensive way we have available to bring up a KDC, create the right entry in its realm database, and set up a keytab, is to configure a system as an IPA server (install freeipa-server, run ipa-server-install, then "ipa user-add" to add a client user). The test user should then be able to ssh from the server to itself (using its FQDN) using either their password or "kinit" and GSSAPI authentication.
My main concern is that a /run/user/<UID> directory is created during the start of session which is after the authentication when kerberos cache files are created. And I'm in doubt whether the openssh server or any other daemon should create this directory if it doesn't exist.
It might have to -- I only see session management functions being exported by the pam_systemd.so module, which I believe usually handles this step. sshd skips pam_authenticate() for pubkey and GSSAPI authentication, so having the module create the directory in its pam_sm_authenticate() method wouldn't help us, and anyway I can understand avoiding creating a directory just because we're checking a password. Care would have to be taken to ensure the right permissions (both traditional and SELinux) were applied to any directories that sshd created. Since I'd like to avoid adding logic, that would have to be maintained, to create that directory everywhere, having sshd create it wouldn't be my first choice. In the short-term, while we look for a different solution, we could land the "DIR:" part of this now and leave the "move" part for later. I don't see https://fedoraproject.org/wiki/Features/Polyinstantiated_Temporary_Directories landing in F18, and that removes much of the urgency of the "move" part of things. So sshd might want to continue to create caches in /tmp, as nfs-utils and cifs-utils will still know to look there.
Nalin, I disagree. IMO the move part is required for F18 for all components that create the cache. It is not an option and needs to be addressed. So please find a way to create a directory. Thanks Dmitri
Perhaps the krb5 ccache code could ask systemd somehow to create the directory?
The MIT code can potentially add a callback to create directory for the cred storage before placing the cache there. It then would have to have a platform specific implementation. In Fedora and derivatives it call call out to systemd. Is this the way to go if so we need to talk to MIT to create such callback interface?
(In reply to comment #9) > Perhaps the krb5 ccache code could ask systemd somehow to create the > directory? That assumes that the location in question is one that systemd is in the business of creating, and that systemd provides a method for asking it to do so. But a simpler question (and the one I've CC'd the systemd maintainers for input on) is: how we can trigger creation of a user's XDG_RUNTIME_DIR without having to call pam_open_session() or making a CreateSession method call?
Created attachment 612140 [details] use kerberos5 DIR cache storage This patch changes type of used kerberos credential cache to DIR type according to the KRB5DirCache feature. I'll probably going to somehow merge it into the existing openssh-5.9p1-gsskex.patch as openssh-6.0p1-gsskex.patch but first I'd like to ask for review these particular changes. The template for kerberos authentication has been changed to "DIR:/tmp/krb5cc_%d_XXXXXXXXXX", a directory is created instead of file. In cleanup, there's first check of existence of a primary file in the directory which is then removed and rmdir() is attempted. Similar actions are done also in GSSAPI session cleanup.
(In reply to comment #6) > My main concern is that a /run/user/<UID> directory is created during the > start of session > which is after the authentication when kerberos cache files are created. > And I'm in doubt whether the openssh server or any other daemon > should create this directory if it doesn't exist. It's OK if kerberos pre-creates the dir for pam_systemd. If it already exists it will not be deleted and things should be safe for kerberos. However, when the last session of the user ends the dir is entirely removed. Which is a good thing I presume. I'd suggest kerberos simply creates the dir and we add no further coupling between kerbereos and systemd. Howerver i can also add a D-Bus call for you guys you can invoke which simply creates the dir. To create the dir pam_systemd/logind does: mkdir_p("/run/user/$UID", 0700); chown("/run/user/$UID", $UID, $GID); selinux_relabel("/run/user/$UID"); And that's it. If you do the same in kerberos pam_systemd/logind will just take over that dir and continue using it.
openssh-6.1p1-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/openssh-6.1p1-1.fc18
Package openssh-6.1p1-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing openssh-6.1p1-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-13976/openssh-6.1p1-1.fc18 then log in and leave karma (feedback).
openssh-6.1p1-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
openssh-6.2p2-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/openssh-6.2p2-3.fc19
openssh-6.2p2-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.