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".
On Mon, Feb 22, 2010 at 3:26 PM, David Christensen <da...@adurotec.com> wrote:
> 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
> 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.
> 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 h...@`hostname`, which in this case works out to
>> 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.
> Freeipa-users mailing list
Freeipa-users mailing list