Informationen zu Secure Shell Packet Exchange

Einleitung

Dieses Dokument beschreibt den Austausch auf Paketebene während der Secure Shell (SSH)-Aushandlung.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse folgender grundlegender Sicherheitskonzepte verfügen:

• Authentifizierung
• Vertraulichkeit
• Integrität
• Wichtige Methoden für den Austausch

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

SSH-Protokoll

Das SSH-Protokoll ist eine Methode zur sicheren Remoteanmeldung von einem Computer zu einem anderen. SSH-Anwendungen basieren auf einer Client-Server-Architektur und verbinden eine SSH-Client-Instanz mit einem SSH-Server.

SSH-Austausch

1. Der erste Schritt von SSH wird als Identification String Exchange.

 1.1. Der Client erstellt ein Paket und sendet es an den Server, der Folgendes enthält:

•  Version des SSH-Protokolls
•  Software-Version

Clientprotokollversion und Softwareversion

1.2. Der Server antwortet mit seinem eigenen Identification String Exchange, einschließlich der Version des SSH-Protokolls und der Softwareversion.

Serverprotokoll- und Softwareversion

2. Der nächste Schritt ist  Algorithm Negotiation. In diesem Schritt handeln sowohl Client als auch Server diese Algorithmen aus:

• Schlüsselaustausch
• Verschlüsselung
• Hash-basierter Message Authentication Code (HMAC)
• Komprimierung

2.1. Der Client sendet eine Key Exchange Init-Nachricht an den Server, in der er die unterstützten Algorithmen angibt. Die Algorithmen werden nach Präferenz geordnet aufgelistet.

Clientschlüsselaustausch-Initialisierung

Vom Client unterstützte Algorithmen

2.2. Der Server antwortet mit einer eigenen Meldung zur Initialisierung des Schlüsselaustauschs, in der die unterstützten Algorithmen aufgeführt sind.

2.3. Da diese Meldungen gleichzeitig ausgetauscht werden, vergleichen beide Parteien ihre Algorithmus-Listen. Wenn die von beiden Seiten unterstützten Algorithmen übereinstimmen, fahren sie mit dem nächsten Schritt fort. Wenn keine exakte Übereinstimmung vorliegt, wählt der Server den ersten Algorithmus aus der Liste des Clients aus, den er ebenfalls unterstützt.

Anmerkung: Wenn sich Client und Server nicht auf einen gemeinsamen Algorithmus einigen können, schlägt der Schlüsselaustausch fehl.

Serverschlüsselaustausch-Initialisierung

3. Als Nächstes treten beide Seiten in die Key Exchange Phase ein, um mithilfe des DH-Schlüsselaustauschs einen gemeinsamen geheimen Schlüssel zu generieren und den Server zu authentifizieren:

3.1. Der Client generiert ein Tastenpaar Public and Private, und sendet den öffentlichen DH-Schlüssel im Diffie-Hellman Group Exchange-Init-Paket. Dieses Schlüsselpaar wird für die Berechnung des geheimen Schlüssels verwendet.

Client Diffie-Hellman Group Exchange-Initialisierung

3.2. Der Server generiert sein eigenes Public and Private kSchlüsselpaar. Er verwendet den öffentlichen Schlüssel des Clients und sein eigenes Schlüsselpaar, um den gemeinsamen geheimen Schlüssel zu berechnen.

3.3. Der Server berechnet auch einen Exchange-Hash mit folgenden Eingaben:

• Client-Identifizierungszeichenfolge
• Server-Identifizierungszeichenfolge
• Payload der Client Key Exchange-Initialisierung 
• Nutzlast der Server Key Exchange-Initialisierung 
• Öffentlicher Serverschlüssel von Hostschlüsseln (RSA-Schlüsselpaar)
• Öffentlicher Client-DH-Schlüssel
• Öffentlicher Server-DH-Schlüssel
• Gemeinsamer geheimer Schlüssel

3.4. Nach dem Computing-Hash signiert der Server es mit seinem privaten RSA-Schlüssel.

3.5. Der Server erstellt eine Diffie-Hellman Group Exchange-Nachricht, die Folgendes enthält:

•  Öffentlicher RSA-Serverschlüssel (zur Unterstützung des Clients bei der Serverauthentifizierung)
•  Öffentlicher DH-Schlüssel des Servers (zur Berechnung des gemeinsamen geheimen Schlüssels)
•  HASH (zur Authentifizierung des Servers und zum Nachweis, dass der Server den gemeinsamen geheimen Schlüssel generiert hat, da der geheime Schlüssel Teil der Hash-Berechnung ist)

Server Diffie-Hellman Group Exchange-Antwort

3.6. Nach dem Empfang der Diffie-Hellman Group Exchange Reply berechnet der Client den Hash auf die gleiche Weise und vergleicht ihn mit dem empfangenen Hash, wobei er ihn mithilfe des öffentlichen RSA-Schlüssels des Servers entschlüsselt.

3.7. Vor der Entschlüsselung des empfangenen HASH muss der Client den öffentlichen Schlüssel des Servers überprüfen. Diese Verifizierung erfolgt über ein digitales Zertifikat, das von einer Zertifizierungsstelle (Certificate Authority, CA) signiert wird. Wenn das Zertifikat nicht vorhanden ist, muss der Client entscheiden, ob er den öffentlichen Schlüssel des Servers akzeptiert.

Hinweis: Wenn Sie SSH verwenden, um sich zum ersten Mal bei einem Gerät anzumelden, das kein digitales Zertifikat verwendet, können Sie auf ein Popup-Fenster stoßen, in dem Sie aufgefordert werden, den öffentlichen Schlüssel des Servers manuell zu akzeptieren. Um zu vermeiden, dass dieses Popup bei jeder Verbindung angezeigt wird, können Sie den Host-Schlüssel des Servers Ihrem Cache hinzufügen.

Öffentlicher Serverschlüssel

4. Da der gemeinsame geheime Schlüssel jetzt generiert wurde, verwenden beide Seiten ihn, um die folgenden Schlüssel abzuleiten:

•  Verschlüsselungsschlüssel
•  IV-Schlüssel - Dies sind Zufallszahlen, die als Eingabe für symmetrische Algorithmen verwendet werden, um die Sicherheit zu erhöhen.
•  Integritätsschlüssel

Das Ende des Schlüsselaustauschs wird durch den Austausch der NEW KEYS Nachricht signalisiert, die jeden Teilnehmer darüber informiert, dass alle zukünftigen Nachrichten verschlüsselt und mit diesen neuen Schlüsseln geschützt werden.

Neue Schlüssel für Client und Server

5. Der letzte Schritt ist die Serviceanfrage. Der Client sendet ein SSH-Dienstanforderungspaket an den Server, um die Benutzerauthentifizierung zu initiieren. Der Server antwortet mit einer SSH Service Accept-Nachricht, in der der Client zur Anmeldung aufgefordert wird. Dieser Austausch erfolgt über den eingerichteten sicheren Kanal.

Zugehörige Informationen

• Konfigurieren von SSH auf Routern und Switches
• Secure Shell (SSH) Transport Layer Protocol
• Technischer Support und Downloads von Cisco