GSSAPI Key Exchange on multi-homed host - openssh

This is a discussion on GSSAPI Key Exchange on multi-homed host - openssh ; >From a security standpoint, if the default keytab (/etc/krb5.keytab) contains only ONE principal, does it matter if GSSAPIStrictAcceptorCheck is set to "yes" or "no"? My company uses an internally built OpenSSH package that includes the GSSAPI Key Exchange patch. Because ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: GSSAPI Key Exchange on multi-homed host

  1. GSSAPI Key Exchange on multi-homed host

    >From a security standpoint, if the default keytab (/etc/krb5.keytab)
    contains only ONE principal, does it matter if GSSAPIStrictAcceptorCheck
    is set to "yes" or "no"?

    My company uses an internally built OpenSSH package that includes the
    GSSAPI Key Exchange patch. Because we have 1000s of hosts, we need to use
    a "standard" sshd_config file that works for the majority of hosts.
    Unfortunately, the current "standard" sshd_config does not set the
    GSSAPIStrictAcceptorCheck entry, which defaults to "yes" and therefore
    does not work correctly on the multi-homed hosts.

    I'd like to change our standard sshd_config so GSSAPIStrictAcceptorCheck
    defaults to "no", but before doing so, I want to better understand the
    implications.

    As I understand the GSSAPIStrictAcceptorCheck flag, setting it to "no",
    simply enables matches against more then the 1st principal in
    /etc/krb5.keytab. So... if there's only one principal in the keytab, it
    seems like it wouldn't matter if GSSAPIStrictAcceptorCheck is set to yes
    or no. Is that correct?
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  2. Re: GSSAPI Key Exchange on multi-homed host

    On Mon, 13 Oct 2008, petesea@bigfoot.com wrote:

    > >From a security standpoint, if the default keytab (/etc/krb5.keytab)

    > contains only ONE principal, does it matter if GSSAPIStrictAcceptorCheck
    > is set to "yes" or "no"?
    >
    > My company uses an internally built OpenSSH package that includes the
    > GSSAPI Key Exchange patch. Because we have 1000s of hosts, we need to use
    > a "standard" sshd_config file that works for the majority of hosts.
    > Unfortunately, the current "standard" sshd_config does not set the
    > GSSAPIStrictAcceptorCheck entry, which defaults to "yes" and therefore
    > does not work correctly on the multi-homed hosts.


    OpenSSH doesn't support a GSSAPIStrictAcceptorCheck at all. There is a
    patch in our bugzilla to add it, and I'd like to review and merge is soon
    but it has never been in any version that we have released.

    -d
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  3. Re: GSSAPI Key Exchange on multi-homed host

    On Tue, 14 Oct 2008, Damien Miller wrote:

    > On Mon, 13 Oct 2008, petesea@bigfoot.com wrote:
    >
    >>> From a security standpoint, if the default keytab (/etc/krb5.keytab)

    >> contains only ONE principal, does it matter if GSSAPIStrictAcceptorCheck
    >> is set to "yes" or "no"?
    >>
    >> My company uses an internally built OpenSSH package that includes the
    >> GSSAPI Key Exchange patch. Because we have 1000s of hosts, we need to
    >> use a "standard" sshd_config file that works for the majority of hosts.
    >> Unfortunately, the current "standard" sshd_config does not set the
    >> GSSAPIStrictAcceptorCheck entry, which defaults to "yes" and therefore
    >> does not work correctly on the multi-homed hosts.

    >
    > OpenSSH doesn't support a GSSAPIStrictAcceptorCheck at all. There is a
    > patch in our bugzilla to add it, and I'd like to review and merge is
    > soon but it has never been in any version that we have released.


    The GSSAPIStrictAcceptorCheck keyword is included as part of Simon
    Wilkinson's GSSAPI Key Exchange patch, which we use. Sorry if that wasn't
    clearer in my first message.
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


+ Reply to Thread