[Freeipa-users] MultiHomed Server SSH login issue

[David Christensen]

Nalin,

Thank you for the information it does help.  You have confirmed what
today's research has yielded; the need to modify sshd's behavior and
have it accept authentication for any name that has a key present in the
keytab.

I am running CentOS 5.4 and apparently the version of ssh that is
installed, 4.3p2 does not support "GSSAPIStrictAcceptorCheck".

I need to do some additional digging.

Thanks again.

David

On 02/22/2010 11:56 AM, Nalin Dahyabhai wrote:
> On Sat, Feb 20, 2010 at 07:31:33PM -0600, David Christensen wrote:
>> I have my ipa 1.2.2 setup in an environment where my servers have two
>> NICs each in a different VLAN.
>>
>> With the multi NIC setup I have two different DNS names for a single
>> host to control which interface is is used when accessing the host e.g.
>> host.example.com and host.priv.example.com.  The hostname of the server
>> is set to host.example.com.
>>
>> I first configured the ipa-client on the host with the host.example.com
>> service principle and all is well; I can login via ssh and
>> authentication occurs via kerberos.  I then setup another service
>> principle with the host.priv.example.com and downloaded the keytab to
>> the target server.  However when I try to login via ssh I am prompted
>> for a password.
>>
>> Turning on verbose output for ssh and upping the syslog to debug, I came
>> across this: Error code krb5 144 which I discovered means "wrong
>> principal in request."
>>
>> Is what I am trying to do, having more then one host/ssh service
>> principle for a single host that is multihomed?
>>
>> If so what is causing the error code 144 when I can see that in my local
>> klist the ticket for the host.priv.example.com is present?
> 
> In order for authentication to succeed, the client and server need to
> agree on what the server's principal name is.  Based on your tests, it
> looks as though the client is happy to think the server's name is
> "host/host.priv.example.com", but the server continues to assume it's
> name is more or less host@`hostname`, which in this case works out to
> "host/host.example.com".
> 
> At the API level, if an application avoids specifying its service name
> when accepting authentication, it'll able to accept authentication to
> any name for which it has a key in its keytab, which is what I think you
> want to have happen here.  The big caveat is that each application (if
> it even supports this) has to be configured differently.
> 
> In the case of sshd, I'd suggest setting
>   GSSAPIStrictAcceptorCheck no
> in /etc/ssh/sshd_config and seeing if that makes things work.
> 
> HTH,
> 
> Nalin