Einführung
SSH-Agent ist Teil von OpenSSH. In diesem Beitrag werde ich erklären, was ein Agent ist, wie er verwendet wird und wie er funktioniert, um Ihre Schlüssel zu schützen. Ich werde auch die Agentenweiterleitung und deren Funktionsweise beschreiben. Ich werde Ihnen dabei helfen, das Risiko der Verwendung der Agentenweiterleitung zu verringern, und eine Alternative zur Agentenweiterleitung vorstellen, die Sie beim Zugriff auf Ihre internen Hosts über Bastionen verwenden können.Was ist ein SSH-Agent?
ssh-agent
Ist ein Schlüsselmanager für SSH. Es speichert Ihre Schlüssel und Zertifikate unverschlüsselt und einsatzbereit im Speicher ssh
. Dadurch müssen Sie nicht jedes Mal ein Kennwort eingeben, wenn Sie eine Verbindung zum Server herstellen. Es wird im Hintergrund auf Ihrem System ausgeführt, getrennt von ssh
und startet normalerweise beim ersten Start ssh
.Der SSH-Agent schützt geheime Schlüssel, da dies nicht der Fall ist :- Es werden keine Schlüsselinformationen auf die Festplatte geschrieben.
- Sie können Ihre privaten Schlüssel nicht exportieren.
Im Agent gespeicherte geheime Schlüssel können nur für einen Zweck verwendet werden: das Signieren einer Nachricht.Aber wenn ein Agent nur Nachrichten signieren kann, wie verschlüsselt und entschlüsselt SSH den Datenverkehr?In der ersten Studie zu öffentlichen und privaten SSH-Schlüsseln wird natürlich davon ausgegangen, dass SSH diese Schlüsselpaare zum Ver- und Entschlüsseln des Datenverkehrs verwendet. Genau das habe ich mir gedacht. Dies ist jedoch nicht der Fall. Das SSH-Schlüsselpaar wird nur zur Authentifizierung während der ersten Verbindung verwendet.So überprüfen Sie beispielsweise einen Benutzerschlüssel während einer SSH-Verbindung aus Serversicht:- Der Client stellt dem Server einen öffentlichen Schlüssel zur Verfügung.
- Der Server generiert und sendet eine kurze zufällige Nachricht, in der er den Client auffordert, sie mit einem privaten Schlüssel zu signieren.
- Der Client fordert den SSH-Agenten auf, die Nachricht zu signieren, und sendet das Ergebnis an den Server zurück.
- Der Server überprüft die Signatur mit dem öffentlichen Schlüssel des Clients.
- Jetzt hat der Server den Beweis, dass der Client den privaten Schlüssel besitzt.
Später, während des Verbindungsprozesses, wird eine Reihe neuer, kurzlebiger und symmetrischer Schlüssel generiert, die zum Verschlüsseln des SSH-Sitzungsverkehrs verwendet werden. Diese Schlüssel dauern möglicherweise nicht einmal eine ganze Sitzung. Das Rekey-Ereignis tritt in regelmäßigen Abständen auf.Agentenprotokoll
SSH verwendet einen Unix-Domänensocket, um über das SSH-Agentenprotokoll mit dem Agenten zu kommunizieren . Die meisten Leute verwenden die ssh-agent
mit OpenSSH gelieferte, aber es gibt viele Open-Source-Alternativen.Das Agentenprotokoll ist so einfach, dass Sie in ein oder zwei Tagen einen einfachen SSH-Agenten schreiben können. Es hat nur wenige grundlegende Operationen:- Fügen Sie ein reguläres Schlüsselpaar hinzu (öffentliche und entschlüsselte private Schlüssel).
- Fügen Sie ein begrenztes Schlüsselpaar hinzu (öffentliche und entschlüsselte private Schlüssel).
- Schlüssel (regulär oder begrenzt) von der Smartcard hinzufügen (nur öffentlicher Schlüssel)
- Schlüssel löschen
- Auflistung der im Agenten gespeicherten Schlüssel
- Signieren einer Nachricht mit einem im Agenten gespeicherten Schlüssel
- Sperren oder entsperren Sie einen gesamten Agenten mit einem Passwort
Was ist ein begrenzter Schlüssel? Dies ist normalerweise ein Schlüssel, der entweder eine begrenzte Lebensdauer hat oder eine explizite Bestätigung durch den Benutzer erfordert, wenn er verwendet wird.Der Befehl ssh-add
ist Ihr Gateway zum SSH-Agenten. Er führt alle diese Operationen mit Ausnahme der Unterschrift aus. Wenn Sie ssh-add ohne Parameter ausführen, durchsucht es Ihr Home-Verzeichnis nach einigen Standardschlüsseln und fügt sie Ihrem Agenten hinzu. Standardmäßig wird gesucht nach:~/.ssh/id_rsa
~/.ssh/id_ed25519
~/.ssh/id_dsa
~/.ssh/id_ecdsa
Sobald Sie die Schlüssel zum Schlüsselbund hinzufügen, werden sie automatisch verwendet ssh
.ssh-
und der mit macOS geliefertessh-agent
macOS-Schlüsselbund kann Passphrasen für Schlüssel im macOS-Schlüsselbund speichern, wodurch das erneute Hinzufügen von Schlüsseln zum Agenten nach einem Neustart noch einfacher wird. Abhängig von Ihren Schlüsselbundeinstellungen müssen Sie sie möglicherweise nach einem Neustart noch entsperren. Führen Sie den Befehl aus, um Schlüsselpassphrasen im Schlüsselbund zu speichern ssh-add -K [ ]
. Passphrasen werden normalerweise in „Lokalen Elementen“ gespeichert. ssh-agent
verwendet diese gespeicherten Passphrasen bei Bedarf automatisch.Was ist Agentenweiterleitung?
Mit der Agentenweiterleitungsfunktion kann Ihr lokaler SSH-Agent über eine vorhandene SSH-Verbindung kommunizieren und sich transparent bei einem Remote-Server authentifizieren. Angenommen, Sie melden sich über SSH bei EC2 an und möchten von dort aus ein privates GitHub-Repository klonen. Ohne Agentenweiterleitung müssen Sie eine Kopie Ihres privaten GitHub-Schlüssels auf dem EC2-Host speichern. Wenn der Agent umgeleitet wird, kann der SSH-Client auf EC2 die Schlüssel auf Ihrem lokalen Computer zur Authentifizierung auf GitHub verwenden.So funktioniert die Agentenweiterleitung
Erstens ein kleiner Hintergrund. SSH-Verbindungen können mehrere Kanäle haben. Hier ein allgemeines Beispiel: Eine interaktive Verbindung zum Bastion-Host (Sprungbox) wird auf einem Kanal durchgeführt. Wenn die Agentenweiterleitung für die Verbindung aktiviert ist (normalerweise über ssh -A
), wird im Hintergrund ein zweiter Kanal geöffnet, um alle Agentenanforderungen an Ihren lokalen Computer weiterzuleiten.In Bezug auf ssh
gibt es keinen Unterschied zwischen Remote und lokal ssh-agent
. SSH überprüft immer die Umgebungsvariable $SSH_AUTH_SOCK
, um den Unix-Domänensocket für den Agenten zu finden. Wenn Sie eine Verbindung zu einem Remote-Host mit aktivierter Agentenweiterleitung herstellen, erstellt SSHD einen Remote-Unix-Domänensocket, der dem Agentenweiterleitungskanal zugeordnet ist, und exportiert diesen $SSH_AUTH_SOCK
, der darauf verweist.
Die Weiterleitung von Agenten ist mit einem bestimmten Risiko verbunden
Wenn Sie einen ssh-agent
Unix- Domain-Socket auf einen Remote-Host umleiten , stellt dies ein Sicherheitsrisiko dar: Jeder Benutzer mit Root-Zugriff auf den Remote-Host kann über den Socket diskret auf Ihren lokalen SSH-Agenten zugreifen. Sie können Ihre Schlüssel verwenden, um sich auf anderen Computern im Netzwerk auszugeben.Hier ist ein Beispiel, wie dies aussehen könnte:
So reduzieren Sie Ihr Risiko durch Agentenweiterleitung
Hier sind einige Möglichkeiten, um die Agentenumleitung sicherer zu machen:- Nicht
ForwardAgent
standardmäßig aktivieren.
Blockieren Sie Ihren SSH-Agenten, wenn Sie die Agentenweiterleitung verwenden. ssh-add -x
blockiert den Agenten mit einem Passwort und ssh-add -X
entsperrt es. Wenn Sie mit einer Agentenweiterleitung mit einem Remote-Host verbunden sind, kann niemand Ihren Agenten ohne Kennwort eingeben.Oder verwenden Sie einen alternativen SSH-Agenten, der Sie fragt, wann er verwendet wird. Sekey verwendet Touch ID unter macOS, um Schlüssel in der MacBook Pro-Sicherheitsenklave zu speichern.Oder verwenden Sie die Agentenweiterleitung überhaupt nicht. Wenn Sie versuchen, über Bastion auf interne Hosts zuzugreifen, gibt ProxyJump
es für diesen Anwendungsfall eine viel sicherere Alternative. (siehe unten)Verwendung ProxyJump
: eine sicherere Alternative
Wenn Sie durch Bastion-Host (Jumpbox) gehen möchten, brauchen Sie wirklich keine Agent'a-Weiterleitung. Der beste Ansatz ist die Verwendung der Richtlinie ProxyJump
.Anstatt den Agenten über einen separaten Kanal ProxyJump
umzuleiten , leitet er die Standardeingabe und -ausgabe Ihres lokalen SSH-Clients über Bastion und weiter zum Remote-Host um. So funktioniert das:- Führen Sie
ssh -J bastion.example.com cloud.computer.internal
die Verbindung aus, um eine Verbindung cloud.computer.internal
über Ihren Bastion-Host herzustellen bastion.example.com
. cloud.computer.internal
Ist der Hostname, der durch Suchen von DNS auf gefunden werden kann bastion.example.com
. - Ihr SSH-Client verwendet die Schlüssel Ihres Agenten, um eine Verbindung herzustellen
bastion.example.com
. - Nach dem Verbinden von SSHD mit Bastion wird eine
cloud.computer.internal
Verbindung zu Ihrem lokalen SSH-Client hergestellt und diese Verbindung an diesen übertragen. - Ihr lokaler SSH-Client geht die Verbindung erneut durch, diesmal mit
cloud.computer.internal
Sie können es sich als SSH in einer SSH-Sitzung vorstellen. außer dass ssh niemals auf bastion läuft. Stattdessen wird eine sshd
Verbindung zu cloud.computer.internal
dieser Verbindung (Standardeingabe und -ausgabe) hergestellt und die Steuerung an Ihre lokale SSH zurückgegeben, die dann eine zweite Verbindung herstellt.ProxyJump konfigurieren Sagenwir Bastion-Host bastion.example.com
. Ich kann meine ~/.ssh/config
so konfigurieren :Host bastion.example.com
User carl
Host *.computer.internal
ProxyJump bastion.example.com
User carl
Dann renne ich einfach los ssh cloud.computer.internal
, um über Bastion eine Verbindung zum internen Ziel herzustellen - ohne Agentenweiterleitung.Wenn ProxyJump nicht funktioniert ...Ältere Versionen von SSH und SSHD (vor Version 7.2, veröffentlicht im Jahr 2016) werden nicht unterstützt ProxyJump
. Sie können jedoch eine äquivalente Operation mit ProxyCommand
und netcat ausführen . Hier ist ein Beispiel:ssh -o ProxyCommand="ssh bastion.example.com nc %h %p" cloud.computer.internal
Die Magie hier ist, dass SSH selbst der Proxyserver ist, den Sie für SSH verwenden. Der Teil nc %h %p
öffnet einfach die Raw-Socket-Verbindung zu cloud.computer.internal
Port 22. Die Standardeingabe / -ausgabe des übergeordneten ssh-Befehls wird direkt an übergeben, ProxyCommand
damit sich der übergeordnete ssh über eine Proxy-Verbindung beim internen Host authentifizieren kann.
Erfahren Sie in SkillFactory-Onlinekursen, wie Sie einen begehrten Beruf von Grund auf neu erlernen oder Ihre Fähigkeiten und Ihr Gehalt verbessern können:Weiterlesen