Editar:
Como o login com uma senha não ajudou você (nos comentários), talvez seja necessário ajustar também as configurações de /etc/krb5.conf . Você precisa fazer com que isso funcione com logins interativos antes de passar para a solução de problemas de logins GSSAPI.
[libdefaults]
default_realm = EXAMPLE.COM
# The following krb5.conf variables are only for MIT Kerberos.
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
A resposta original segue.
The issue is I want to be able to generate a Kerberos ticket upon logging in, or at least so I don't have to enter my password in, at all. I used GSSAPI auth to get to localhost, so I got in with a kerberos ticket. Can I pass that one along, perhaps?
Eu suspeito que este é o seu problema, na verdade. Quando você autentica em sshd com GSSAPI (ou qualquer outra forma de autenticação baseada em chave), você está ignorando completamente a pilha auth . Isso evita que os módulos PAM solicitem qualquer forma de credencial interativa, mas também evita que os "recursos de conveniência" que o seu módulo implementou na pilha sejam disparados. Um teste rápido seria fazer o login com sua senha e executar klist , o que eu suspeito strongmente que mostrará o resultado que você esperava.
A implementação pam_krb5 com a qual tenho mais experiência é aquela hospedada por eyrie.org ( Russ Allbery) , então vou usá-lo como um ponto de comparação com a documentação que você vinculou. Você pode encontrar a manpage que estou citando aqui .
Ambos os módulos implementam pam_setcred() na pilha auth :
- FreeBSD:
The Kerberos 5 authentication component provides functions to verify the identity of a user (pam_sm_authenticate()) and to set user specific credentials (pam_sm_setcred()).
- eyrie.org:
Provides implementations of pam_authenticate() and pam_setcred(). The former takes the username from the PAM session, prompts for the user's password (unless configured to use an already-entered password), and then performs a Kerberos initial authentication, storing the obtained credentials (if successful) in a temporary ticket cache. The latter, depending on the flags it is called with, either takes the contents of the temporary ticket cache and writes it out to a persistent ticket cache owned by the user or uses the temporary ticket cache to refresh an existing user ticket cache.
Nenhum módulo implementa pam_setcred() na pilha account :
- FreeBSD:
The Kerberos 5 account management component provides a function to perform account management, pam_sm_acct_mgmt(). The function verifies that the authenticated principal is allowed to login to the local user account by calling krb5_kuserok() (which checks the user's .k5login file).
- eyrie.org:
Provides an implementation of pam_acct_mgmt(). All it does is do the same authorization check as performed by the pam_authenticate() implementation described above.
O módulo Russ Allbery implementa pam_setcred() na pilha session . O módulo FreeBSD faz nada quando chamado pela pilha session .
- FreeBSD:
The Kerberos 5 session management component provides functions to initiate (pam_sm_open_session()) and terminate (pam_sm_close_session()) sessions. Since session management is not defined under Kerberos 5, both of these functions simply return success. They are provided only because of the naming conventions for PAM modules.
- eyrie.org:
Provides implementations of pam_open_session(), which is equivalent to calling pam_setcred() with the PAM_ESTABLISH_CRED flag, and pam_close_session(), which destroys the ticket cache created by pam_setcred().
Em suma, você precisa de um módulo PAM que forneça a funcionalidade desejada nas pilhas account ou session . Parece que o seu atual não atenderá a essa necessidade quando você se autenticar via GSSAPI.