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

Reply via email to