Description of problem:
With the default settings of "GSSAPIAuthentication yes" and "GSSAPICleanupCredentials no" in /etc/ssh/sshd_config, credentials delegated via "GSSAPIDelegateCredentials yes" from the SSH client are never cleaned up.  This eventually results in sssd_kcm rejecting logins when the maximum number of secrets is reached for the user.  This in turn results in the user being unable to log in with domain credentials (e.g. to GDM).

Version-Release number of selected component (if applicable):
openssh-8.0p1-10.el8.x86_64
sssd-kcm-2.5.2-2.el8_5.4.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Join machine to a domain and set up GSSAPI authentication for SSH, with KCM enabled
2. From a host with a valid TGT, do 
    for run in {1..66}; do ssh -K myhost /bin/true; done
3. Observe that "klist -A" on the target lists dozens of ticket caches created by these sessions
4. Attempt to log into GDM using the domain credentials on the target host.

Actual results:
GDM login fails; sssd_kcm.log reports "[kcm] [local_db_check_peruid_number_of_secrets] (0x0040): Cannot store any more secrets for this client (basedn cn=NNN,cn=persistent,cn=kcm) as the maximum allowed limit (66) has been reached", and /var/log secure reports "[gdm-password][nnnnnnn]: pam_sss(gdm-password:auth): received for user myuser: 4 (System error)".

Expected results:
User should be able to log in.

Additional info:
When this occurs for a user, "kdestroy -A" can be used to destroy the credentials caches to allow that user to log in again.

The default of "no" of GSSAPICleanupCredentials was a deliberate decision based on Bug 1055016, and was described as a "reasonable workaround" (which is why I've filed this as an openssh bug rather than an sssd-kcm bug); I don't know whether this measure is still needed, but eight years later, one hopes that a better solution might be available.

If changing the default for GSSAPICleanupCredentials back to "yes" is not practical, there are several ways this issue could be mitigated, including:

- raising the maximum number of allowed secrets per user in sssd_kcm to a limit greater than 66 (although this merely delays the inevitable and may have performance implications);

- upon reaching the maximum (or just periodically), deleting tickets that have already expired; or, replacing the oldest secret when the maximum is reached;

- somehow changing the mechanism so that every SSH login with GSSAPIDelegateCredentials=yes does not create a separate credentials cache.

I don't know whether there is a simple way to determine how many secrets sssd_kcm has stored for each user (e.g., to determine whether any users are nearing the limit and at risk for not being able to log in), or if there is an easier method to clear those secrets than running "kdestroy -A" as the affected user, but this information would be helpful in treating the symptom.