RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1256610 - Kerberos tgt removed when logging out ssh session from local machine
Summary: Kerberos tgt removed when logging out ssh session from local machine
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: keyutils
Version: 7.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: David Howells
QA Contact: Kun Wang
URL:
Whiteboard:
Depends On:
Blocks: 1298243 1420851
TreeView+ depends on / blocked
 
Reported: 2015-08-25 06:36 UTC by adam winberg
Modified: 2023-09-14 03:04 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-16 16:25:08 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description adam winberg 2015-08-25 06:36:50 UTC 
Description of problem:
When i ssh to my local machine using the machine name (ie ssh mymachine) and then log out from the ssh session my kerberos tgt has been removed. 

This is only reproducible using the default KEYRING:persistent default ccache name. Using DIR och FILE i cannot reproduce this. 

journalctl reports:
goa[4731]: secret_password_lookup_sync() returned NULL [goautils.c:210, goa_utils_lookup_credentials_sync()]

Version-Release number of selected component (if applicable):
gnome-online-accounts-3.8.5-14.el7.x86_64

Probably not GOA thats at fault here, but dont really know what else is.

How reproducible:
Always, if using ccache type KEYRING:persistent

Steps to Reproduce:
1. Aquire TGT with kinit.
2. SSH to local machine using hostname (not 'localhost')
3. Log out from SSH session

Actual results:
klist shows no kerberos TGT.

Expected results:
TGT ticket for my session should not be removed.

Additional info:
Comment 2 adam winberg 2015-08-25 13:09:31 UTC 
Changed component to something more plausible, was also able to reproduce this on RHEL 7.1 server.

krb5-libs-1.12.2-14.el7.x86_64
krb5-workstation-1.12.2-14.el7.x86_64
Comment 3 Dmitri Pal 2015-08-25 15:08:07 UTC 
AFAIR it is by design. Your TGT is removed if you close last login session to the box. The ticket would stay there if you have at least one login session running. 
What is the use case you are trying to address?
There have been some security related improvements (like this) in RHEL 7. For example if you are interested in running long jobs while you are not logged in the way to do it is by utilizing GSS-proxy.

Thanks
Dmitri
Comment 4 adam winberg 2015-08-26 05:40:03 UTC 
Well, there's no real use case, I just stumbled upon it and thought it was a bug. 

Regarding your statement, "The ticket would stay there if you have at least one login session running", this does not seem to be true. 

Reproducable for me:
1. Log in via ssh to box A (automatically getting TGT via sssd)
2. ssh to box A from above session.
3. exit ssh session from step 2. 
4. Now you're back in the ssh session from step 1, but with no TGT.
Comment 5 Dmitri Pal 2015-08-31 11:43:18 UTC 
(In reply to adam winberg from comment #4)
> Well, there's no real use case, I just stumbled upon it and thought it was a
> bug. 
> 
> Regarding your statement, "The ticket would stay there if you have at least
> one login session running", this does not seem to be true. 
> 
> Reproducable for me:
> 1. Log in via ssh to box A (automatically getting TGT via sssd)
> 2. ssh to box A from above session.
> 3. exit ssh session from step 2. 
> 4. Now you're back in the ssh session from step 1, but with no TGT.

If this is the case it might be a bug.
We will take a look.
Comment 6 Stephen Gallagher 2015-08-31 12:52:14 UTC 
If I remember correctly, the decision to remove the TGT happens inside the kernel in the keyring code (if the kernel determines that the last real session is gone, it gets deleted). CCing David Howells.
Comment 8 John Hodrien 2016-04-07 12:00:34 UTC 
Do you perhaps have this in your sshd config?

GSSAPICleanupCredentials yes

We definitely saw a change from RHEL6 to RHEL7 with this using what I believe to be default configs.

Config using GSSAPI auth with delegation.

On 6, you get a unique ticket cache per connection, and this works just fine.
On 7, with krb5.conf default of:

default_ccache_name = KEYRING:persistent:%{uid}

klist shows that you get the same on cache each connection:

KEYRING:persistent:%{uid}:%{uid}

Then a logout on any connection causes it to be destroyed by OpenSSH and you're left with no credential.
Comment 10 adam winberg 2018-03-28 05:59:24 UTC 
Not sure what the needinfo is for, but I can confirm that we did have 

GSSAPICleanupCredentials yes

in our sshd config. We have since then set this to 'no' and no longer see this behaviour.
Comment 11 Dave Wysochanski 2018-03-28 08:43:37 UTC 
(In reply to adam winberg from comment #10)
> Not sure what the needinfo is for, but I can confirm that we did have 
> 
> GSSAPICleanupCredentials yes
> 
> in our sshd config. We have since then set this to 'no' and no longer see
> this behaviour.

Yes that was why the needinfo since my read was John's question was addressed to you.  Thanks for confirming.

Ok so I am not sure if there is any bug here or not.  Do you think there is still a bug?  You mentioned there is this difference in the opening statement:
> This is only reproducible using the default KEYRING:persistent default ccache name. Using DIR och FILE i cannot reproduce this. 

Or possibly this is "working as designed" but there is just a documentation issue due to differences in RHEL6 and RHEL7 described in comment #3 and comment #8?
Comment 12 adam winberg 2018-03-28 09:06:34 UTC 
I can't answer to whether this is working as designed or not, but it's a change in default behaviour since the default keyring target in RHEL7 changed to the kernel keyring and should at least be documented.

That said, when I test now I can't back up my statement that it works differently using FILE or DIR for credential storage - I get the same behaviour regardless. So at least it's consistent!   :)

Since GSSAPICleanupCredentials by default is set to 'no' and the kernel keyring code handles cleanup, thats ok with me and you can close this.
Comment 13 John Hodrien 2018-03-28 09:12:07 UTC 
I'd agree with that.  As long as GSSAPICleanupCredentials is set to no, this is all working as designed, and better than it did in RHEL6.  As soon as it's set to yes, the behaviour is worse than in RHEL7.

/Possibly/ there's an argument for documentation to warn you of this interaction.
Comment 15 Dave Wysochanski 2020-07-16 16:25:08 UTC 
Closing this BZ as the SF Case(s) is/are closed and we are in Maintenance Support 1 Phase which means we need to focus on more critical BZs. Please re-open if new SF cases are attached and the issue is critical for the customer and meets Maintenance Support 1 Phase criteria: https://access.redhat.com/support/policy/updates/errata/#Maintenance_Support_1_Phase
Comment 16 Red Hat Bugzilla 2023-09-14 03:04:11 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days
Note You need to log in before you can comment on or make changes to this bug.