rpkg

#496 rpkg should attempt kerberos auth without checking Kerberos ticket cache
Opened by ktdreyer. Modified

Open
Close Issue

When a user attempts GSSAPI authentication to a service (for example, with requests-kerberos), and the user does not have a TGT, MIT kerberos will automatically obtain a TGT for the service's realm if the user stores a keytab in a default location on disk.

This already works with the koji CLI. I can store a "kdreyer" keytab at the special location on disk:

$ klist -kt /var/kerberos/krb5/user/1000/client.keytab 
Keytab name: FILE:/var/kerberos/krb5/user/1000/client.keytab
KVNO Timestamp           Principal
---- ------------------- -----------------------------------------------
 1 04/24/2015 07:48:15 kdreyer@EXAMPLE.COM

And then destroy all my credentials:

$ kdestroy -A

And then authenticate

$ koji -p example hello
yo, kdreyer!
You are using the hub at https://koji.example.com/kojihub
Authenticated via GSSAPI

My ticket cache shows that krb5-libs automatically obtained the ticket for me
(no "kinit" necessary):

$ klist
Ticket cache: KCM:1000:15483
Default principal: kdreyer@EXAMPLE.COM
Valid starting       Expires              Service principal
04/14/2020 10:56:26  04/14/2020 20:56:26  krbtgt/EXAMPLE.COM@EXAMPLE.COM
04/14/2020 10:56:27  04/14/2020 20:56:26  HTTP/koji.example.com@EXAMPLE.COM

Unfortunately rpkg has some checks built in so that it will not allow this
behavior.

Would you please consider removing the code that tests for an existing kerberos
cache? It would be more elegant to attempt a Kerberos login with Koji, even if there is no TGT cached, and then only raise if that fails.

Removing this code would make rpkg simpler and easier to maintain.

A blog post by @admiyo that explains more about this feature of Kerberos: https://adam.younglogic.com/2015/05/auto-kerberos-authn/

So far I wasn't able to create keytab via ipa-getkeytab. But it worked with ktutil.
Before I start coding (on a critical function where I can do some mistake), I would like to suggest steps that I took. But maybe you already tried it (and it has possibly some cons):
Edit '/etc/koji.conf' and edit values

  • principal ('krb_principal' probably doesn't work)
  • keytab

After the modification (and destroying my session), koji hello showed me authenticated.

Looks the mechanism internally uses some cache (which I can't disable so far), because when I deleted these values from config, koji hello stil works.
Edited by onosek

There are a couple of things going on in the test you described.

  • MIT Kerberos itself will use a client keytab file at /var/kerberos/krb5/user/$EUID/client.keytab to obtain a TGT automatically. This means that if you take Koji out of the picture entirely, Python's requests-kerberos (via krb5-libs) will load your keytab at that filesystem path to get a TGT. You do not need to edit /etc/koji.conf at all to get this behavior. man krb5.conf describes the default_client_keytab_name setting. That is what controls this.

  • Koji does respect the keytab setting from /etc/koji.conf (or the other profile conf locations). If you set a keytab here, Koji will try to authenticate with that particular keytab (rather than using MIT Kerberos' default_client_keytab_name behavior.)

  • Koji (via requests-kerberos) chooses a principal according to the existing kerberos caches, so you probably do not need to set principal explicitly in your koji conf.

Lastly, you mentioned that you see koji hello authenticate you even when you do not set keytab in /etc/koji.conf. Can you please verify:

  1. You've destroyed every cache, not just one (using the "-A" flag to kdestroy -A)
  2. You have no other keytab settings in the other profile conf locations on your computer

If those two conditions are true, then you should see the following behavior:

  • koji hello automatically obtains a new TGT when you put your keytab at /var/kerberos/krb5/user/$EUID/client.keytab

  • koji hello fails to authenticate when there is no keytab at /var/kerberos/krb5/user/$EUID/client.keytab and no existing kerberos cache.

@bpeck I noticed your Jenkins jobs would benefit from this change as well. You're running "kinit" before "fedpkg" in this job (for example)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.