SSH-Schlüssel kopiert oder Agent weitergeleitet? Zwei verschiedene Risiken

Eine Anmeldung, die über ein VPN einen SSH-Schlüssel verwendet, bedeutet nicht, dass der private Schlüssel an den Netzwerkbetreiber übergeben wurde, und diese Beruhigung ist enger, als sie gehört wird. Die Public-Key-Authentifizierung sendet einen öffentlichen Schlüssel und eine Signatur, die der Client lokal erzeugt. Agent-Weiterleitung ist eine andere Anordnung mit einer anderen Exposition, und sie kann eine nutzbare Authentifizierungsfähigkeit auf einer Maschine hinterlassen, die Sie nicht kontrollieren. Die Antwort, die Sie schulden, hängt davon ab, welches der beiden tatsächlich geschehen ist.

Was die Public-Key-Authentifizierung sendet

Beim Standardverfahren mit öffentlichem Schlüssel bietet der Client einen öffentlichen Schlüssel an, der Server entscheidet, ob er diesen Schlüssel akzeptiert, und der Client signiert eine Herausforderung mit dem privaten Schlüssel, der in seiner Datei oder seinem Agenten bleibt. Über das Netz gehen der öffentliche Schlüssel und die daraus entstehende Signatur. Nichts an diesem Austausch verlangt, dass der Server, der Tunnel oder jemand auf dem Weg das private Material hält.

Die Authentifizierungsspezifikation definiert diesen Nachweis, und der private Schlüssel ist kein Feld in der Anfrage.

Das ist eine Aussage über ein Protokoll, keine Charakterreferenz für jeden beteiligten Endpunkt. Die Prüfung der Host-Identität muss weiterhin intakt sein, denn ein Server, der nicht beweisen kann, wer er ist, sammelt möglicherweise Signaturen für einen Zweck, den Sie nicht beabsichtigt haben. Eine gemietete VM, ein geerbter Bastion und ein Laptop mit einer unbekannten Erweiterung sind drei getrennte Vertrauensfragen. Halten Sie sie getrennt von der kryptografischen, die tatsächlich geklärt ist.

Was die Agent-Weiterleitung delegiert

Agent-Weiterleitung öffnet einen Kanal vom entfernten Host zurück zum Agenten auf Ihrer Maschine, sodass Prozesse auf diesem Host den Agenten um eine Signatur bitten können, ohne jemals den privaten Schlüssel zu halten. Der Schlüssel bleibt, wo er ist, die Fähigkeit nicht. Alles, was diesen weitergeleiteten Socket auf dem entfernten Host erreichen kann, kann für die Lebensdauer der Sitzung Authentifizierungsvorgänge als eine der geladenen Identitäten anfordern. Das ist delegierte Vollmacht, weshalb Weiterleitung eine engere Politik verdient als die Übergabe eines öffentlichen Schlüssels.

Eine kopierte Schlüsseldatei ist eine Offenlegung. Ein weitergeleiteter Agent ist eine Erlaubnis, und die beiden brauchen unterschiedliche Antworten.

Aktivieren Sie die Weiterleitung für einen benannten Bedarf und benannte Hosts, und prüfen Sie, was der Client tatsächlich tut, statt was die Konfiguration zu sagen scheint. Es zählen die effektiven Einstellungen, denn ein Host-Block überschreibt still einen globalen Standard. Dieselbe Logik gilt auf der Serverseite, die die Weiterleitung ganz ablehnen kann, wenn die Bereitstellung sie nie braucht.

Prüfen Sie die Belege, bevor Sie eine Antwort wählen

Wenn angenommen wird, dass eine private Schlüsseldatei oder eine gleichwertige Signaturidentität offengelegt wurde, ist die Antwort Ersetzung und Widerruf über den Prozess Ihrer Organisation, plus Entfernung ihrer Akzeptanz aus jedem Dienst, der ihr vertraut hat. Das Löschen einer lokalen Kopie macht die Kopien nicht ungültig, die Sie nicht sehen.

Wenn die Sorge ein vorübergehender Agentenzugriff ist, ist die Antwort enger: Beenden Sie die unnötige Delegation, prüfen Sie die beteiligten Sitzungen und Identitäten, und lassen Sie den Incident-Verantwortlichen entscheiden, ob eine Ersetzung gerechtfertigt ist. Belege zählen hier, denn kein beobachteter Export beweist nicht, dass keine Authentifizierung missbraucht wurde, und eine bloße Pfadänderung ist keine Diagnose eines gestohlenen Schlüssels. Notieren Sie, welcher Komponente vertraut wurde, ob die Weiterleitung aktiviert war und was tatsächlich beobachtet wurde. Wählen Sie dann die Antwort, die zu diesem Protokoll passt, statt der dramatischsten verfügbaren.

ssh-add -l
ssh -G host.example | grep -i forwardagent

Führen Sie sie vor und nach einer Änderung aus, damit der Vergleich etwas bedeutet. Eine früher aufgebaute Sitzung behält die Delegation, die ihr gewährt wurde, was auch immer die Einstellungen jetzt sagen.

Zwei Kontrollen, die nicht austauschbar sind

Privates Material schützen, begrenzen, wer um eine Signatur bitten kann, und die Identität des Gegenübers prüfen sind drei verwandte Kontrollen, und keine ersetzt eine andere. Ein Team, das die Weiterleitung entfernt, ohne Host-Schlüssel zu prüfen, hat die Hälfte eines Problems behoben. Ein Team, das einen Schlüssel rotiert, weil sich die Route geändert hat, hat nichts behoben.

Ein kompromittierter Endpunkt ist eine vierte Frage, denn privilegierte Software auf Ihrer eigenen Maschine kann erheblich mehr tun, als Pakete zu beobachten.

Ordnen Sie den Vorfall diesen Kategorien zu, bevor Sie etwas anfassen, und geben Sie jeder einen Verantwortlichen. Führen Sie ein kurzes Protokoll darüber, was vertraut, was delegiert und was geprüft wurde, denn dieses Protokoll macht die nächste Überprüfung billig statt zu einer weiteren Debatte. Wenn eine Kategorie unbekannt ist, schreiben Sie unbekannt statt den harmlosen Fall anzunehmen. Die Unterscheidung ist praktisch, nicht akademisch: Sie entscheidet, ob Sie ein Zugangsdatum ersetzen, eine Sitzung widerrufen oder einfach die Weiterleitung beenden.