Zusammenfassung

  • Ein DNSSEC-authentisierter SSHFP-Treffer bindet Algorithmus und Fingerabdruck eines präsentierten SSH-Hostschlüssels an einen ausgewählten DNS-Eigentümernamen. Er beweist weder die beabsichtigte Dienstwahl noch Port, Nutzer oder Befehl.
  • Die Entscheidung setzt Namenswahl, DNSSEC-Zustand, exakten Vergleich, SSH-Besitznachweis und lokale Policy zusammen. Rotation koordiniert zusätzlich DNS-Cache und known_hosts.

Der richtige Beweis für den falschen Namen

Im Eingangsfall wurde nichts gefälscht. Der Resolver wählte einen vollständigen Namen, DNSSEC authentisierte dessen RRset, der Server signierte den Austausch mit dem passenden privaten Schlüssel. Unbeantwortet blieb, weshalb db gerade zu diesem Namen erweitert werden durfte.

RFC 4255 warnt vor unqualifizierten Namen. Ein eingeschleuster Suchpfad kann zu einem anderen Host führen; daher soll in diesem Fall zunächst eine lokale Schlüsseldatenbank geprüft werden. DNSSEC macht die Antwort auf die gestellte Frage echt. Es macht die Frage nicht vernünftig.

Die Spur muss Eingabename, effektiven Namen, Suffix/CNAME, SSHFP-Owner, Adresse und Port getrennt halten.

Drei Werte und ihre Lücken

SSHFP ist DNS-Typ 44. RDATA enthält Schlüsselalgorithmus, Fingerabdrucktyp und Fingerabdruck. Der Ownername liegt außerhalb. Empfangener Algorithmus und berechneter Digest über den Public-Key-Blob müssen gemeinsam passen.

Der SSH-Transport verlangt weiterhin eine Signatur des Austauschs und beweist damit Besitz des privaten Schlüssels in dieser Sitzung. Besitz ist nicht exklusiv; eine gestohlene Kopie signiert ebenso gültig.

Der Record enthält keinen Port, Account, Befehl, IP, Rolle oder Gültigkeitszeitraum. Ein Treffer für einen Hostnamen entscheidet nicht zwischen zwei Daemons, einem Bastion-Host oder Umgebungen.

Secure ist ein DNSSEC-Zustand

RFC 4255 verbietet Vertrauen über SSHFP, wenn der verwendete RR nicht durch eine vertrauenswürdige DNS-Signatur authentisiert wurde. Bei ausgelagerter Validierung braucht auch der Weg zum Validator Schutz.

Secure, Insecure, Bogus und Indeterminate sind verschieden. Ein identischer Fingerabdruck unter Insecure verdient kein automatisches Vertrauen. Bogus darf nicht aus Verfügbarkeitsgründen herabgestuft werden. Selbst Secure authentisiert den RRset des abgefragten Namens, nicht die Absicht hinter DHCP-Suffix oder Kanonisierung.

Kein Rückfall nach SHA-256-Widerspruch

IANA registriert RSA, DSA, ECDSA, Ed25519, Ed448 sowie SHA-1 und SHA-256. Registrierung beweist keine Laufzeitunterstützung.

RFC 6594 verlangt: Unterstützt ein Client SHA-256 und liegen beide Digesttypen vor, ist SHA-256 vorzuziehen. Passt SHA-256 nicht, muss der Schlüssel abgelehnt werden; ein passender SHA-1-Record darf ihn nicht retten. Telemetrie braucht Owner, Algorithmus, Typ, berechneten Wert und jedes Ergebnis statt sshfp=match.

Die lokale Policy entscheidet

RFC 4255 lässt die Reihenfolge von SSHFP und lokalen Datenbanken konfigurierbar. OpenSSH dokumentiert VerifyHostKeyDNS=no als Standard. yes vertraut einer Secure-Übereinstimmung implizit; unsichere Treffer werden wie ask behandelt. Bei ask bleibt StrictHostKeyChecking für neue Schlüssel maßgeblich.

Globale und persönliche known_hosts, Host/Match, Kanonisierung und CNAME-Regeln verändern den tatsächlich ausgeführten Zweig. Genau diese effektive Konfiguration gehört ins Beweisprotokoll.

OpenSSH kann known_hosts als [hostname]:port verwalten; ssh-keygen -r erzeugt SSHFP nach Hostname. SSHFP trägt keinen Port. Auch ein Sprunghost hat eine eigene Schlüsselentscheidung; die Authentisierung des Ziels gilt nicht rückwärts für den Bastion-Host.

Rotation läuft auf zwei Uhren

SSHFP-Austausch kann neue Schlüssel verteilen, Löschung bei verpflichtender Policy zur Sperre beitragen. TTL, RRSIG-Zeitraum und lokale Pins bleiben jedoch bestehen. Eine Änderung am autoritativen Server ist keine sofortige weltweite Ablehnung.

Eine geordnete Rotation veröffentlicht den neuen Fingerabdruck sicher vorab, beobachtet wichtige Validatoren, überlappt begrenzt, wechselt den Daemon, entfernt den alten RR und testet nach Cache-Ablauf die Ablehnung.

Host ist nicht Nutzer

SSH trennt Serverauthentisierung im Transport von Nutzerauthentisierung. Ein angenommener Hostschlüssel schützt den Kanal zum ausgewählten Server. Er genehmigt weder Konto, Shell, Weiterleitung noch Befehl.

Negative Tests variieren Suchpfad, DNSSEC-Zustand, SHA-256-Fehler, lokalen Pin, Ports, Bastion, kopierten privaten Schlüssel und anschließende Nutzer-/Befehlsablehnung. Jeder Pass muss Owner, Zustand, Schlüssel, Port, Verbindung, Policy und Folgeerlaubnis benennen.