>> nat...@nathanpeters.com wrote: >>> I have FreeIPA installed on several types of Linux machines and they >>> are >>> all experiencing strange issues with certificates and host keys. >>> Here is the setup: >>> >>> Server : FreeIPA 4.1.2 on Centos 7 >>> Client 1&2 : FreeIPA 3.0.0-42.el6 with sssd 1.11.6-30.el6_6.4 on CentOS >>> 6.5 >>> Client 3&4 : FreeIPA 4.1.2-1.el7 on Centos 7 >>> >>> >>> First the FreeIPA clients running client 3.0.0 do not seem to be >>> properly >>> getting their host keys from the server. Whenever I ssh from one >>> client >>> to another (or even to the IPA server itself) I am prompted to answer >>> yes >>> or no to the host key. The host keys are both listed in the host >>> record >>> if I login to the domain controller web interface (and match what is on >>> the server), and the DNS SSHFP records exist also. >>> >>> # sss_ssh_authorizedkeys --debug 10 admin >>> (Fri Mar 20 13:43:52:706986 2015) [sss_ssh_authorizedkeys] [main] >>> (0x0020): sss_ssh_get_ent() failed (2): No such file or directory >>> Error looking up public keys >>> >>> I've seen some bug reports that this was a problem with sssd 1.10 but >>> with >>> a recent (updated today) version of sssd 1.11 I would assume that is >>> not >>> the issue? >> >> I think you'll need to wait for one of the SSSD guys on this one. strace >> might point the way if the error is happening on the user side of dbus. >> >>> The second issue is that whenver I join a FreeIPA 4.1.2 client, I can't >>> login with FreeIPA or AD users. I believe this is due to the fact that >>> when I login to the domain controller web interface and look at the >>> freshly enrolled client it says "kerberos key present, host >>> provisioned" >>> but the next line is "Status No Valid Certificate". Unenrolling and >>> re-enrolling the client leads to the same issue with "No Valid >>> Certificate". >>> >>> Here is a grep of my client install log filtered for 'certificate'. I >>> don't see any errors. >>> 2015-03-20T20:33:28Z DEBUG args='/usr/bin/certutil' '-d' >>> '/tmp/tmpuZCwlm' >>> '-A' '-n' 'CA certificate 1' '-t' 'C,,' >>> 2015-03-20T20:33:28Z DEBUG auth_certificate_callback: check_sig=True >>> is_server=False >>> 2015-03-20T20:33:28Z DEBUG auth_certificate_callback: check_sig=True >>> is_server=False >>> 2015-03-20T20:33:30Z DEBUG Adding CA certificates to the IPA NSS >>> database. >>> 2015-03-20T20:33:32Z DEBUG Attempting to add CA certificates to the >>> default NSS database. >>> 2015-03-20T20:33:32Z INFO Added CA certificates to the default NSS >>> database. >>> 2015-03-20T20:33:32Z DEBUG auth_certificate_callback: check_sig=True >>> is_server=False >> >> The host certificate is not used for anything so it isn't the problem. >> One is not obtained automatically in 4.1 any more. It wouldn't be used >> at login in any case. >> >> Did you disable the HBAC allow-all rule? >> >> I'd bump up the sssd debug level and check the logs. >> >> rob >> >> > > Oh I realized that I can login to either of the 4.x clients from a windows > machine, but once on the 4.x client itself if I try to ssh off the machine > to either a 3.x or a 4.x client, I get : > $ ssh ipaclient4-sandbox-atdev-van > ssh_exchange_identification: Connection closed by remote host
Ok, this can be ignored. Apparently, 'Connection closed by remote host' is the message given when the actual problem is 'cannot resolve hostname in DNS'. This is really dumb because connection closed indicates that it not only found it in dns, but then managed to connect and then was closed. The real problem is that it was never opened because it could never be found. Stupidly misleading error message... -- 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
