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 <[email protected]> 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 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 > _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
