I have a cluster of machines running Centos 7.3, and I am using Kerberos / LDAP for authentication. Kerberos / LDAP are as packaged in FreeIPA 4.4.0.

All hosts have an address on I'll refer to this as the "primary" network.

Some hosts have an address in I'll refer to this as the "secondary" network. For hosts that have this second interface, there are corresponding extra A / PTR entries in DNS that associate a secondary hostname and the secondary IP address. In all cases, the secondary hostname is <primary hostname>-eth1.


I am working on getting SSO implemented across our cluster. SSO is working fine on the primary network, but not on the secondary network.


I configured the server as follows:

ipa-server-install \
-n me.example.com \
--mkhomedir \
--hostname=host-1.me.example.com \
--ip-address= \
--ssh-trust-dns \
--setup-dns \
--auto-forwarders \
--forward-policy=only \
--auto-reverse \
--dirsrv-cert-file=<path to server SSL certificate> \
--http-cert-file=<path to server SSL certificate> \

After the server installation completes, I also have to manually add the following PTR record to DNS: PTR host-1.me.example.com

I have to do this since, apparently, the --auto-reverse flag to ipa-server-install does not work (or, perhaps more likely, I don't understand it).


I configured my client machines as follows:

ipa-client-install \
--force-ntpd \
-p admin \
-W \
--mkhomedir \
--no-nisdomain \

As with the server installation, I also had to manually add DNS PTR records for the clients. The forward A records, as created by FreeIPA, have been fine in all cases.

Then, to get the secondary hostname enrolled with FreeIPA, I did the following on the client:

kinit admin
ipa-join -h host-1-eth1.me.example.com

As before, this created forward DNS A records, but I had to manually add corresponding DNS PTR records.


Where I am having trouble is on the secondary network. For example, I can SSH to host-1 in a passwordless manner (i.e. SSO is working on the primary network), but I cannot SSH to host-1-eth1 in a passwordless manner (i.e. SSO is not working on the secondary network).

There are two prompts one might receive from SSH:

  1. A prompt to accept an unknown SSH host key
  2. A prompt for the user's password

I do not get prompted for a user password when I SSH to a host using its secondary hostname. It is the prompt to accept an unknown SSH host key that I cannot get around when attempting to SSH to a host using its secondary hostname. And this is happening because...

I have observed that there are no SSHFP DNS records being generated for the secondary hostnames. All of the same SSH host keys should be associated with the secondary hostname as are associated with the primary hostname. However, this is not happening.

How must I use FreeIPA to get the needed SSHFP DNS records generated for the secondary hostnames? Obviously, more than the ipa-join I am doing is needed.


Probably not the answer you like but I've also considered SSHFP RRs in DNS but gave up on this because of the following reasons:

  1. It needs client support (see option VerifyHostKeyDNS for OpenSSH client).
  2. You need to sign your DNS zones with DNSSEC and have local resolvers to check the signatures to be really secure. Otherwise DNS records can be easily spoofed.
  3. In some bigger environments it's pretty hard to coordinate that with the people responsible for the DNS servers. Bear in mind that you would need dynamic DNS updates if you have many SSH servers.

I'd strongly recommend to look into OpenSSH certificates to let a trusted certificate authority sign all host keys. This also needs client support (e.g. not supported in PuTTY) and you have to distribute the public key(s) of the SSH-CA to all clients. But it is easier than DNSSEC and IMHO more secure.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.