[Freeipa-users] MultiHomed Server SSH login issue

[Joe Presbrey]

Sorry for the late reply, David.

You should apply this patch to OpenSSH:
http://scripts.mit.edu/trac/browser/trunk/server/common/patches/openssh-5.0p1-multihomed.patch?format=txt

I use it at MIT with Kerberos there and elsewhere in an IPA environment with:
ipa-server-1.2.1-4.fc11.x86_64
openssh-5.2p1-2.fc11.x86_64

Load a principal for each of your reverse resolving IP hosts into
/etc/krb5.keytab using ktutil and everything will "just work".

--
Joe Presbrey

On Mon, Feb 22, 2010 at 3:26 PM, David Christensen <david at adurotec.com> wrote:
> 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
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>