pam_krb5 fails to establish and keep forwardable kerberos ticket for a keyboard interaction ssh session
It appears that logging in from the local console allows me to establish a kerberos ticket that I can use, but logging in with keyboard interactive SSH doesn't. GSS based login with SSH does, but the method to establish the key here is just a simple forward, so that's somewhat expected. I cranked up PAM's debug flags (in both pam.conf and pam_debug), and managed to come up with a reasonable hypothesis for what's going.
It seems that OpenSSH forks off a child PID, calls pam_get_data on the SUNW-KRB5-AUTH-DATA key, finds that it's absent for the newly created pid, and populates it with the important PAM environment variables (mainly the ticket cache path). The problem seems to occur when a second child process is forked, possibly from a shared parent pid, for the setcred portion of PAM. PAM expects the key SUNW-KRB5-AUTH-DATA to exist and errors out if it doesn't. When logging in from the login service, this key is present every time it's searched. Right after setcred is called when logging in from console, a kerberos ticket is added and a warning about ktktd_warn is established. When done from keyboard-interactive login with SSH, it terminates early (though the pam stack still sees it as successful) with a kmd get failed error.
The relevant pieces of code:
This is where the SUNW-KRB5-AUTH-DATA in pam_krb5 is calloc'd, populated, and environment varibles are later passed in.
This is where that key is queried, and the pam handle's heap backed linked list fails to find the key, causing a kmd get failed error
I've attached the two logs, from console, and from keyboard-interactive sshd. It's important to note that kerberized login (GSS) with sshd works, as does keyboard interactive for authentication. However, establishing the session's kerberos ticket fails (klist comes up empty unless the user had previously established a ticket with kinit or logged into the console).
I'm not sure what the relevant fix is, either that kmd needs to be populated in the parent pid so that post fork, copy-on-write doesn't clone a local version of that list, or pam_krb5's setcred method needs to reestablish this module data in the same way auth does.
The relevant portion
Updated by Adam Stylinski 5 days ago
Some more info I found:
That's how other PAM modules are handling the exact same issue. On Freenode, it was suggested a pamd service could also, to some extent, solve this issue.