Sorry for the late reply, David.

You should apply this patch to OpenSSH:

I use it at MIT with Kerberos there and elsewhere in an IPA environment with:

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 <> 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.
>>> and  The hostname of the server
>>> is set to
>>> I first configured the ipa-client on the host with the
>>> service principle and all is well; I can login via ssh and
>>> authentication occurs via kerberos.  I then setup another service
>>> principle with the 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 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/", but the server continues to assume it's
>> name is more or less h...@`hostname`, which in this case works out to
>> "host/".
>> 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 mailing list

Reply via email to