0

I have several hosts running CentOS 7.3 with OpenSSH 6.6.1p1 and Kerberos 5 version 1.14.1.

My hosts and their network interfaces are as shown below. Hosts are listed by their "primary" hostname, which is the hostname that is associated in DNS with the single IP address on the host's eth0 network interface. On hosts with multiple network interfaces, I then also give the DNS names associated with the single IP address on each of those network interfaces.

  • inf.example.com

    • eth0: 192.168.1.1/24
  • dev.example.com

    • eth0: 192.168.1.2/24
  • cluster-1.example.com

    • eth0: 192.168.1.11/24
    • eth1: 192.168.10.11/24 (DNS A / PTR records for this secondary network interface are set up using hostname cluster-1-a.example.com)
  • cluster-2.example.com

    • eth0: 192.168.1.12/24
    • eth1: 192.168.10.12/24 (DNS A / PTR records for this secondary network interface are set up using hostname cluster-2-a.example.com)

inf.example.com, the "infrastructure" server, is where DNS, LDAP, the Kerberos Key Distribution Center (KDC), etc. run. These items are all managed in a unified manner via the use of FreeIPA version 4.4.0.

dev.example.com is a development host from which developers run scripts that use SSH to execute remote commands on cluster-1.example.com.

The command that's run on cluster-1.example.com in turn uses SSH to execute a remote command on the other cluster host, but it does so over its secondary network interface (i.e. over its 192.168.10.11 (aka cluster-2-a.example.com) network interface).

To facilitate running of these scripts, I am attempting to get Single Sign On (SSO) fully set up for OpenSSH.

Everything is working fine if I use the 192.168.1.0/24 addresses and use the -K flag for SSH to forward my Kerberos Ticket Granting Ticket (TGT) to the host I'm SSHing to:

user@dev$ ssh -K cluster-1.example.com
user@cluster-1$ ssh -K cluster-2.example.com
user@cluster-2 $ # Everything worked! I was never prompted to accept an SSH host key or to enter a password!

However, if I try to use the secondary network interface on the second SSH hop, things do not work as desired (i.e. in a way that requires no human interaction). Specifically, two prompts for human interaction occur:

  1. I am prompted to accept the server's SSH host key
  2. I am prompted for my password

These problems can be seen below:

user@dev$ ssh -K cluster-1.example.com
user@cluster-1$ ssh -K cluster-2-a.example.com
The authenticity of host 'cluster-2-a.example.com (<no hostip for proxy command>)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'cluster-2-a.example.com' (RSA) to the list of known hosts.
Password:

It's not surprising this is not working. Though the IP addresses and hostnames associated with the secondary network interfaces have corresponding A and PTR records in DNS, there is no "enrollment" of the IP addresses and hostnames associated with the secondary network interfaces in Kerberos.

How are hosts with multiple network interfaces / hostnames / IP addresses properly configured in Kerberos to allow SSH SSO to work using any of the hosts' hostnames / IP addresses?

7/31/2018 UPDATE
inf.example.com (i.e. the KDC) does not have a presence on the 192.168.10.0/24 network.

Does it need a presence on 192.168.10.0/24 for 1) Initial enrollment of cluster-1-a.example.com and cluster-2-a.example.com or for 2) ongoing operations of cluster-1-a.example.com and cluster-2-a.example.com?

Or, can all the Kerberos traffic needed to enroll and then operate the secondary network interfaces flow over the primary interfaces (i.e. the 192.168.1.0/24 network)?

1

Though the IP addresses and hostnames associated with the secondary network interfaces have corresponding A and PTR records in DNS, there is no "enrollment" of the IP addresses and hostnames associated with the secondary network interfaces in Kerberos.

Well, do enroll them.

  1. On each multihomed server, disable strict principal checking and tell it to accept tickets for any key that's present in its keytab:

  2. After you do this, add principals for all of the server's names to the KDC, and the keys for all of them into the same /etc/krb5.keytab. (For clients which have name canonicalization disabled, you can even add principals for short names and/or IP addresses.)

    FreeIPA seems to have a feature called "principal aliases" for doing this, although I'm not sure whether it works as needed here:

    https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/managing-kerberos-aliases

This is probably not the only way, but it's the simplest and does not involve any client-side configuration. Everything just works as before.

7/31/2018 UPDATE

inf.example.com (i.e. the KDC) does not have a presence on the 192.168.10.0/24 network.

Does it need a presence on 192.168.10.0/24 for 1) Initial enrollment of cluster-1-a.example.com and cluster-2-a.example.com or for 2) ongoing operations of cluster-1-a.example.com and cluster-2-a.example.com?

No, it doesn't. Kerberos does not care about subnets in the slightest – it only depends on standard unicast TCP/UDP communications working. (For example, my homelab has servers and KDCs in three separate countries, communicating over the public Internet...)

For that matter, the servers don't communicate with the KDC at all. Only clients do. The server uses its local keytab to verify your ticket.

(Of course, the server will communicate with your FreeIPA directory services to look up account details via LDAP... but that's no longer a Kerberos thing.)

  • I will likely accept this as an answer once I learn enough to do as you have suggested in a FreeIPA-compliant manner. I'm still on the Kerberos / FreeIPA learning curve. Are there security implications to the suggestion that's been made? – Dave Jul 25 '18 at 10:03
  • Shouldn't be any, at least as long as the keytab only has alternate principals for the same service. (Active Directory systems do this by default, with the same key being used for all of the host's principals. I suspect FreeIPA's "aliases" feature does the same.) Review the MIT Kerberos docs linked above though. – grawity Jul 25 '18 at 16:10
  • Slowly moving forward on this. Please see the 7/31/2018 update to my original post. Thank you! – Dave Jul 31 '18 at 14:04
  • That should probably be a standalone question, but in short, subnets are completely irrelevant. – grawity Jul 31 '18 at 16:12

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.