SSH-Agent-Weiterleitung oder Schlüssel kopieren: Was wirklich abfließt

Zwei verschiedene Ereignisse werden ein durchgesickerter SSH-Schlüssel genannt, und sie verlangen unterschiedliche Reaktionen. Die Authentifizierung mit öffentlichem Schlüssel sendet einen öffentlichen Schlüssel und eine mit dem privaten Schlüssel erstellte Signatur, der private Schlüssel ist also nie ein Feld der Anfrage. Die Agent-Weiterleitung legt etwas anderes offen, denn ein entfernter Host, der Ihren weitergeleiteten Agent erreicht, kann ihn um eine Signatur bitten, ohne den Schlüssel je zu halten. Behandelt man beides als ein Ereignis, landet man entweder bei einem sinnlosen Schlüsselwechsel oder bei einer Delegation, die weiterläuft.

Die Anmeldung mit öffentlichem Schlüssel überträgt eine Signatur, nicht den Schlüssel

Der Authentifizierungsaustausch trägt den öffentlichen Schlüssel des Nutzers und eine Signatur über Sitzungsdaten. Der Server prüft diese Signatur gegen den Schlüssel, dem er bereits vertraut, deshalb kann die private Hälfte über ein nicht vertrauenswürdiges Netz auf dem Client bleiben. Ein VPN-Betreiber, der den Tunnel beobachtet, sieht so oder so eine verschlüsselte SSH-Sitzung.

Das beschreibt das Protokoll, nicht die Vertrauenswürdigkeit jedes Endpunkts auf dem Weg. Lassen Sie die Host-Identitätsprüfung intakt, denn ein Client, der jeden Hostschlüssel akzeptiert, hat eine andere Kontrolle aufgegeben als die hier besprochene. Eine mitgelesene Sitzung und ein mitgelesener Schlüssel sind getrennte Befunde, und nur einer davon ist ein Verlust von Zugangsdaten. Halten Sie beides auch im Bericht in getrennten Sätzen.

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh -o StrictHostKeyChecking=yes [email protected]

Der erste Befehl gibt den öffentlichen Fingerabdruck aus, damit Sie ihn mit dem vergleichen können, was der Server auflistet. Der zweite macht die Hostschlüsselprüfung ausdrücklich, statt sich auf eine Voreinstellung zu verlassen, die niemand gelesen hat. Führen Sie beide aus, bevor Sie etwas an Schlüsseln ändern, damit die Ausgangslage dokumentiert ist.

Wer einen Agent weiterleitet, delegiert die Fähigkeit zu signieren

Ist die Weiterleitung aktiviert, erscheint auf dem entfernten Host ein Socket, und der lokale Agent beantwortet Anfragen, die darüber eintreffen. Wer diesen Socket während der Sitzung nutzen kann, kann sich gegenüber Hosts, die die geladenen Identitäten akzeptieren, als Sie ausweisen. Kein privater Schlüssel überquert dafür das Netz.

Die Fähigkeit ist die Exposition, nicht die Datei. Deshalb gehört die Weiterleitung zu einer benannten Aufgabe und einem benannten Host und nicht zu jeder Verbindung, die ein Laptop aufbaut. Ein Sprunghost, der die Verbindung ohne weitergeleiteten Agent durchreicht, beseitigt den Bedarf meist vollständig.

ssh-add -l
ssh -o ForwardAgent=no [email protected]
ssh -J [email protected] [email protected]

Der erste listet auf, welche Identitäten der Agent gerade hält, was man wissen sollte, bevor man seinen Socket an eine andere Maschine gibt. Der zweite verbindet ohne Delegation. Der dritte zeigt das Sprunghost-Muster, das die Weiterleitung oft ganz ersetzt.

Wählen Sie die Reaktion nach den Belegen, die Sie haben

Eine Signatur-Identität, die als exponiert gilt, verlangt den Prozess aus Ersetzen und Widerrufen und das Entfernen ihrer Akzeptanz bei den Diensten, die ihr vertraut haben. Das Löschen der Kopie auf dem Laptop lässt jede andere Kopie unberührt. Beginnen Sie bei den Diensten und räumen Sie dann die Clients auf.

Ein vorübergehendes Delegationsproblem ist enger. Beenden Sie die Weiterleitung, die nicht nötig war, und prüfen Sie mit dem Eigentümer des Vorfalls, welche Sitzungen und Identitäten sie abdeckte. Ein Schlüsselwechsel kann folgen, aber darüber entscheiden Belege und nicht die Sorge.

Kein beobachteter Export beweist nur, dass der Mechanismus, den Sie befürchteten, nicht aufgetreten ist. Er sagt nichts darüber, was ein Host am anderen Ende dieses Sockets sonst hätte tun können.

Halten Sie die Kontrollen im Bericht getrennt

Schützen Sie das private Material, begrenzen Sie, wer es um eine Signatur bitten kann, und halten Sie die geprüfte Identität der Gegenseite fest. Das sind drei Kontrollen, die einander verstärken, und keine ersetzt eine andere, wenn Sie erklären, was geschehen ist.

Ein kompromittierter Laptop oder eine privilegierte Anwendung darauf ist ein dritter Fall mit viel größerer Reichweite. Eine andere VPN-Route löst das nicht und stellt das Vertrauen in einen Schlüssel nicht wieder her, der von der Platte gelesen worden sein könnte.

Notieren Sie, welcher Komponente vertraut wurde, ob die Weiterleitung aktiv war und was tatsächlich beobachtet wurde. Dieser Eintrag macht die nächste Entscheidung verteidigbar, statt sie zu einer Vermutung darüber zu machen, was ein Leck bedeutet.