Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Steps to Reproduce:
1. Ensure that "GSSAPIAuthentication yes" is enabled in sshd_config and restart sshd if necessary
2. Set up krb5.conf and krb5.keytab for kerberos on the ssh server and the ssh client
2a. On the server, set the ticket cache type to "FILE", eg:
[libdefaults]
default_ccache_name = FILE:/tmp/krb5cc_%{uid}
3. On the ssh client, ensure that GSSAPIAuthentcation and Delegation are on:
Host *
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
4. On the client, kinit
5. On the client, ssh username@server
6. In your server session, type in:
printenv KRB5CCNAME
>
> Actual results:
>
KRB5CCNAME is not set
>
> Expected results:
>
>
KRB5CCNAME is set, eg:
$ printenv KRB5CCNAME
FILE:/tmp/krb5cc_261937
> Additional info:
>
With UsePAM on and doing password authentication, KRB5CCNAME is set (perhaps it is sssd that sets it in this case).
Eg:
]$ ssh dwb7@dimension -o GSSAPIAuthentication=no
dwb7@dimension's password:
Last login: Wed Nov 6 13:59:28 2019 from 128.253.198.20
[dwb7@dimension ~]$ printenv KRB5CCNAME
FILE:/tmp/krb5cc_261937
*Also*
if in sshd_config, one turns on "KerberosUniqueCCache" (off by default), then with GSSAPIAuthentication, KRB5CCNAME is set:
$ ssh dwb7@dimension
Last login: Wed Nov 6 14:00:31 2019 from 128.253.198.20
[dwb7@dimension ~]$ printenv KRB5CCNAME FILE:/tmp/krb5cc_261937_0nQT67TinQ
So, with KerberosUniqueCCache off (the default) and GSSAPIAuthentication, KRB5CCNAME is not set, and it should be.
This is completely intentional. In the past, there were too many problems with setting KRB5CCNAME environment variable so we got down to not setting it if the krb5.conf specifies unique location for a user (as in your example). All the tools using kerberos are able to find the tickets without problems.
If you insist on having the environment variable set, there is the KerberosUniqueCCache configuration option for you as you already found out. If you have some other use case or need for this variable, please clarify that.
Steps to Reproduce: 1. Ensure that "GSSAPIAuthentication yes" is enabled in sshd_config and restart sshd if necessary 2. Set up krb5.conf and krb5.keytab for kerberos on the ssh server and the ssh client 2a. On the server, set the ticket cache type to "FILE", eg: [libdefaults] default_ccache_name = FILE:/tmp/krb5cc_%{uid} 3. On the ssh client, ensure that GSSAPIAuthentcation and Delegation are on: Host * GSSAPIAuthentication yes GSSAPIDelegateCredentials yes 4. On the client, kinit 5. On the client, ssh username@server 6. In your server session, type in: printenv KRB5CCNAME > > Actual results: > KRB5CCNAME is not set > > Expected results: > > KRB5CCNAME is set, eg: $ printenv KRB5CCNAME FILE:/tmp/krb5cc_261937 > Additional info: > With UsePAM on and doing password authentication, KRB5CCNAME is set (perhaps it is sssd that sets it in this case). Eg: ]$ ssh dwb7@dimension -o GSSAPIAuthentication=no dwb7@dimension's password: Last login: Wed Nov 6 13:59:28 2019 from 128.253.198.20 [dwb7@dimension ~]$ printenv KRB5CCNAME FILE:/tmp/krb5cc_261937 *Also* if in sshd_config, one turns on "KerberosUniqueCCache" (off by default), then with GSSAPIAuthentication, KRB5CCNAME is set: $ ssh dwb7@dimension Last login: Wed Nov 6 14:00:31 2019 from 128.253.198.20 [dwb7@dimension ~]$ printenv KRB5CCNAME FILE:/tmp/krb5cc_261937_0nQT67TinQ So, with KerberosUniqueCCache off (the default) and GSSAPIAuthentication, KRB5CCNAME is not set, and it should be.