On 09/11/2013 10:10 PM, Dean Hunter wrote:
> On Wed, 2013-09-11 at 21:34 -0400, Dmitri Pal wrote:
>> On 09/11/2013 09:27 PM, Dean Hunter wrote:
>>> On Wed, 2013-09-11 at 21:10 -0400, Dmitri Pal wrote:
>>>> On 09/11/2013 08:49 PM, Dean Hunter wrote:
>>>>> On Wed, 2013-09-11 at 11:49 -0400, Simo Sorce wrote:
>>>>>> On Wed, 2013-09-11 at 10:39 -0500, Dean Hunter wrote:
>>>>>> > On Wed, 2013-09-11 at 11:20 -0400, Simo Sorce wrote: 
>>>>>> > > On Wed, 2013-09-11 at 08:39 -0500, Dean Hunter wrote:
>>>>>> > > 
>>>>>> > > > I do NOT believe this:
>>>>>> > > >         [dean@ipa2 ~]$ ssh dean@desktop2
>>>>>> > > >         Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org
>>>>>> > > >         Could not chdir to home directory /home/net/dean: 
>>>>>> > > > Permission
>>>>>> > > >         denied
>>>>>> > > >         -bash: /home/net/dean/.bash_profile: Permission denied
>>>>>> > > >         
>>>>>> > > >         -bash-4.2$ logout
>>>>>> > > >         -bash: /home/net/dean/.bash_logout: Permission denied
>>>>>> > > >         Connection to desktop2 closed.
>>>>>> > > >         
>>>>>> > > >         [dean@ipa2 ~]$ su -
>>>>>> > > >         Password: 
>>>>>> > > >         
>>>>>> > > >         [root@ipa2 ~]# ssh dean@desktop2
>>>>>> > > >         dean@desktop2's password: 
>>>>>> > > >         Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org
>>>>>> > > >         
>>>>>> > > >         [dean@desktop2 ~]$ logout
>>>>>> > > >         Connection to desktop2 closed.
>>>>>> > > >         
>>>>>> > > >         [root@ipa2 ~]# logout
>>>>>> > > >         
>>>>>> > > >         [dean@ipa2 ~]$ ssh dean@desktop2
>>>>>> > > >         Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org
>>>>>> > > >         
>>>>>> > > >         [dean@desktop2 ~]$ 
>>>>>> > > > 
>>>>>> > > 
>>>>>> > > Are you using a kerberized NFS mount ?
>>>>>> > > 
>>>>>> > > I think what is happening is that when going via SSH rpc.gssd cannot
>>>>>> > > find your ticket, ssh may be doing something "wrong" in this case.
>>>>>> > > 
>>>>>> > > Simo.
>>>>>> > > 
>>>>>> > Yes, I am using Kerberos with NFS.
>>>>>> > 
>>>>>> > Should I report this as a bug?
>>>>>> > 
>>>>>> We need to decide what component is faulty. It may be possible we can
>>>>>> get it working somehow.
>>>>>>
>>>>>> When you ssh in what is the ccache ssh assign you ?
>>>>>> can you run klist and post the output (sanitize it if needed) ?
>>>>>>
>>>>>> Simo.
>>>>>>
>>>>> I hope this is what you requested:
>>>>>
>>>>>     [dean@ipa2 <mailto:dean@ipa2> ~]$ klist
>>>>>     Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR
>>>>>     Default principal: d...@hunter.org <mailto:d...@hunter.org>
>>>>>
>>>>>     Valid starting     Expires            Service principal
>>>>>     09/11/13 19:43:28  09/12/13 19:43:28 
>>>>>     krbtgt/hunter....@hunter.org <mailto:hunter....@hunter.org>
>>>>>
>>>>>     [dean@ipa2 <mailto:dean@ipa2> ~]$ ssh dean@desktop2
>>>>>     <mailto:dean@desktop2>
>>>>>     Last login: Wed Sep 11 19:41:48 2013 from ipa2.hunter.org
>>>>>     Could not chdir to home directory /home/net/dean: Permission
>>>>>     denied
>>>>>     -bash: /home/net/dean/.bash_profile: Permission denied
>>>>>
>>>>>     -bash-4.2$ hostname
>>>>>     desktop2.hunter.org
>>>>>
>>>>>     -bash-4.2$ klist
>>>>>     klist: No credentials cache found (ticket cache
>>>>>     FILE:/tmp/krb5cc_1387400001)
>>>>>
>>>>>     -bash-4.2$ logout
>>>>>     -bash: /home/net/dean/.bash_logout: Permission denied
>>>>>     Connection to desktop2 closed.
>>>>>
>>>>>     [dean@ipa2 <mailto:dean@ipa2> ~]$ klist
>>>>>     Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR
>>>>>     Default principal: d...@hunter.org <mailto:d...@hunter.org>
>>>>>
>>>>>     Valid starting     Expires            Service principal
>>>>>     09/11/13 19:43:28  09/12/13 19:43:28 
>>>>>     krbtgt/hunter....@hunter.org <mailto:hunter....@hunter.org>
>>>>>     09/11/13 19:44:43  09/12/13 19:43:28 
>>>>>     host/desktop2.hunter....@hunter.org
>>>>>     <mailto:desktop2.hunter....@hunter.org>
>>>>>
>>>>>     [dean@ipa2 <mailto:dean@ipa2> ~]$
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Freeipa-users mailing list
>>>>> Freeipa-users@redhat.com <mailto:Freeipa-users@redhat.com>
>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>> Do I get it right: you tried twice and the first time it did not
>>>> work while the second it did?
>>>> There might be a race condition mounting your home directory using
>>>> your ticket.
>>>>
>>>> -- 
>>>> Thank you,
>>>> Dmitri Pal
>>>>
>>>> Sr. Engineering Manager for IdM portfolio
>>>> Red Hat Inc.
>>>>
>>>>
>>>> -------------------------------
>>>> Looking to carve out IT costs?
>>>> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeipa-users mailing list
>>>> Freeipa-users@redhat.com <mailto:Freeipa-users@redhat.com>
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>
>>> Starting clean after rebuilding ipa2 and desktop2 and a gdm login to
>>> ipa2 as dean, if I "ssh dean@desktop2 <mailto:dean@desktop2>" it
>>> will consistently fail as noted in my last note.  However, if I:
>>>
>>>  1. su -
>>>  2. ssh dean@desktop2 <mailto:dean@desktop2>
>>>  3. logout of dean@desktop2 <mailto:dean@desktop2>
>>>  4. logout of root@ipa2 <mailto:root@ipa2>
>>>
>>> then "ssh dean@desktop2" <mailto:dean@desktop2> succeeds!
>>>
>>> Does that answer your question?  So I do not think there is a race. 
>>> It is more like the super user session leaves something behind that
>>> was missing?
>>
>> Does it succeed if after step 3 but before step 4 you do kdestoy?
>>
>>
>> -- 
>> Thank you,
>> Dmitri Pal
>>
>> Sr. Engineering Manager for IdM portfolio
>> Red Hat Inc.
>>
>>
>> -------------------------------
>> Looking to carve out IT costs?
>> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>>
>
> Hah!  Even better, it works the first time and every time, if I start
> with a kdestroy:
>
>  1. From Virtual Machine Manager open ipa2
>  2. Login as dean
>  3. Open a terminal
>  4. kdestroy
>  5. ssh dean@desktop2 <mailto:dean@desktop2>
>  6. logout
>  7. ssh dean@desktop2 <mailto:dean@desktop2>
>  8. logout
>
> Now, the fun starts.  Why do it do that?
>
>
Now you need to see what you have before kdestroy.
Klist will help to see what cache is in play.
Then you need to see whether you as dean can access this cache (check
permissions and SELinux).

Based on the input you provided earlier the cache might be in
FILE:/tmp/krb5cc_1387400001
While after you login it is in
DIR::/run/user/1387400001/krb5cc/tktFDDxRR
The latter is the right one.
All applications in Fedora starting F18 should use DIR cache.
It seems that on this machine there is some other kerberized software
(NFS client?) that is not configured or updated to create DIR cache
style cache and continues to use FILE style cache. There have been a
slew of bugs around this. It seems you are hitting one of those.
Just FYI to avoid this confusion and to fight some race conditions
related to creation of the /run/user/uid directory the cache is now
moved to kernel and we are in process of updating different components
to use it.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to