Alexey, if you look in /etc/ssh/sshd_config, there's numerous directives concerning GSSAPI auth.
# GSSAPI options GSSAPIAuthentication yes GSSAPICleanupCredentials yes #GSSAPIStrictAcceptorCheck yes #GSSAPIKeyExchange no #GSSAPIEnablek5users no So sshd knows natively about GSSAPI auth. Don't think it's using any PAM stack for GSSAPI (auth phase). Surely using PAM stack for account and session phases however. Spike On Wed, Feb 26, 2025 at 10:30 AM Alexey Tikhonov <[email protected]> wrote: > Hi, > > On Wed, Feb 26, 2025 at 5:07 PM Spike White via sssd-users > <[email protected]> wrote: > > > > We notice that when sssd-kcm service is messed up and not running, > password auth fails. Interestingly, Kerberos (GSSAPI auth still succeeds. > Why? > > > > So I know why password auth fails. In > /etc/krb5.conf.d/kcm_default_cache, it has: > > > > [libdefaults] > > default_ccache_name = KCM: > > > > So in password auth, it is failing on the step of writing the Kerberos > credential cache into the credentials store (KCM). I speculate that it’s > specifically pam_sss.so in the auth phase that’s failing to do this. > > 'krb5_child' (invoked by 'sssd_be' by request from 'sssd_pam' by > request from 'pam_sss.so') fails to store TGT. > > > > I understand why password auth fails. My question is – why does > Kerberos (GSSAPI) auth succeed? > > > > My guess is that sshd handles GSSAPI auth internally and never calls the > PAM stack in the “auth” phase. Only for the “account” and “session” > phase. Thus pam_sss.so never gets invoked for the auth phase. > > I don't know if sshd uses 'pam_sss_gss.so', but that way or another, I > guess there is no need to acquire and store TGT on user behalf. > >
-- _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
