Generierung von SSHFP-Records in FreeIPA

532
Dave

MEIN SETUP

Ich habe einen Cluster von Computern, auf denen Centos 7.3 ausgeführt wird, und ich benutze Kerberos / LDAP für die Authentifizierung. Kerberos / LDAP sind in FreeIPA 4.4.0 enthalten.

Alle Hosts haben eine Adresse am 192.168.1.0/24 . Ich bezeichne das als "primäres" Netzwerk.

Einige Hosts haben eine Adresse in 192.168.2.0/24 . Ich bezeichne das als "sekundäres" Netzwerk. Für Hosts mit dieser zweiten Schnittstelle gibt es entsprechende zusätzliche A / PTR-Einträge in DNS, die einen sekundären Hostnamen und die sekundäre IP-Adresse zuordnen. In allen Fällen lautet der sekundäre Hostname <primärer Hostname> -eth1 .

MEIN ZIEL

Ich arbeite daran, SSO in unserem Cluster zu implementieren. SSO funktioniert gut im primären Netzwerk, aber nicht im sekundären Netzwerk.

Was ich bisher gemacht habe: SERVER SIDE

Ich habe den Server wie folgt konfiguriert:

ipa-server-install \ -r ME.EXAMPLE.COM \ -n me.example.com \ --mkhomedir \ --hostname=host-1.me.example.com \ --ip-address=192.168.1.1 \ --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> \ --no-dnssec-validation

Nachdem die Serverinstallation abgeschlossen ist, muss ich den folgenden PTR-Eintrag auch manuell zu DNS hinzufügen:

1.1.168.192.in-addr.arpa PTR host-1.me.example.com

Ich muss dies tun, da anscheinend das --auto-reverse- Flag zu ipa-server-install nicht funktioniert (oder, wahrscheinlich, ich verstehe es nicht).

Was ich bisher getan habe: CLIENT SIDE

Ich habe meine Client-Computer wie folgt konfiguriert:

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

Wie bei der Serverinstallation musste ich auch manuell DNS-PTR-Einträge für die Clients hinzufügen. Die von FreeIPA erstellten Forward-A-Datensätze waren in allen Fällen in Ordnung.

Um dann den sekundären Hostnamen bei FreeIPA registrieren zu lassen, habe ich auf dem Client Folgendes ausgeführt:

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

Diese erstellten Vorwärts-DNS-A-Einträge, aber ich musste die entsprechenden DNS-PTR-Einträge manuell hinzufügen.

DAS PROBLEM

Wo ich Probleme habe, ist im sekundären Netzwerk. Zum Beispiel kann ich SSH für host-1 kennwortlos verwenden (dh, SSO arbeitet im primären Netzwerk), aber ich kann SSH für host-1-eth1 nicht ohne Passwort (dh SSO funktioniert nicht im sekundären Netzwerk). .

Es gibt zwei Eingabeaufforderungen, die Sie möglicherweise von SSH erhalten:

  1. Eine Aufforderung, einen unbekannten SSH-Hostschlüssel zu akzeptieren
  2. Eine Aufforderung zur Eingabe des Kennworts des Benutzers

Ich werde nicht zur Eingabe eines Benutzerkennworts aufgefordert, wenn ich einen Host mit einem sekundären Hostnamen SSH benutze. Es ist die Aufforderung, einen unbekannten SSH-Hostschlüssel zu akzeptieren, den ich nicht umgehen kann, wenn ich mit einem sekundären Hostnamen versucht, SSH an einen Host zu senden. Und das passiert, weil ...

Ich habe beobachtet, dass für die sekundären Hostnamen keine SSHFP-DNS-Einträge generiert werden. Alle gleichen SSH-Hostschlüssel sollten mit dem sekundären Hostnamen verknüpft sein, die dem primären Hostnamen zugeordnet sind. Dies geschieht jedoch nicht.

Wie muss ich FreeIPA verwenden, um die erforderlichen SSHFP-DNS-Einträge für die sekundären Hostnamen zu erhalten? Natürlich ist mehr als der ipa-Join, den ich mache, erforderlich.

2

1 Antwort auf die Frage

0
Michael Ströder

Wahrscheinlich nicht die Antwort, die Sie mögen, aber ich habe auch über SSHFP-RRs in DNS nachgedacht, diese aber aus folgenden Gründen aufgegeben:

  1. Es benötigt Client-Unterstützung (siehe Option VerifyHostKeyDNS für OpenSSH-Client).
  2. Sie müssen Ihre DNS-Zonen mit DNSSEC signieren und über lokale Resolver verfügen, damit die Signaturen wirklich sicher sind. Andernfalls können DNS-Einträge leicht gefälscht werden.
  3. In einigen größeren Umgebungen ist es ziemlich schwierig, dies mit den Verantwortlichen für die DNS-Server zu koordinieren. Beachten Sie, dass Sie dynamische DNS-Updates benötigen, wenn Sie über viele SSH-Server verfügen.

Ich würde dringend empfehlen, sich die OpenSSH-Zertifikate anzusehen, damit eine vertrauenswürdige Zertifizierungsstelle alle Host-Schlüssel signieren kann. Dies erfordert auch eine Client-Unterstützung (z. B. in PuTTY nicht unterstützt) und Sie müssen die öffentlichen Schlüssel der SSH-CA an alle Clients verteilen. Aber es ist einfacher als DNSSEC und IMHO sicherer.

Verwandte Probleme