☰

Generierung von SSHFP-Datensätzen in FreeIPA

tag-icon • tag-icon linux ssh ldap kerberos freeipa
Generierung von SSHFP-Datensätzen in FreeIPA

MEIN SETUP

Ich habe einen Cluster von Maschinen, auf denen Centos 7.3 läuft, und verwende Kerberos/LDAP zur Authentifizierung. Kerberos/LDAP sind in FreeIPA 4.4.0 enthalten.

Alle Hosts haben eine Adresse auf192.168.1.0/24. Ich werde dies als das „primäre“ Netzwerk bezeichnen.

Einige Hosts haben eine Adresse in192.168.2.0/24. Ich werde dies als das „sekundäre“ Netzwerk bezeichnen. Für Hosts, die über diese zweite Schnittstelle verfügen, gibt es entsprechende zusätzliche A/PTR-Einträge im DNS, die einen sekundären Hostnamen und die sekundäre IP-Adresse verknüpfen. In allen Fällen lautet der sekundäre Hostname<primärer Hostname>-eth1.

MEIN ZIEL

Ich arbeite daran, SSO in unserem gesamten Cluster zu implementieren. SSO funktioniert im primären Netzwerk einwandfrei, im sekundären Netzwerk jedoch nicht.

WAS ICH BISHER GEMACHT HABE: SERVERSEITE

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 außerdem den folgenden PTR-Eintrag manuell zum DNS hinzufügen:

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

Ich muss das tun, da anscheinend die--auto-reverseFlagge zuipa-server-installfunktioniert nicht (oder, was wahrscheinlicher ist, ich verstehe es nicht).

WAS ICH BISHER GEMACHT HABE: KUNDENSEITE

Ich habe meine Client-Rechner wie folgt konfiguriert:

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

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

Um dann den sekundären Hostnamen bei FreeIPA zu registrieren, habe ich auf dem Client Folgendes getan:

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

Wie zuvor wurden dadurch weitergeleitete DNS-A-Einträge erstellt, aber ich musste entsprechende DNS-PTR-Einträge manuell hinzufügen.

DAS PROBLEM

Ich habe Probleme im sekundären Netzwerk. Ich kann beispielsweise per SSH aufGastgeber-1auf passwortlose Weise (d. h. SSO funktioniert im primären Netzwerk), aber ich kann nicht per SSH aufHost-1-eth1auf kennwortlose Weise (d. h. SSO funktioniert nicht im sekundären Netzwerk).

Es gibt zwei Eingabeaufforderungen, die man von SSH erhalten kann:

  1. Eine Aufforderung zum Akzeptieren eines unbekannten SSH-Hostschlüssels
  2. Eine Eingabeaufforderung für das Benutzerkennwort

Ich werde nicht nach einem Benutzerkennwort gefragt, wenn ich per SSH eine Verbindung zu einem Host mit seinem sekundären Hostnamen herstelle. Es ist die Aufforderung, einen unbekannten SSH-Hostschlüssel zu akzeptieren, die ich nicht umgehen kann, wenn ich versuche, per SSH eine Verbindung zu einem Host mit seinem sekundären Hostnamen herzustellen. Und das passiert, weil...

Mir ist aufgefallen, dass für die sekundären Hostnamen keine SSHFP-DNS-Einträge generiert werden. Dem sekundären Hostnamen sollten dieselben SSH-Hostschlüssel zugeordnet sein wie dem primären Hostnamen. Dies geschieht jedoch nicht.

Wie muss ich FreeIPA verwenden, um die benötigten SSHFP-DNS-Einträge für die sekundären Hostnamen zu generieren? Offensichtlich mehr als dieipa-beitretenIch tue, was nötig ist.

Antwort1

Das ist wahrscheinlich nicht die Antwort, die Ihnen gefällt, aber ich habe auch SSHFP-RRs in DNS in Betracht gezogen, dies jedoch aus den folgenden Gründen aufgegeben:

  1. Es benötigt Client-Support (siehe OptionVerifyHostKeyDNSfür OpenSSH-Client).
  2. Um wirklich sicher zu sein, müssen Sie Ihre DNS-Zonen mit DNSSEC signieren und lokale Resolver haben, die die Signaturen prüfen. Andernfalls können DNS-Einträge leicht gefälscht werden.
  3. In einigen größeren Umgebungen ist es ziemlich schwierig, dies mit den für die DNS-Server verantwortlichen Personen zu koordinieren. Bedenken Sie, dass Sie dynamische DNS-Updates benötigen, wenn Sie viele SSH-Server haben.

Ich empfehle dringend, sich das anzusehenOpenSSH-Zertifikateum alle Hostschlüssel von einer vertrauenswürdigen Zertifizierungsstelle signieren zu lassen. Dies erfordert ebenfalls Client-Unterstützung (wird z. B. in PuTTY nicht unterstützt) und Sie müssen die öffentlichen Schlüssel der SSH-CA an alle Clients verteilen. Es ist jedoch einfacher als DNSSEC und meiner Meinung nach sicherer.

verwandte Informationen