Can ssh generate a kerberos ticket? (FreeBSD)

Question

TL;DR

I want to be able to ssh from a FreeBSD host to a FreeBSD host, using my kerberos ticket generated when I first logged in.

Question

Environment

FreeBSD 10.3 with working openldap-sasl-client, kerberos 5 (not heimdal), sssd, ssh, and joined to Active Directory (2008 R2). I had to compile sssd from the /usr/ports source location because by default sssd-ad is not included which I need. I'm not using winbind, so reference 1 is not helpful. (Nor does FreeBSD have an authconfig command, apparently.) I can perform a kinit just fine:

[bgstack15@localhost /]$ kinit [email protected]'s Password: [bgstack15@localhost /]$ klist Credentials cache: FILE:/tmp/krb5cc_5532829429 Principal: [email protected] Issued Expires Principal Aug 18 16:01:16 2016 Aug 19 02:01:16 2016 krbtgt/[email protected] 

After that I can ssh -K secondhost and it takes me right there.

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?

What I've already tried

Here's my /etc/pam.d/sshd

auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local auth sufficient pam_unix.so no_warn auth sufficient pam_krb5.so no_warn use_first_pass forwardable ccache=krb5cc_%u auth required pam_unix.so no_warn try_first_pass account required pam_nologin.so account required pam_login_access.so account sufficient /usr/local/lib/pam_sss.so ignore_unknown_user account required pam_unix.so session optional /usr/local/lib/pam_sss.so session required /usr/local/lib/pam_mkhomedir.so mode=0700 session required pam_permit.so password sufficient /usr/local/lib/pam_sss.so use_authtok password sufficient pam_krb5.so use_authtok forwardable password required pam_unix.so no_warn try_first_pass 

I also tried
auth sufficient pam_krb5.so no_warn try_first_pass forwardable ccache=krb5cc_%u

There is an option to just run kinit in the .profile, but I'm trying to avoid entering the password.

Is using pam_exec.so an option? I can do echo PASSWORD | kinit --password-file=STDIN which works, so can I call this somehow?

References

1. Similar to this guy, but on FreeBSD 10.3 Initialise Kerberos ticket on ssh login using PAM
2. man pam_krb5.so https://www.freebsd.org/cgi/man.cgi?query=pam_krb5&sektion=8
3. Similar, but does not get around the no-password issue Get Kerberos ticket with SSH
4. http://web.archive.org/web/20150315074946/http://howtovmlinux.com/articles/infrastructure-management/red-hat-idm/automate-kinit-kerberos-ticket-during-ssh-login.html

Answer 1

It seems that your ssh client (PuTTY) isn't delegating credentials. No amount of pam trickery is going to get around this without causing you to retype your password, which would rather defeat the point.

I can't seem to make putty 0.67 delegate, even with the likely option checked. The accept line you are referring to looks like logging from sshd of the authentication, not delegation. By default sshd doesn't log delegation. Looking at the SSH packet log, putty 0.67 it doesn't even seem to make the attempt.

Answer 2

Edit:

Given that logging in with a password did not help you (in the comments), you may need to tweak your /etc/krb5.conf settings as well. You need to get this working with interactive logins before you move on to troubleshooting GSSAPI logins.

[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 

Original answer follows.

---

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?

I suspect this is your problem, actually. When you authenticate to sshd with GSSAPI (or any other form of key-based authentication), you're bypassing the auth stack completely. This prevents PAM modules from prompting you for any form of interactive credential, but it also prevents any "convenience features" that your module implemented in that stack from firing. A quick test would be to log in with your password and run klist, which I strongly suspect will show you the result you were expecting.

The pam_krb5 implementation that I have the most experience with is the one hosted by eyrie.org (Russ Allbery), so I'm going to use it as a point of comparison with the documentation you've linked to. You can find the manpage I'm citing here.

Both modules implement pam_setcred() in the auth stack:

• 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.

Neither module implements pam_setcred() in the account stack:

• 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.

The Russ Allbery module implements pam_setcred() in the session stack. The FreeBSD module does nothing when called by the session stack.

• 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().

---

In short, you need a PAM module which is going to provide the desired functionality in the account or session stacks. It looks like your current one is not going to meet this need when you authenticate via GSSAPI.