It's the end of 2018 and I've run into the same question as you. After some digging, I can offer a write-up for posteriority.
tl; dr:
- "Infinite renewal" not possible and probably never will be
- SSSD will renew tickets if you log in using passwords
- SSSD will renew all tickets, at some point in the future
First off, you can't have "indefinitely". Kerberos tickets have a maximum renewable lifetime which is a KDC server setting, and nothing will let you renew one ticket past this time. The only thing you could do is store the users credentials and request a fresh new ticket on their behalf.
That being said, you shouldn't have to. Chances are that you are running the "System Security Services Daemon", or SSSD. If you do, you can use the builtin renewal options krb5_renew_interval and krb5_renewable_lifetime to renew users tickets automatically:
[domain/yourdomain.example.com]
krb5_renewable_lifetime = 90d
krb5_renew_interval = 500
You can look into man 5 sssd-krb5 for details. With these settings SSSD will ask for renewable tickets (maximum lifetime 90 days) whenever you log in* and every 500 seconds go through a list of tickets* and renew the existing tickets that are renewable.
After 90 days have passed since the original ticket, the renewal will fail and the ticket is lost. However, if you log in* in the mean time, you will get a fresh ticket from SSSD - even when you enter your password into your machines lock screen.
*) So far, so wonderful. Unfortunately, a few gotchas apply.
At the time when I am writing this, SSSD can only renew tickets that it itself requested. These are all the logins that go through the pam_sss PAM module, for example (but not limited to):
- Typing
su $USER on your terminal
- Logging in to your system through a graphical shell
- Unlocking the screen through a graphical shell
- Logging in through SSH using the
PasswordAuthentication method.
Now what is notably missing from this list is:
- Running
kinit
- Logging in through SSH using the
PubkeyAuthentication method.
- Logging in through SSH using the
GSSAPIAuthentication method.
- Logging in through SSH, while the
GSSAPIDelegateCredentials option is on.
Now that makes things quite awkward, and for the time being it essentially means that eitheryou force users to enter a password or that you write a ticket renewal daemon yourself. I have not found another way to make this work in the present, please anybody comment if you found a way.
This might become quite a bit easier, however.
SSSD now provides a "kerberos cache manager", a KCM that's called sssd-kcm. Basically, it's a small server that will store tickets there (KCM: when you run klist) instead of the Kernel keyring (KEYRING: when you run klist) or a file in /tmp (FILE: when you run klist).
At some point in the future, SSSD will hopefully be able to renew all tickets (not just the ones it requested itself) when sssd-kcm implements ticket renewal. This has not happened yet, and is tracked in issue 1723 on the SSSD bug tracker.
If you're running a Red Hat based system (RHEL, CentOS, Fedora), then SSHD also needs to learn to respect the selected cache creation mechanism. This is tracked in issue 1639376 on the Red Hat bugtracker.
