2

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
3
  • Kerberos has 'forwardable' tickets, but I don't know how to force it to give you one when you log in, and I'm not sure it's a good practice anyway. Does this SSH login have to be Kerberos? Or can it be a certificate login. You can certainly set up public key authentication, even without a password.
    – Jeter-work
    Aug 18, 2016 at 20:44
  • How do you log into the first host? You say you used GSSAPI. It sounds like you forgot to delegate.
    – 84104
    Aug 19, 2016 at 6:41
  • @84104, I coming from Windows 7 AD-joined using putty 0.62 with settings: Connection->SSH->Auth->GSSAPI option "Allow GSSAPI credential delegation" enabled. It shows the Accepted gssapi-with-mic line.
    – bgStack15
    Aug 19, 2016 at 13:36

2 Answers 2

0

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.

1
  • I think this is the correct answer. According to community.centrify.com/t5/Centrify-Express/…, I need to make my FreeBSD system in AD "trusted for delegation" but my access does not allow that. I guess PuTTY on Windows needs that setting, so what I want is impossible. Going from a FreeBSD host where I have a Kerberos ticket to another FreeBSD host works fine, with the ssh -K secondhost command.
    – bgStack15
    Aug 19, 2016 at 18:03
3

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.

5
  • Logging in with my pw does not generate a kerberos ticket. I installed security/pam_krb5 from the ports directory (eyrie kerberos) and still is not generating a ticket or even letting me log in! I get in openpam_dispatch(): calling pam_sm_setcred() in /usr/local/lib/security/pam_krb5.so and then kernel: pid 39498 (sshd), uid 0: exited on signal 11 in the various logs.
    – bgStack15
    Aug 19, 2016 at 14:48
  • Seeing an empty klist when using a password does suggest the presence of another problem, as you've surmised. Without having a FreeBSD VM handy, all I can tell you off-handedly is that I see the TGT when I type klist after authenticating, I use the module from eyrie, and my system has a valid "host" key in /etc/krb5.keytab. I'll post my [libdefaults] section from /etc/krb5.conf, but with there being an accepted answer I'm probably not going to research this further.
    – Andrew B
    Aug 19, 2016 at 18:23
  • So my pam still isn't configured right? If unaccepting the other answer will encourage you to continue explaining pam/ssh/GSSAPI, I'll do it.
    – bgStack15
    Aug 19, 2016 at 19:05
  • I assumed the accept meant you had lost further interest, so feel free to re-accept it for now. When you log in, you shouldn't have to invoke kinit if everything is set up correctly. Double check the output of klist -k /etc/krb5.keytab and make sure you generated a key for the host, and make sure only root can read that file. (it's been awhile, can't remember if you can run kinit manually without host key, but it will definitely cause other problems)
    – Andrew B
    Aug 19, 2016 at 21:01
  • If I use auth sufficient /usr/local/lib/pam_sss.so use_first_pass instead of pam_krb5.so, I can log in with password and it generates me a tgt. If I use the GSSAPI auth, it won't (probably because of @84101's answer). If I use pam_krb5 from pam_krb5-rh package as my auth sufficient, it generates on pw, but not GSSAPI. The pam_krb5(eyrie) just crashes, period.
    – bgStack15
    Aug 22, 2016 at 13:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .