Bug 1278017 - ssh login with credential forwarding gives me a subsidiary ccache; can't kinit to another user
ssh login with credential forwarding gives me a subsidiary ccache; can't kini...
Status: ASSIGNED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssh (Show other bugs)
7.1
Unspecified Linux
medium Severity medium
: rc
: ---
Assigned To: Jakub Jelen
BaseOS QE Security Team
:
: 1278018 (view as bug list)
Depends On: 1199363
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-04 09:47 EST by Charles Slivkoff
Modified: 2017-08-20 13:09 EDT (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1199363
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Charles Slivkoff 2015-11-04 09:47:38 EST
+++ This bug was initially created as a clone of Bug #1199363 +++

Basically, on the box that I originally logged into (via KDM):

> klist
Ticket cache: KEYRING:persistent:7225:krb_ccache_8LMqrkh
Default principal: tibbs@MATH.UH.EDU

Valid starting       Expires              Service principal
03/05/2015 21:19:44  03/06/2015 21:19:44  krbtgt/MATH.UH.EDU@MATH.UH.EDU
        renew until 03/12/2015 20:44:18

I can kinit to another principal:

> kinit tibbs/admin
Password for tibbs/admin@MATH.UH.EDU:

Now, if I first ssh to another host:

> ssh ld01
Last login: Thu Mar  5 21:25:03 2015 from epithumia.e.math.uh.edu

ld01:~> klist
Ticket cache: KEYRING:persistent:7225:7225
Default principal: tibbs@MATH.UH.EDU

Valid starting       Expires              Service principal
03/05/2015 21:25:16  03/06/2015 21:19:44  krbtgt/MATH.UH.EDU@MATH.UH.EDU
        renew until 03/12/2015 20:44:18

Then I can't kinit to another principal:

ld01:~> kinit tibbs/admin
kinit: Can't create new subsidiary cache because default cache is already a subsdiary while generating new ccache

Simo seems to know what's up and asked me to file a bug.  I'm running updated F21; here are some hopefully relevant versions:

krb5-libs-1.12.2-9.fc21.x86_64
openssh-6.6.1p1-11.1.fc21.x86_64
pam_krb5-2.4.9-3.fc21.x86_64
pam-1.1.8-16.fc21.x86_64
kernel-3.18.7-200.fc21.x86_64

--- Additional comment from Jakub Jelen on 2015-03-17 08:22:47 EDT ---

OK. I can reproduce it on my machine. It also appears when you try to kinit to different user (not only principal).

When you try to list tickets with flags (klist -f), you will see that the last ticket has a "f" flag, which means that it is forwarded (and used for authentication for this host?) so you probably can't overwrite it with different ticket?
seems to be related to this one: bz974947


Simo? What do you think? What is expected behaviour?

Just tested with DIR ccache and I'm unable to get the forwarded ticket on second server.

--- Additional comment from Simo Sorce on 2015-03-17 09:13:23 EDT ---

(In reply to Jakub Jelen from comment #1)
> OK. I can reproduce it on my machine. It also appears when you try to kinit
> to different user (not only principal).
> 
> When you try to list tickets with flags (klist -f), you will see that the
> last ticket has a "f" flag, which means that it is forwarded (and used for
> authentication for this host?) so you probably can't overwrite it with
> different ticket?
> seems to be related to this one: bz974947
> 
> 
> Simo? What do you think? What is expected behaviour?
> 
> Just tested with DIR ccache and I'm unable to get the forwarded ticket on
> second server.

It's a tricky situation, on the one hand it may make sense to have a subsidiary cache, on the other it causes a number of restrictions we shouldn't really suffer.

We probably need to discuss what are the expectations as an ssh user and see if we need some tunables or not.

My initial thinking is that, if you have a Cache Collection, what you can do is to stick the delegated credentials in a subsidiary, but still put the whole collection in KRB5CCNAME and just kswitch to the newly stored credentials as the default creds.
However, if you are already logged into the console or from another ssh session, doing a kswitch will affect all terminals, so I am hesitant.

Perhaps, it should be a tunable where you can tell sshd what is the preference: stick to subsidiary vs expose the whole collection.

--- Additional comment from Jakub Jelen on 2015-03-26 12:14:23 EDT ---

OK. I had the second look at this issue and from my point of view, we should do it all the same way how the FILE and DIR cache does it. My testing with different default_ccache_name showed that you can do the above mentioned kinit with all the other configurations:
http://paste.fedoraproject.org/203252/27382909/

So only KEYRING is set up as subsidiary cache.

There is no reason to block kinit, because there is workaround to use "kdestroy; kinit user" to change to different principal.

sshd is handling ccache by hand and KEYRING is supported after this bz991186. We are using functions krb5_cc_initialize, krb5_cc_store_cred from krb5.h so if I'm right we can

Unfortunately, there is not much documentation about KEYRING ccache. I don't think that we specify somewhere it it should be subsidiary or do handle this cache different than the others. If it is a bug, probably in krb5 libraries IMHO.

--- Additional comment from Jason Tibbitts on 2015-03-26 12:46:47 EDT ---

Unfortunately the workaround of "kdestroy; kinit whatever" has implications for kerberized NFS so it's not entirely a perfect solution, but I can deal either way.  I just thought it was odd that whether you can kinit depends on both your ccache type and how you happened to log in.

--- Additional comment from Simo Sorce on 2015-03-26 13:33:14 EDT ---

Ok I think we can move this to krb5, if the KEYRING ccache behaves subnstantially differently than a FILE/DIR ccache we may consider it a KEYRING ccache bug indeed.

--- Additional comment from Roland Mainz on 2015-03-26 19:52:17 EDT ---

(In reply to Simo Sorce from comment #5)
> Ok I think we can move this to krb5, if the KEYRING ccache behaves
> subnstantially differently than a FILE/DIR ccache we may consider it a
> KEYRING ccache bug indeed.

Who wrote the initial KEYRING support in krb5 ?

--- Additional comment from Simo Sorce on 2015-03-27 09:13:31 EDT ---

(In reply to Roland Mainz from comment #6)
> Who wrote the initial KEYRING support in krb5 ?

I think Nalin did the old KEYRING code, and I refactored it heavily to make it a Collection Type.

--- Additional comment from Nalin Dahyabhai on 2015-03-27 09:47:20 EDT ---

You flatter me.  The git log attributes it to Kevin Coffman.

--- Additional comment from Charles Slivkoff on 2015-06-01 11:20:32 EDT ---

This is also an issue for RHEL 7. 

Is another BZ needed?

--- Additional comment from Fedora End Of Life on 2015-11-04 05:36:30 EST ---

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 2 Robbie Harwood 2015-11-09 14:42:19 EST
*** Bug 1278018 has been marked as a duplicate of this bug. ***
Comment 3 Robbie Harwood 2016-01-06 09:34:34 EST
The referenced bug has been closed.  Since we have a newer version of krb5 in RHEL7 than what closed it, could you please confirm that this is still a bug, else I will close this ticket?
Comment 4 Charles Slivkoff 2016-01-06 09:46:03 EST
RHEL7 continues to behave the same.

I ssh to a RHEL7 server and authenticate via GSSAPI.

Attempts to kinit to another instance without first kdestroy return this failure:

kinit: Can't create new subsidiary cache because default cache is already a subsidiary while generating new ccache
Comment 5 Charles Slivkoff 2016-01-06 11:47:23 EST
(In reply to Charles Slivkoff from comment #4)
> RHEL7 continues to behave the same.
> 
> I ssh to a RHEL7 server and authenticate via GSSAPI.

with GSSAPIDelegateCredentials=yes 
 
> Attempts to kinit to another instance without first kdestroy return this
> failure:
> 
> kinit: Can't create new subsidiary cache because default cache is already a
> subsidiary while generating new ccache
Comment 14 Robbie Harwood 2017-07-21 15:29:59 EDT
(See Fedora bug for more information.)

Note You need to log in before you can comment on or make changes to this bug.