Re: [Freeipa-users] re-enrolling clients with --force-join getting /var/lib/sss/pubconf/known_hosts conflicts
On Thu, 2015-11-05 at 16:25 -0500, Rob Crittenden wrote: > What is "flaky" about it? It will fail and then without doing anything else except waiting a second or two, a second invocation will succeed. But I think I know why. It seems to fail on the slave server but pass on the primary server. Any hints on what to start looking for? Cheers, b. signature.asc Description: This is a digitally signed message part -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] re-enrolling clients with --force-join getting /var/lib/sss/pubconf/known_hosts conflicts
Brian J. Murrell wrote: > On Wed, 2015-11-04 at 15:37 -0500, Brian J. Murrell wrote: >> I am trying to re-enroll clients after re-installing their O/S (EL6) >> using: >> >> # ipa-client-install --force-join ... >> >> Per http://www.freeipa.org/page/V3/Forced_client_re-enrollment but I >> am >> finding that after doing that for a given host, trying to ssh to it >> from another enrolled IPA client I am getting: >> >> @@@ >> @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ >> @@@ >> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! >> Someone could be eavesdropping on you right now (man-in-the-middle >> attack)! >> It is also possible that a host key has just been changed. >> The fingerprint for the RSA key sent by the remote host is >> 15:db:4d:e2:8b:c2:b8:3d:da:93:90:06:f2:f1:d6:21. >> Please contact your system administrator. >> Add correct host key in /dev/null to get rid of this message. >> Offending DSA key in /var/lib/sss/pubconf/known_hosts:4 >> Keyboard-interactive authentication is disabled to avoid man-in-the >> -middle attacks. >> Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). > > So the problem here was not really anything to do with the above but > rather that ipa-client-install is flaky and can fail when running it a > few seconds later it succeeds. Since I am provisioning multiple > systems at a time in a script, it was not clearly obvious to me that it > was failing. What is "flaky" about it? > And so when ipa-client-install flakes out, of course what is left is > the previous instance of the node in FreeIPA complete with the previous > instance's SSH keys. Without any details it's hard to say what is going on. Having a side-by-side of an unsuccessful install log and a successful install log a few seconds later would be very helpful. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] re-enrolling clients with --force-join getting /var/lib/sss/pubconf/known_hosts conflicts
On Wed, 2015-11-04 at 15:37 -0500, Brian J. Murrell wrote: > I am trying to re-enroll clients after re-installing their O/S (EL6) > using: > > # ipa-client-install --force-join ... > > Per http://www.freeipa.org/page/V3/Forced_client_re-enrollment but I > am > finding that after doing that for a given host, trying to ssh to it > from another enrolled IPA client I am getting: > > @@@ > @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@ > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > Someone could be eavesdropping on you right now (man-in-the-middle > attack)! > It is also possible that a host key has just been changed. > The fingerprint for the RSA key sent by the remote host is > 15:db:4d:e2:8b:c2:b8:3d:da:93:90:06:f2:f1:d6:21. > Please contact your system administrator. > Add correct host key in /dev/null to get rid of this message. > Offending DSA key in /var/lib/sss/pubconf/known_hosts:4 > Keyboard-interactive authentication is disabled to avoid man-in-the > -middle attacks. > Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). So the problem here was not really anything to do with the above but rather that ipa-client-install is flaky and can fail when running it a few seconds later it succeeds. Since I am provisioning multiple systems at a time in a script, it was not clearly obvious to me that it was failing. And so when ipa-client-install flakes out, of course what is left is the previous instance of the node in FreeIPA complete with the previous instance's SSH keys. b. signature.asc Description: This is a digitally signed message part -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
