• SSH and The requires_pre_auth attribute

    From Russ Allbery@21:1/5 to Dan Mahoney (Gushi) on Mon Nov 23 13:51:46 2020
    Copy: kerberos@mit.edu

    "Dan Mahoney (Gushi)" <danm@prime.gushi.org> writes:

    1) Is my "if it's on the host entry, it must be on the user entry"
    basically accurate?


    Therefore, because of this, unless you are *certain* that every principal
    that needs to authenticate to another principal will have requires
    pre-auth set, you should not set requires pre-auth on server principals.

    There is in general no strong reason to set requires pre-auth on randomly-generated keys unless you want to force exactly this client
    behavior. Yes, not having it set means that in theory an attacker can try
    to brute-force the randomly-generated key, but... it's randomly generated.
    So if there is any realistic chance of success in this, you have much
    larger problems.

    (I don't have off-the-cuff answers to your other questions.)

    Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Mahoney (Gushi)@21:1/5 to All on Mon Nov 23 13:41:37 2020
    Hey all.

    At the day job, we found that a user was able to log in to one system, but
    not another -- and the difference was that everyone who *could* log in had
    the requires_preauth attribute set on their principal, and newuser@DOM.AIN didn't. This was with password, not GSSAPI authentication (KerberosAuthentication yes; UsePAM no)

    Both hosts were FreeBSD, running 11.4-RELEASE-patchlevelwhatever with the default sshd. Nearly identical sshd_configs. Both had all the right DNS.

    Having figured that out, we went down the rabbit hole of figuring out what
    was different about the hosts: One of the *hosts* kerberos entries, (the
    one they couldn't log into), also had REQUIRES_PRE_AUTH set.

    Now, I've only loosely understood what REQUIRES_PRE_AUTH does. It's an
    offline attack prevention thing. Reading the O'Reilly Kerberos bit made
    it a bit clearer, and this page made it quite clear:


    None of those docs were on the MIT website.

    This (confusing) page is the only mention I could find in the first page
    of google results on the mit website for "Kerberos Preauth":


    And nowhere (except on a mailing list post I just found after solving the problem) does it say that if you set it on a host, you *must* set it on a
    user. Nothing mentions ssh. That could all be made clearer.


    I'm posting this so that hopefully someone in the future will find this.

    Now, my questions for y'all:

    1) Is my "if it's on the host entry, it must be on the user entry"
    basically accurate?

    2) Preauth is a good thing. We need to go through and set
    requires_pre_auth for every host/foo@DOM.AIM entry and user@DOM.AIN entry
    on our kdc. I can't find a way to list all princs that have (or don't
    have) a given attribute. Is there a way?

    3) Is there a way to mass set these attributes?

    4) Is there a way to make these attributes *the default* when adding a new princ? I can define a policy, but not an attribute-set for that policy.




    --------Dan Mahoney--------
    Techie, Sysadmin, WebGeek
    Gushi on efnet/undernet IRC
    FB: fb.com/DanielMahoneyIV
    LI: linkedin.com/in/gushi
    Site: http://www.gushi.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)