Re: Kerberos 5 and DNS aliases - Kerberos

This is a discussion on Re: Kerberos 5 and DNS aliases - Kerberos ; >If so, why does the available name depend on the `hostname` setting without any change in the DNS? Because the server picks the acceptor principal to use for incoming connections by resolving the machine's hostname. You can disable this behaviour, ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: Kerberos 5 and DNS aliases

  1. Re: Kerberos 5 and DNS aliases


    >If so, why does the available name depend on the `hostname` setting without any change in the DNS?


    Because the server picks the acceptor principal to use for incoming connections by resolving the machine's hostname. You can disable this behaviour, and permit any principal[1] whose key is in the default keytab by using a recent version, and setting GSSAPIStrictAcceptorCheck to 'no'


    >Does a ssh client really pass any server name to sshd during GSSAPI negotiation?


    Not directly, but the client must pick a service principal for the server. This is selected using the hostname the client is connecting to, as I described.

    Simon.

    [1] Any principal means anything that has keys in the keytab being used by sshd.. Arguably the code should restrict this to only principals for the 'host' service - but I can't see a way of doing this without breaking the GSSAPI abstraction layer. For now, you just need to be careful what keys you put in the default keytab.




  2. Re: Kerberos 5 and DNS aliases

    Simon Wilkinson wrote:

    > >If so, why does the available name depend on the `hostname` setting
    > >without any change in the DNS?


    > Because the server picks the acceptor principal to use for incoming
    > connections by resolving the machine's hostname. You can disable
    > this behaviour, and permit any principal[1] whose key is in the
    > default keytab by using a recent version, and setting
    > GSSAPIStrictAcceptorCheck to 'no'


    The FreeBSD sshd does not seem to have this option. However, I think I
    have found an alternative solution after reading the Kerberos FAQ.

    I have created for the server a DNS name with multiple A RRs. If one of
    the IP addresses becomes unreachable, the ssh client begins to try
    other addresses in turn until it eventually connects. In this setup,
    GSSAPI auth always works because the hostname is the same.

    I wonder if browsers, MUAs and other client applications are also
    expected to try each IP address until success, but this is already
    another story.

    [dd]

    --
    Victor Sudakov, VAS4-RIPE, VAS47-RIPN
    2:5005/49@fidonet http://vas.tomsk.ru/

+ Reply to Thread