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 h...@`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 [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
