Hello,
would it be acceptable to add an option for rpc.gssd to use host keytab if
user's kerberos ticket is not available?
Consider the following scenario:
1) machine has NFS mounted /home using kerberos authentication
2) user logs in, sshd creates krb ticket ($HOME/.k5login needs to be world
readable to allow kerberized access, e.g., using kerberos ticket)
3) user stays logged in and krb ticket expires
4) kinit to renew ticket produces strange error because $HOME is not
accessible and a new ticket is not created.
So, I think in this case, I would like to see rpc.gssd uses host keytab while
user's ticket is not available, which maps to nobody/nogroup, but kinit should
succeed.
Or are there any other options if one is using kerberized homes only?
--
Luk?? Hejtm?nek
Hello,
On 11/28/2016 01:37 PM, Lukas Hejtmanek wrote:
> Hello,
>
> would it be acceptable to add an option for rpc.gssd to use host keytab if
> user's kerberos ticket is not available?
I'm not sure how this would work.
The kernel would do an upcall to the user's
creds but they have expired. Now if this
new option is set, rpc.gssd would used
the machine's cred? It seems to me that
would not be too secure.
>
> Consider the following scenario:
> 1) machine has NFS mounted /home using kerberos authentication
> 2) user logs in, sshd creates krb ticket ($HOME/.k5login needs to be world
> readable to allow kerberized access, e.g., using kerberos ticket)
> 3) user stays logged in and krb ticket expires
> 4) kinit to renew ticket produces strange error because $HOME is not
> accessible and a new ticket is not created.
>
> So, I think in this case, I would like to see rpc.gssd uses host keytab while
> user's ticket is not available, which maps to nobody/nogroup, but kinit should
> succeed.
Who is going the kinits in this scenario?
>
> Or are there any other options if one is using kerberized homes only?
>
I'm pretty sure sssd will what you are looking for.
steved.
Hello,
On Tue, Nov 29, 2016 at 01:37:00PM -0500, Steve Dickson wrote:
> The kernel would do an upcall to the user's
> creds but they have expired. Now if this
> new option is set, rpc.gssd would used
> the machine's cred? It seems to me that
> would not be too secure.
maybe it is not considered secure, but it is still more secure to me than
using sec=sys.
the problem is, that kerberized home is problem for .k5login file and also for
.ssh/authorized_keys. While the .k5login file is accessed with root context
(sshd), the authorized_keys is accessed with user context, so login via ssh
pubkey is not possible at all.
moreover, consider scenario where a user has symlink from his/her home to NFS
share, without kerberos ticket, logon process can get stucked until he/she has
the ticket. The ticket cannot be created until success logon.
> > Consider the following scenario:
> > 1) machine has NFS mounted /home using kerberos authentication
> > 2) user logs in, sshd creates krb ticket ($HOME/.k5login needs to be world
> > readable to allow kerberized access, e.g., using kerberos ticket)
> > 3) user stays logged in and krb ticket expires
> > 4) kinit to renew ticket produces strange error because $HOME is not
> > accessible and a new ticket is not created.
> >
> > So, I think in this case, I would like to see rpc.gssd uses host keytab while
> > user's ticket is not available, which maps to nobody/nogroup, but kinit should
> > succeed.
> Who is going the kinits in this scenario?
the user comes back and wants to issue kinit. Kinit fails due to eperm on
anything in $HOME. The user has to log off and on again.
> I'm pretty sure sssd will what you are looking for.
how this could help me to work around expired tickets?
--
Luk?? Hejtm?nek
On 11/29/2016 01:48 PM, Lukas Hejtmanek wrote:
> Hello,
>
> On Tue, Nov 29, 2016 at 01:37:00PM -0500, Steve Dickson wrote:
>> The kernel would do an upcall to the user's
>> creds but they have expired. Now if this
>> new option is set, rpc.gssd would used
>> the machine's cred? It seems to me that
>> would not be too secure.
>
> maybe it is not considered secure, but it is still more secure to me than
> using sec=sys.
True.
>
> the problem is, that kerberized home is problem for .k5login file and also for
> .ssh/authorized_keys. While the .k5login file is accessed with root context
> (sshd), the authorized_keys is accessed with user context, so login via ssh
> pubkey is not possible at all.
What would the .k5login look like and what would the principal look like?
My apologies but I'm not very familar with how sshd interacts with
the .k5login.
>
> moreover, consider scenario where a user has symlink from his/her home to NFS
> share, without kerberos ticket, logon process can get stucked until he/she has
> the ticket. The ticket cannot be created until success logon.
Yeah... This has been a long running problem which is why
I'm curious about your RFC...
>
>>> Consider the following scenario:
>>> 1) machine has NFS mounted /home using kerberos authentication
>>> 2) user logs in, sshd creates krb ticket ($HOME/.k5login needs to be world
>>> readable to allow kerberized access, e.g., using kerberos ticket)
>>> 3) user stays logged in and krb ticket expires
>>> 4) kinit to renew ticket produces strange error because $HOME is not
>>> accessible and a new ticket is not created.
>>>
>>> So, I think in this case, I would like to see rpc.gssd uses host keytab while
>>> user's ticket is not available, which maps to nobody/nogroup, but kinit should
>>> succeed.
>> Who is going the kinits in this scenario?
>
> the user comes back and wants to issue kinit. Kinit fails due to eperm on
> anything in $HOME. The user has to log off and on again.
I see.
>
>> I'm pretty sure sssd will what you are looking for.
>
> how this could help me to work around expired tickets?
>
sssd will renew the ticket before it expired (I think).
But the user has to be known to a ipa-server on
an ipa-client, so this may not be workable...
steved.
On Mon, Nov 28, 2016 at 1:37 PM, Lukas Hejtmanek <[email protected]> wro=
te:
> Hello,
>
> would it be acceptable to add an option for rpc.gssd to use host keytab i=
f
> user's kerberos ticket is not available?
>
> Consider the following scenario:
> 1) machine has NFS mounted /home using kerberos authentication
> 2) user logs in, sshd creates krb ticket ($HOME/.k5login needs to be worl=
d
> readable to allow kerberized access, e.g., using kerberos ticket)
> 3) user stays logged in and krb ticket expires
> 4) kinit to renew ticket produces strange error because $HOME is not
> accessible and a new ticket is not created.
Why is kinit accessing something from $HOME. What distro are you using
to run kinit (or any other info to explain use of $HOME)?
I just ran kinit on RHEL7.2 and it nowhere does it read $HOME.
What I read here is that user has expired creds and is trying to
access a kerberized NFS file. The operation MUST fail, there is no way
around it. There shouldn't be any fixes that would allow for a user to
access files without credentials.
So in the environment where for whatever reason your kinit requires
read of $HOME, you must make sure credentials are refreshed before
they expire. Steve has mentioned that sssd takes on this
responsibility.
> So, I think in this case, I would like to see rpc.gssd uses host keytab w=
hile
> user's ticket is not available, which maps to nobody/nogroup, but kinit s=
hould
> succeed.
>
> Or are there any other options if one is using kerberized homes only?
>
> --
> Luk=C3=A1=C5=A1 Hejtm=C3=A1nek
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 29, 2016 at 02:28:10PM -0500, Steve Dickson wrote:
> > maybe it is not considered secure, but it is still more secure to me than
> > using sec=sys.
> True.
So, I was asking, if I provide such patch, will it be accepted into mainline
nfs-utils?
> > the problem is, that kerberized home is problem for .k5login file and also for
> > .ssh/authorized_keys. While the .k5login file is accessed with root context
> > (sshd), the authorized_keys is accessed with user context, so login via ssh
> > pubkey is not possible at all.
> What would the .k5login look like and what would the principal look like?
> My apologies but I'm not very familar with how sshd interacts with
> the .k5login.
ok, I did more testing. It seems that kinit does not search ~/.k5login but
~/.krb5/config.
If NFS client gets permission denied, it is ok and kinit just creates a new
ticket.
However, if user has ticket that expired, NFS client returns EKEYEXPIRED
instead of EPERM. In such a case, kinit/kdestoy does not deal with this errno
and returns:
kinit: krb5_init_context failed: 127
or
kdestroy: krb5_init_context failed: 127
if you do rm /tmp/krb5cc_`id -u`_*, EKEYEXPIRED is changed to EPERM and
kinit/kdestroy works again.
Colleague of me says that EKEYEPIRED should not be returned by NFS client at
all, EPERM should be always returned and he sees this as a bug in kernel code.
--
Luk?? Hejtm?nek