The reproducer doesn't modify alice's .k5users file, so I'm a bit confused about what we're being shown here.

The k5login manpage quite explicitly mentions remote access as the main use case.
An excerpt:
       Suppose the user alice had a .k5login file in her home  directory  con‐
       taining the following line:

              bob

       This  would  allow  bob  to  use Kerberos network applications, such as
       ssh(1), to access alice's account, using bob's Kerberos tickets.

And afaik this has always been the case.

I am closing as NOTABUG.

I'm not sure if your reproducer is correct either. Did you wanted to say

# echo bob >/home/alice/.k5users
# chown alice:alice /home/alice/.k5users
# ssh alice@`hostname`


(.k5users instead of .k5login)

If this is the case you might want to open this ticket against openssh becasue its the openssh's sshd which offers this functionality. The idea was that ssh can be used like ksu to allow the execution specific commands as the target users. But this requires that the list of allowed commands must follow the principal in .k5users. If there is no command I would expect that .k5users bahave like .k5login and allows shell (i.e. general) access.

(In reply to Sumit Bose from comment #4)
> I'm not sure if your reproducer is correct either. Did you wanted to say
> 
> # echo bob >/home/alice/.k5users
> # chown alice:alice /home/alice/.k5users
> # ssh alice@`hostname`
> 
> 
> (.k5users instead of .k5login)
> 

Yes, that was what I meant. Sorry, it was a copy/paste error.

> If this is the case you might want to open this ticket against openssh
> becasue its the openssh's sshd which offers this functionality. The idea was
> that ssh can be used like ksu to allow the execution specific commands as
> the target users. But this requires that the list of allowed commands must
> follow the principal in .k5users. If there is no command I would expect that
> .k5users bahave like .k5login and allows shell (i.e. general) access.

You are right. It is in sshd man page, I should have checked that. I blindly thought that krb5 changed. But since the new behaviour is documented in sshd man page, and seems to work as documented, I don't think the case needs to be forwarded to ssh. Thanks for explanation; this is not a bug, indeed.

One more question. Shouldn't the "k5users" method listed/implemented here too? 

http://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/krb5_conf.html#localauth-interface

k5login is listed there and I can disable ssh login with:

[plugins]
 localauth = {
  disable = k5login
 }

if k5login is configured. But k5users can not be disabled.

k5users is specific to ksu, krb5.conf knows nothing about it.

I'm not sure why we introduced support for ~/.k5users or who uses it. To drop the hole patch with this would be one option.

However I would add a new control option to sshd_conf called KerberosEnablek5users which will control using ~/.k5users files. It would be disabled by default due to CVE-2014-9278  but it could be enabled by an administrator.

There will be one check in the code:

--- a/gss-serv-krb5.c
+++ b/gss-serv-krb5.c
@@ -269,7 +269,7 @@ ssh_gssapi_krb5_cmdok(krb5_principal principal, const char *name,
 
        snprintf(file, sizeof(file), "%s/.k5users", pw->pw_dir);
        /* If both .k5login and .k5users DNE, self-login is ok. */
-       if (!k5login_exists && (access(file, F_OK) == -1)) {
+       if ( !options.enable_k5users || (!k5login_exists && (access(file, F_OK) == -1))) {
                 return ssh_krb5_kuserok(krb_context, principal, luser,
                                         k5login_exists);
        }

Created attachment 979678 [details]
KerberosEnablek5users.patch

KerberosUseKuserok
   Specifies whether to look at .k5users file for GSSAPI authentication access control. Further details are described in ksu(1). The default is “no”.

It should be:

KerberosEnablek5users
   Specifies whether to look at .k5users file for GSSAPI authentication access control. Further details are described in ksu(1). The default is “no”.

After discussion with Patrick, I'm closing this as a duplicate of 1169843

*** This bug has been marked as a duplicate of bug 1169843 ***

*** This bug has been marked as a duplicate of bug 1170745 ***