Bug 1256610 - Kerberos tgt removed when logging out ssh session from local machine [NEEDINFO]
Kerberos tgt removed when logging out ssh session from local machine
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: keyutils (Show other bugs)
7.1
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: David Howells
BaseOS QE Security Team
:
Depends On:
Blocks: 1298243 1420851
  Show dependency treegraph
 
Reported: 2015-08-25 02:36 EDT by adam winberg
Modified: 2017-08-02 02:45 EDT (History)
6 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description adam winberg 2015-08-25 02:36:50 EDT
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 09:09:31 EDT
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 11:08:07 EDT
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 01:40:03 EDT
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 07:43:18 EDT
(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 08:52:14 EDT
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 08:00:34 EDT
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.

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