Kann SSH-Hostnamenkanonisierung das genehmigte Ziel ändern?

Eine Genehmigung mit dem Text ssh build autorisiert nicht zwingend den Rechner, der am Ende die TCP-Verbindung annimmt. OpenSSH kann den Kurznamen ergänzen, einem erlaubten CNAME folgen, seine Konfiguration ein zweites Mal auswerten, einen anderen Benutzer oder Port wählen und den entstandenen Namen in eine von mehreren Adressen auflösen. Wenn ein Agent-Gateway nur den Text des Agenten genehmigt, kann die Genehmigung ein Ziel beschreiben, während der SSH-Client ein anderes verwendet.

Das ist kein Argument gegen Kanonisierung. Kurznamen sind praktisch, kanonische Namen erleichtern die Verwaltung und Hostschlüssel authentifizieren weiterhin die Server. Die Genehmigungsgrenze gehört hinter die Berechnung des effektiven Ziels durch OpenSSH und vor das Öffnen des Sockets. Die genehmigende Person sollte den angeforderten Namen, den endgültigen Namen und die Adresse sowie jede wesentliche Konfigurationsänderung sehen.

Ein SSH-Befehl enthält vier verschiedene Identitäten

Ein SSH-Ziel ist nicht nur eine Zeichenkette. Wer es darauf reduziert, erzeugt den hier beschriebenen Fehler. Ein ernsthafter Genehmigungsweg hält vier Identitäten getrennt:

• Der angeforderte Name ist das Argument des Agenten, etwa build.
• Der effektive Hostname ist der Wert, den OpenSSH nach Hostname-Ersetzung und Kanonisierung verwendet, etwa build.ops.example.
• Die Gegenstellenadresse ist die IP-Adresse, die der Client beim Öffnen des Sockets auswählt.
• Die authentifizierte Identität ist der für die Verbindung akzeptierte Hostschlüssel oder das Hostzertifikat.

Diese Werte beantworten verschiedene Fragen. Der angeforderte Name hält die Absicht fest. Der effektive Name steuert spätere Konfigurationsabgleiche und meist die Hostschlüsselsuche. Die Adresse sagt, wohin die Pakete gingen. Der Hostschlüssel sagt, welcher Server den Besitz eines privaten Schlüssels nachgewiesen hat. Vor der Verbindung braucht die Genehmigung die ersten drei Angaben, nach dem Schlüsselaustausch sollte das Auditergebnis die vierte ergänzen.

OpenSSH macht den Namensunterschied in ssh_config selbst sichtbar. Das Token %n bezeichnet den ursprünglichen entfernten Hostnamen aus der Befehlszeile, %h dagegen den Namen nach der Konfigurationsverarbeitung. %k enthält einen weiteren Wert: HostKeyAlias, falls gesetzt, sonst den ursprünglichen Namen. Diese Tokens existieren, weil OpenSSH nicht sicher davon ausgehen kann, dass jede Phase denselben Namen nutzt.

Der Unterschied erklärt auch, warum eine erfolgreiche Hostschlüsselprüfung eine ungenaue Autorisierung nicht repariert. Authentifizierung kann beweisen, dass die Gegenstelle den erwarteten Schlüssel besitzt. Sie beweist nicht, dass der Mensch diese Gegenstelle autorisieren wollte, als die Karte nur build zeigte. Autorisierung fragt, ob die Aktion dieses Ziel erreichen darf. Authentifizierung fragt, ob der antwortende Server zu einem Identitätseintrag passt. Beide Prüfungen sind nötig und finden zu unterschiedlichen Zeitpunkten statt.

Kanonisierung kann den Namen vor der Verbindung umschreiben

CanonicalizeHostname steuert, ob OpenSSH Namen ausdrücklich umschreibt. Der Standardwert no überlässt die Suche dem Systemresolver. Mit yes probiert OpenSSH bei direkten Verbindungen die Suffixe aus CanonicalDomains. Mit always werden auch Ziele hinter ProxyCommand oder ProxyJump kanonisiert.

Angenommen, der Agent fordert diese Aktion an:

host: build
user: deploy
command: /usr/local/bin/release status

Der Client könnte diese Konfiguration haben:

Host *
    CanonicalizeHostname yes
    CanonicalDomains ops.example
    CanonicalizeFallbackLocal no
    CanonicalizeMaxDots 1
    CanonicalizePermittedCNAMEs *.ops.example:*.hosts.example

OpenSSH versucht zuerst build.ops.example. Liefert DNS einen erlaubten CNAME auf build-07.hosts.example, kann dieses Ziel zum kanonischen Namen werden. Die Anforderung lautet noch immer build, doch der Client verbindet sich nicht mehr unter diesem Namen. Eine Karte, die nur die Anforderung zeigt, verbirgt die entscheidende Umwandlung.

Die Grenzen verdienen Aufmerksamkeit. CanonicalizeMaxDots hat den Standardwert 1, daher kommt auch ein Name mit einem Punkt für die Kanonisierung infrage, nicht nur ein einzelnes Label. CanonicalizeFallbackLocal steht standardmäßig auf yes; liefern die konfigurierten kanonischen Domains kein Ergebnis, kann OpenSSH den ursprünglichen Namen an den Systemresolver und dessen Suchregeln geben. Mit no wird der Fehler sichtbar. Für ein Genehmigungs-Gateway ist das meist besser, denn lokale Suchlisten können sich mit Netzwerk und Zeit ändern.

Das Folgen von CNAMEs wird separat beschränkt. CanonicalizePermittedCNAMEs steht standardmäßig auf none, und seine Regeln verbinden erlaubte Quellmuster mit Zielmustern. Dieser Standard ist sinnvoll. Eine breite Regel wie *:* macht den DNS-Alias zu einem unbeschränkten Umschreibeschritt. Eine enge Regel dokumentiert den tatsächlich erwarteten Wechsel des Namensraums, etwa von Dienstaliasen unter ops.example zu Hosts unter hosts.example.

Das OpenSSH-Handbuch beschreibt diese Optionen genau, aber eine Richtlinienebene darf ihre Werte nicht nur auf die Karte kopieren. Sie muss dieselbe Berechnung mit derselben Clientkonfiguration ausführen. Eine eigene Nachbildung der Suffixsuche und CNAME-Regeln im Genehmigungsdienst weicht bei Versions- und Konfigurationsänderungen leicht vom SSH-Client ab.

Der zweite Konfigurationslauf ändert mehr als DNS

Bei aktiver Kanonisierung verarbeitet OpenSSH seine Konfiguration erneut mit dem neuen Zielnamen. Dieser zweite Lauf kann Host- und Match-Blöcke aktivieren, die nicht zum ursprünglichen Alias passten. Eine reine DNS-Vorprüfung kann deshalb weitere Änderungen am Ziel übersehen.

Nehmen wir an, der kanonische Name passt zu diesem Block:

Match canonical host *.prod.ops.example
    User release
    Port 2222
    IdentityFile ~/.ssh/prod_release
    ProxyJump bastion.ops.example

Eine Anforderung für deploy könnte zunächst zu deploy.prod.ops.example werden und anschließend einen anderen entfernten Benutzer, Port, eine andere Identitätsdatei und einen Sprunghost erhalten. OpenSSH verwendet für die meisten Direktiven den zuerst gefundenen Wert. Ob diese Einstellungen greifen, hängt also von früheren Blöcken und ihrer Reihenfolge ab. Aus dem passenden Block allein lässt sich die endgültige Konfiguration nicht ableiten.

Die Bedingung canonical passt nur beim erneuten Lesen nach der Kanonisierung. final fordert einen letzten Lauf auch dann an, wenn die Kanonisierung deaktiviert ist. Ist sie aktiv, passen canonical und final im selben Lauf. host prüft das Ziel nach Hostname-Ersetzung oder Kanonisierung, originalhost dagegen den Befehlszeilenwert. Durch diese Details hängt eine scheinbar einfache Konfiguration stark vom Zustand ab.

Das gefährliche Muster lautet: host=deploy, user=agent, port=22 genehmigen, danach ssh deploy an einen normalen Client geben und annehmen, dass die Felder gleich bleiben. Darf die Clientkonfiguration weiterhin User, Port, ProxyJump, RemoteCommand, Weiterleitungen oder die Identitätswahl ändern, wurde ein Vorschlag genehmigt und nicht die ausgeführte Aktion.

Ein sichereres Design friert die wesentliche effektive Konfiguration nach dem letzten Lauf ein. Binden Sie mindestens Host, gewählte Adresse, Port, entfernten Benutzer, Proxyweg, entfernten Befehl, Weiterleitungen, Hostschlüsselalias und Identitätsquelle an die Genehmigung. Ändert sich ein Wert vor der Verbindung, verwerfen Sie die Genehmigung und fragen erneut. Eine zweite Auswertung darf die alte Entscheidung nicht stillschweigend übernehmen.

Die Herkunft der Konfiguration gehört zum Ziel

Das endgültige Ziel hängt von den Dateien, Befehlszeilenoptionen, der Umgebung und dem lokalen Netzwerk ab, die OpenSSH ausgewertet hat. Werden diese Eingaben nicht erfasst, kann sich die genehmigte Bedeutung leicht ändern. Das Handbuch nennt als normale Reihenfolge Befehlszeilenoptionen, Benutzerdatei und Systemdatei. Bei den meisten Direktiven gilt der erste gefundene Wert.

Ein Agent, der beliebige SSH-Optionen ergänzen darf, kann vorsichtige Standards umgehen. -F wählt eine andere Datei, während -o direkt Hostname, ProxyCommand, ProxyJump, Port, User, HostKeyAlias oder Weiterleitungen setzen kann. Das Gateway sollte eine SSH-Aktion in typisierte Felder zerlegen und nicht unterstützte Optionen ablehnen, statt eine undurchsichtige Zeichenkette zu akzeptieren. Sind Rohoptionen nötig, müssen alle zielrelevanten Optionen klassifiziert und normalisiert in die Genehmigung aufgenommen werden.

Konfigurationsdateien bringen transitive Eingaben mit. Include akzeptiert mehrere Pfade, Platzhalter, Tokens und Umgebungsvariablen und verarbeitet Treffer in lexikalischer Reihenfolge. Eine neue Datei in einem eingebundenen Verzeichnis kann den ersten Wert ändern, ohne die Hauptdatei anzufassen. Erfassen Sie Inhaltsdigest und Eigentümer jeder geladenen Datei, nicht nur den Pfad der ersten. Lehnen Sie Dateien ab, die der Agent oder das Arbeitsverzeichnis eines nicht vertrauenswürdigen Repositorys schreiben kann.

Match exec ist mehr als ein Vergleich: OpenSSH führt den angegebenen Befehl in der Shell des Benutzers aus und wertet Rückgabecode null als Treffer. Match localnetwork kann die Konfiguration nach den Adressen aktiver lokaler Schnittstellen ändern. Das Handbuch warnt selbst, dass ein lokal beobachtetes Netzwerk bei DHCP keine verlässliche Grundlage für sicherheitsrelevante Konfiguration ist. Dieselbe Anforderung ssh build kann nach einer VPN-Verbindung, einem anderen Skriptergebnis oder einer neuen eingebundenen Datei ein anderes Ziel ergeben.

Der Genehmigungsausführer sollte vor der Auswertung einen geschlossenen Eingabesatz bilden. Nutzen Sie ein festes Clientprogramm, eine kontrollierte Konfigurationswurzel, eine bereinigte Umgebung, bekannte Dateieigentümer, eine ausdrückliche Adressfamilie und eine erklärte Regel für Benutzer- und Systemdateien. Berechnen Sie einen Digest dieses Satzes und legen Sie ihn in das Ausführungsticket. Er muss nicht die Karte beherrschen, gehört aber ins Audit und muss bei der Nutzung erneut geprüft werden.

Konfiguration einzufrieren verlangt kein Verbot nützlicher Hosteinstellungen. Es verlangt eine Entscheidung, wer sie schreiben darf. Ein vom Betreiber verwalteter Alias, der build einem kanonischen Produktionshost zuordnet, kann sicher sein, wenn die Karte die Zuordnung zeigt. Ein Alias in einem vom Agenten kontrollierten Checkout gehört zur nicht vertrauenswürdigen Anforderung, selbst wenn er wie gewöhnliche OpenSSH-Konfiguration aussieht.

Diese Herkunftsprüfung schließt auch eine häufige Testlücke. Teams testen die Kanonisierung oft mit einer sauberen temporären Datei, führen die Aktion aber mit der vollständigen Entwicklerkonfiguration und den Systemstandards aus. Der Test beweist das Verhalten der temporären Datei, nicht der echten Aktion. Erfassen Sie die genauen Eingaben einmal und tragen Sie sie bis zur Verbindung weiter.

Behandeln Sie auch die OpenSSH-Version als Eingabe. Standards und zulässige Direktiven ändern sich, und in einer Flotte können verschiedene Builds dieselbe Datei lesen. Erfassen Sie Programmpfad und Version im Ticket und wiederholen Sie Kompatibilitätstests vor einem Upgrade. Ein für eine Version geschriebener Parser sollte unbekannte Ausgabe ablehnen, statt ein neues oder umbenanntes Feld für harmlos zu halten.

Die Herkunft entscheidet außerdem, ob eine Genehmigung wiederverwendet werden darf. Das ist nur vertretbar, wenn Anforderung, vollständige Konfiguration, Auflösungsergebnis und Connectorzustand für kurze Zeit identisch bleiben. Ein gleicher Spitzname beweist nichts davon. Eine neue knappe Genehmigung ist besser als eine langfristige Erlaubnis, deren effektives Ziel zwischen Agentläufen unbemerkt wandert.

DNS-Antworten können sich nach der Anzeige ändern

Auch bei festem effektivem Hostnamen kann sich seine Adresse zwischen Genehmigung und Verbindung ändern. DNS-Rotation, getrennte Ansichten, VPN-Wechsel, Resolversuchpfade und normale Aktualisierungen können andere Antworten liefern. Eine klassische Lücke zwischen Prüfung und Nutzung entsteht, wenn der Dienst den Namen auflöst und eine Adresse zeigt, der SSH-Prozess später aber erneut auflöst.

Die Lösung besteht nicht darin, DNS als nicht vertrauenswürdig zu bezeichnen und die Adresse wegzulassen. Die Ausführung muss an genau das Auflösungsergebnis gebunden werden, das der Mensch gesehen hat. Lösen Sie einmal im vertrauenswürdigen Ausführer auf, wählen Sie eine Adresse nach den Regeln des Clients, zeigen Sie sie an und geben Sie dieselbe Socketadresse ohne weitere Namenssuche an die Verbindung. Behalten Sie den kanonischen Namen für anwendbare Identitätszwecke, Schlüsselsuche, Zertifikate und Protokolle, aber lassen Sie den Transport keine neue Adresse wählen.

Mehrere A- oder AAAA-Einträge brauchen eine ausdrückliche Regel. Einen begrenzten Adresssatz zu zeigen und dem Client einen Versuch mit seinen Mitgliedern zu erlauben, kann sinnvoll sein. Die Genehmigung muss dann den Satz nennen, und das Audit muss die erfolgreiche Adresse erfassen. Ändert sich der Satz, darf die alte Genehmigung die neue Adresse nicht einschließen. Bei besonders wichtigen Hosts ist eine einzelne ausgewählte Adresse einfacher nachzuvollziehen.

Ein Proxy verändert den Ort der DNS-Auflösung. Bei ProxyJump bittet der Client die Sprungverbindung meist, den Datenverkehr zum endgültigen Host und Port zu tragen. ProxyCommand kann fast jedes Transportverhalten umsetzen. Die lokal sichtbare Gegenstellenadresse kann zum Proxy gehören, während der Zielname anderswo aufgelöst wird. Die Genehmigung braucht beide Schritte: den konkreten Proxyendpunkt und den durch ihn übertragenen Zielwert. Den Proxy als Ziel auszugeben verliert das eigentliche Ziel; ihn zu ignorieren verliert den Netzwerkweg.

Ein gültiger Hostschlüssel bestätigt nicht den angeforderten Namen

Strikte Hostschlüsselprüfung schützt eine andere Grenze als die Zielgenehmigung. Sie sollte aktiv bleiben, kann aber nicht erkennen, ob das Kanonisierungsergebnis der menschlichen Absicht entsprach. Gemeinsame Schlüssel, Zertifikate mit mehreren Principals und ein ausdrücklicher HostKeyAlias können eine kryptografisch gültige Verbindung unter einem nicht angezeigten Namen erzeugen.

Die SSH-Architektur in RFC 4251 beschreibt eine lokale Datenbank, die den vom Benutzer eingegebenen Namen mit einem Hostschlüssel verknüpft. OpenSSH ergänzt dieses Modell um konfigurationsgesteuerte Namen. HostKeyAlias weist den Client an, beim Lesen und Speichern von Schlüsseln sowie beim Prüfen von Zertifikaten einen Alias statt des echten Namens zu verwenden. Das hilft bei Tunneln und mehreren Servern unter einer Adresse, erzeugt aber einen weiteren Namen für das Audit.

RFC 4255, der SSHFP definiert, ist hier besonders relevant. Er warnt vor unvollständigen Hostnamen und eingeschleusten DNS-Suchpfaden und empfiehlt dann, zuerst die lokale Schlüsseldatenbank zu prüfen. Er sagt außerdem, dass einem SSHFP-Eintrag ohne DNSSEC-Authentifizierung nicht vertraut werden darf. Der Rat behandelt Serverauthentifizierung, stützt aber den allgemeinen Punkt: Namenserweiterung verändert den Sicherheitskontext, und Resolverausgabe allein beweist keine Identität.

RFC 4462 warnt für GSS-API noch deutlicher. Eine Implementierung darf kein unsicheres DNS-Ergebnis zum Aufbau des Zielnamens verwenden, weil ein Angreifer Alias oder Adresszuordnung ändern und den Server nachahmen könnte. Auch bei gewöhnlicher Authentifizierung mit öffentlichem Schlüssel bleibt die Lehre gültig. Eine ungeschützte Namensumschreibung darf nicht heimlich die Identität festlegen, die eine Sicherheitskontrolle angeblich genehmigt hat.

Die Schlüsselprüfung sollte das Verbindungsergebnis wieder an den Vorprüfungsdatensatz binden. Erfassen Sie den vorgelegten Fingerabdruck, den Suchnamen oder Alias, die Übereinstimmung eines Zertifikats-Principals und das Ergebnis der strikten Prüfung. Fragt der Client nach Annahme eines neuen Schlüssels, ist das eine neue Sicherheitsentscheidung. Ein autonomer Prozess darf sie nicht automatisch treffen, nur weil zuvor ein Shellbefehl genehmigt wurde.

Die Vorprüfung muss dieselben OpenSSH-Eingaben verwenden

Eine brauchbare Vorprüfung bildet die endgültige Clientkonfiguration nach und beobachtet den Weg, ohne den entfernten Befehl auszuführen. ssh -G gibt die Konfiguration nach Auswertung der Blöcke Host und Match aus. ssh -vvv ergänzt Diagnose zu Auflösung, Verbindung und Hostschlüssel; laut Handbuch sind drei -v die höchste Ausführlichkeit.

Führen Sie diese Folge in einer kontrollierten Umgebung aus und ersetzen Sie build durch das genaue angeforderte Token:

ssh -G build | awk '
  $1 == "hostname" || $1 == "user" || $1 == "port" ||
  $1 == "proxyjump" || $1 == "proxycommand" ||
  $1 == "hostkeyalias" || $1 == "canonicalizehostname" {
    print
  }
'
ssh -vvv -o BatchMode=yes -o SessionType=none \
  -o ConnectTimeout=5 build 2>&1

Der erste Befehl erzeugt ungefähr diese Ausgabeform:

user deploy
hostname build-07.hosts.example
port 22
canonicalizehostname true
proxyjump none

Der ausführliche Lauf gibt anschließend versionsabhängige Zeilen aus, benennt aber den erweiterten Host, gewählte Adresse und Port, Konfigurationsläufe und angebotenen Schlüssel. Erfassen Sie strukturierte Fakten im Ausführer, statt Debugtext als stabile API zu behandeln. Die Befehle eignen sich für manuelle Untersuchungen; Produktionscode sollte dieselben Fakten aus der Implementierung beziehen, die den Socket öffnet.

Diese Diagnose hat zwei Fallen. Erstens zeigt ssh -G die ausgewertete Konfiguration, beweist aber nicht, welche Adresse eine spätere Verbindung erreicht. Zweitens kann die ausführliche Prüfung auch mit SessionType=none eine Verbindung öffnen und Schlüssel austauschen; führen Sie sie nur mit eigener Autorisierung aus. BatchMode=yes unterdrückt interaktive Fragen, macht aus einem Verbindungsversuch aber keine lokale Berechnung.

Isolieren Sie für eine reproduzierbare Untersuchung alle Eingaben. Geben Sie die erwartete Benutzerdatei mit -F an, berücksichtigen Sie das Verhalten des Builds bei der Systemdatei, fixieren Sie Variablen für Include und Tokens und erfassen Sie die Version. Halten Sie auch fest, ob ein Kontrollsocket eine multiplexierte Verbindung wiederverwenden kann. Eine frische Vorprüfung hilft wenig, wenn die Ausführung einer alten Mastersitzung beitritt.

Starten Sie nicht eine unabhängige Auswertung zur Genehmigung und eine zweite zur Ausführung. Die bevorzugte Architektur verwendet einen Ausführer, der lädt, kanonisiert, auflöst, mit einem unveränderlichen Kandidatendatensatz pausiert und nach der Genehmigung denselben Zustandsautomaten fortsetzt. Kann die Bibliothek nicht sicher pausieren, erstellen Sie ein signiertes oder authentifiziertes Ticket mit allen wesentlichen Feldern und lassen Sie jede Abweichung ablehnen.

Der Genehmigungsdatensatz sollte die Umwandlung zeigen

Eine gute Karte macht die Änderung sichtbar, ohne ein Debugprotokoll zu verlangen. Zeigen Sie das angeforderte Ziel neben effektivem Ziel und Adresse. Wenn nichts geändert wurde, sagen Sie es knapp. Hat die Kanonisierung oder ein Match-Block ein wesentliches Feld geändert, markieren Sie alten und neuen Wert.

Ein praktischer Datensatz kann so aussehen:

{
  "requested": {
    "host": "build",
    "user": "deploy",
    "command": "/usr/local/bin/release status"
  },
  "effective": {
    "host": "build-07.hosts.example",
    "address": "192.0.2.44",
    "port": 22,
    "user": "deploy",
    "proxy": null,
    "host_key_alias": null
  },
  "resolution": {
    "canonicalized": true,
    "source": "build.ops.example",
    "permitted_cname": true
  },
  "binding": "sha256:REDACTED"
}

Die Bindung sollte eine deterministische Kodierung der angeforderten und effektiven Felder, den entfernten Befehl, Weiterleitungen, die Konfigurationsidentität, Adresse oder genehmigten Satz und eine kurze Gültigkeit abdecken. Der Connector berechnet sie direkt vor dem Öffnen neu. Unterscheiden sich DNS, Konfiguration, Befehl, Benutzer, Port oder Proxyweg, stoppt er.

Entfernen Sie kein Feld von der sichtbaren Karte, nur weil es in der Bindung steckt. Menschen autorisieren, was sie sehen. Zeigen Sie build -> build-07.hosts.example (192.0.2.44) als lesbare Umwandlung, danach Benutzer, Port, Proxy und Befehl. Fingerabdrücke und Herkunft können in aufklappbare Details, außer eine neue oder geänderte Hostidentität verlangt Aufmerksamkeit.

Schwierig ist ein Name, der in einen großen oder wechselhaften Pool aufgelöst wird. Genehmigen Sie kein grenzenloses Konzept wie jede derzeitige Adresse dieses Namens. Wählen Sie einen Kandidaten, genehmigen Sie einen begrenzten veröffentlichten Satz mit Ablauf oder verlangen Sie eine stabilere Identität, etwa einen Zertifikats-Principal einer vertrauenswürdigen CA. Das Modell muss erklärt und darf nicht vom Connector erraten werden.

Proxys und Wiederverwendung brauchen getrennte Bindungen

Bei Proxys verhält sich die Kanonisierung anders. CanonicalizeHostname yes gilt nur für Verbindungen ohne ProxyCommand und ProxyJump; always schließt Proxyverbindungen ein. Dieses eine Wort kann den endgültigen Namen ändern und den zweiten Konfigurationslauf auslösen. Das System muss den tatsächlichen Wert erfassen und darf keine globale Aktivierung annehmen.

Jeder Sprunghost ist eine eigene SSH-Verbindung mit angefordertem Namen, effektivem Namen, Adresse, Benutzer, Port und authentifiziertem Schlüssel. Auch das endgültige Ziel behält seine Identität im Tunnel. Nur die letzte Bezeichnung zu genehmigen übersieht einen kompromittierten oder unerwarteten Sprung. Nur den Sprungserver zu genehmigen übersieht das Weiterleitungsziel.

Verbindungsmultiplexing schafft einen weniger sichtbaren Umweg. Existiert bereits eine passende ControlMaster-Sitzung, kann ein neuer Aufruf sie verwenden, statt die vorhergesagte Verbindung aufzubauen. Der Master könnte DNS früher aufgelöst, alte Konfiguration verwendet und einen Schlüssel vor der aktuellen Genehmigung geprüft haben. Deaktivieren Sie Wiederverwendung für kontrollierte Agentaktionen oder binden Sie die Genehmigung an die unveränderliche Verbindungsidentität des Masters und prüfen Sie sie vor dem Öffnen eines Kanals.

Dieselbe Regel gilt für Wiederholungsversuche. Scheitert eine Adresse, bleibt die nächste nur autorisiert, wenn sie im angezeigten Satz enthalten war. Ersatzproxy, anderer Port oder neu kanonisierter Name sind keine bloßen Transportdetails. Sie ändern den Gegenstand der Autorisierung und brauchen eine neue Entscheidung.

Auditbelege müssen Absicht und Ergebnis bewahren

Ein nützlicher Eintrag lässt die ganze Umwandlung ohne erneute DNS-Abfrage rekonstruieren. Speichern Sie die ursprüngliche Agentanforderung, effektive Felder, kanonischen Namen, DNS-Kette, Kandidatenadressen, ausgewählte Adresse, Sprünge, akzeptierten Fingerabdruck, Zertifikats-Principal und Befehl oder Subsystem. Zeitstempeln Sie Auflösung und Socketverbindung getrennt, damit der Abstand sichtbar ist.

Sallyport führt SSH-Aktionen über das mitgelieferte Hilfsprogramm sp-ssh, während die Schlüssel im verschlüsselten Tresor bleiben. Der Agent erhält daher nie den privaten SSH-Schlüssel. Activity- und Sessions-Journal entstehen aus einem verschlüsselten, hashverketteten Auditprotokoll. So kann der Genehmigungs- und Ausführungsweg angefordertes und beobachtetes Ziel statt nur einer befehlsähnlichen Zeichenkette bewahren.

Aufbewahrung allein reicht nicht. Definieren Sie testbare Invarianten: Die verwendete Adresse gehörte zum genehmigten Satz, Host und Port passten zum Ticket, die akzeptierte Identität wurde erfasst und jeder Wiederholungsversuch oder Sprung war autorisiert. Geben Sie dem Test CanonicalizeHostname, einen erlaubten CNAME, einen Match canonical-Block und zwei DNS-Antworten. Ändern Sie zwischen Vorprüfung und Verbindung einen Fakt und prüfen Sie, dass die Ausführung stoppt.

Der zu verhindernde Fehler ist alltäglich: Ein Agent fordert build an, ein Mensch erkennt den Spitznamen und genehmigt, und ein Client in einem anderen Netzwerk ergänzt ihn um eine andere Domain. Die Sitzung kann verschlüsselt bleiben und der Server einen gültigen Schlüssel für seinen Namen zeigen. Die Genehmigung ist trotzdem falsch. Nehmen Sie angeforderten Namen, endgültigen Namen und gewählte Adresse in dieselbe Entscheidung auf und lassen Sie den Connector beweisen, dass er genau diese Werte benutzt hat.