Bug 3203 - Could default_ccache_name from krb5.conf be used for GSSAPI connections?
Summary: Could default_ccache_name from krb5.conf be used for GSSAPI connections?
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: Kerberos support (show other bugs)
Version: 8.3p1
Hardware: ix86 Linux
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-26 21:34 AEST by Toby Blake
Modified: 2022-12-29 00:56 AEDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Toby Blake 2020-08-26 21:34:54 AEST
Hi there,

I'm filing this bug upstream as suggested in this ubuntu bug report:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1889548

I'll recreate my original text from that ticket here:

"
ssh connections from a client with the following in ssh_config...

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

... to an ubuntu 20.04 machine result in KRB5CCNAME being set to 'FILE:/tmp/krb5cc_[uid]_[random]' despite the following in /etc/krb5.conf:

[libdefaults]
 ...
 default_ccache_name = KEYRING:persistent:%{uid}

This means that we cannot enforce a policy to use KEYRING ccaches across our systems. Authentications which go via the pam stack (e.g. login to the machine at the console or over ssh using a password) can be configured to use a KEYRING ccache, via libpam-krb5 settings in /etc/krb5.conf.

The FILE: setting seems to be hard-coded in the openssh code (auth-krb5.c). It would be great if ssh(gssapi-with-mic) connections either (a) set KRB5CCNAME to the default_ccache_name value, if set in /etc/krb5.conf, or (b) didn't set KRB5CCNAME at all, so the system default is used.
"

Redhat already patch for this, but they patch the upstream source quite heavily (as do ubuntu, but in different ways).

I'm hoping to spend more time on getting a patch to do this on ubuntu, but I suspect that wouldn't be of much use upstream.

Would there be interest in implementing this functionality upstream?

Thanks
Toby Blake
School of Informatics
University of Edinburgh
Comment 1 Jakub Jelen 2020-08-27 19:28:53 AEST
We use several patches to do that in RHEL/Fedora and this was already proposed in bug #2775, but without any feedback from OpenSSH developers.

Feel free to use the patches we use (might need updating from version posted in the bug). But note that there is still many people interested in using per-session caches.
Comment 2 Toby Blake 2020-08-27 19:37:41 AEST
(In reply to Jakub Jelen from comment #1)
> We use several patches to do that in RHEL/Fedora and this was
> already proposed in bug #2775, but without any feedback from OpenSSH
> developers.
> 
> Feel free to use the patches we use (might need updating from
> version posted in the bug). But note that there is still many people
> interested in using per-session caches.

Hi Jakub,

Thanks for the reply.  I've tried a (slightly reworked to get it to apply) version of openssh-7.7p1-gssapi-new-unique.patch but it doesn't seem to quite do what I want it to do, specifically it always gives me a new unique ccache, rather than using e.g. KEYRING:persistent:%{uid}.  It may be that in reworking it I've messed it up somewhat so I need to find some time to look at it in more detail.

Cheers
Toby
Comment 3 Jakub Jelen 2020-08-27 20:00:50 AEST
Hi,
the current version we use in Fedora lives here so it could have gone through some updates and fixes since 2 years ago:

https://src.fedoraproject.org/rpms/openssh/blob/master/f/openssh-7.7p1-gssapi-new-unique.patch

The new unique cache in the given collection is probably the most sensible way of doing this. Or you suggest that you would like the new login to override existing tickets in the ccache? Or you still see the ccache in /tmp being used? What configuration did you try?
Comment 4 Toby Blake 2020-08-27 20:55:31 AEST
(In reply to Jakub Jelen from comment #3)
> Hi,
> the current version we use in Fedora lives here so it could have
> gone through some updates and fixes since 2 years ago:
> 
> https://src.fedoraproject.org/rpms/openssh/blob/master/f/openssh-7.
> 7p1-gssapi-new-unique.patch

Hi, this is the patch I've tried to rework for ubuntu.

> The new unique cache in the given collection is probably the most
> sensible way of doing this. Or you suggest that you would like the
> new login to override existing tickets in the ccache? Or you still
> see the ccache in /tmp being used? What configuration did you try?

What I'd like is to be able to set 

[libdefaults]
default_ccache_name = KEYRING:persistent:%{uid}

... in /etc/krb5.conf and for (gssapi) ssh connections to use this, in the same way that I can set it for PAM connections.

This no doubt works under redhat (and indeed it works for us with Scientific Linux 7.8 with the addition of a backported openssh-7.5p1-gss-environment.patch, as discussed in https://bugzilla.redhat.com/show_bug.cgi?id=1199363)

I think I need to look at the gssapi-new-unique patch again, with a more complete understanding of the relevant code areas.  My reworking of it is definitely not doing what it should do.

The biggest issue in getting this working is the divergent code bases between redhat and ubuntu (in particular, I suspect, the gsskex patch).  This is why I'd much prefer this issue to be fixed upstream.

Pending that, I'll look again at the the unique patch.

Cheers
Toby
Comment 5 Lars-Dominik Braun 2021-05-28 19:04:01 AEST
Has there been any progress?

We’d also be interested in this feature. Our setup includes SSSD, which provides a KCM: backend for ticket storage, but SSH keeps falling back to KRB5CCNAME=FILE: when using an existing ticket to login.

Working around the issue is quite simple (because no pattern expansion is needed) using pam_env and an entry in /etc/environment, which overrides SSH’s default. Still, it’d be better if SSH respected krb5.conf in the first place.
Comment 6 Pat Riehecky 2022-09-22 01:40:01 AEST
Echoing interest in this.