20.3. Die Abfolge der Vorg�nge einer SSH-Verbindung
Die folgende Abfolge von Vorg�ngen tragen zu einer unversehrten SSH-Kommunikation zwischen zwei Hosts bei:
Zun�chst wird eine sichere Transportschicht geschaffen, die dem Client-System anzeigt, dass es mit dem korrekten Server in Verbindung steht.
Die Transportschicht zwischen dem Client und dem Remote-Host ist mit einer symmetrischen Kodierung verschl�sselt.
Der Client authentifiziert sich gegen�ber dem Server.
Der Remote-Client kann nun sicher mit dem Remote-Host �ber die verschl�sselte Verbindung kommunizieren.
20.3.1. Transportschicht
Die wichtigste Aufgabe der Transportschicht ist es, die sichere und verschl�sselte Kommunikation zwischen zwei Rechnern bei und nach der Authentifizierung zu gew�hrleisten. Die Transportschicht verwaltet zu diesem Zweck die Verschl�sselung und Entschl�sselung der Daten und sorgt daf�r, dass die Datenpakete w�hrend des gesamten �bertragungsflusses gesch�tzt sind. Weiterhin kann diese Schicht die Daten komprimieren und damit die �bertragungsgeschwindigkeit erheblich erh�hen.
Sobald ein Client �ber ein SSH-Protokoll mit einem Server in Verbindung tritt, erfolgen verschiedene wichtige Vorg�nge, die dazu dienen, dass die beiden Systeme die Transportschicht korrekt aufbauen:
Austausch der Schl�ssel
Zu verwendenden Algorithmus f�r den �ffentlichen Schl�ssel bestimmen
Zu verwendenden Algorithmus f�r die symmetrische Verschl�sselung bestimmen
Zu verwendenden Algorithmus f�r die Authentifizierung der Mitteilungen bestimmen
Hash-Algorithmus bestimmen
Beim Austausch der Schl�ssel identifiziert sich der Server gegen�ber dem Client mit Hilfe eines eindeutigen Host-Schl�ssel. Hat der Client bisher noch nie mit diesem Server kommuniziert, ist der Server-Schl�ssel dem Client unbekannt und es wird keine Verbindung hergestellt. OpenSSH umgeht dieses Problem, indem es den Host-Schl�ssel des Servers akzeptiert, nachdem der Benutzer benachrichtigt wurde und pr�ft die Akzeptanz des neuen Host-Schl�ssels. Bei allen nachfolgenden Verbindungen wird dieser Schl�ssel mit der gespeicherten Version des Clients verglichen und auf diese Weise sichergestellt, dass der Client tats�chlich mit dem gew�nschten Server kommuniziert. Sollte der Host-Schl�ssel in Zukunft nicht mehr passen, muss der Benutzer die gespeicherte Version des Client entfernen, bevor eine Verbindung zustande kommen kann.
 | Achtung |
|---|
| | Es ist m�glich, dass ein Hacker sich zum Beispiel bei der ersten Verbindung als Server ausgeben kann, da der lokale Rechner zu diesem Zeitpunkt den gew�nschten Server und einen unerlaubt eingerichteten Server noch nicht unterscheiden kann. Um dies zu vermeiden, sollten Sie die Integrit�t eines neuen SSH-Servers pr�fen, indem Sie sich vor dem ersten Kontakt oder nachdem sich der Host-Schl�ssel ge�ndert hat, mit dem Server-Administrator in Verbindung setzen. |
Das SSH-Protokoll wurde konzipiert, um mit fast allen Algorithmen oder Formaten f�r allgemeine Schl�ssel verwendet werden zu k�nnen. Nachdem ein erster Schl�sselaustausch zwei Werte erstellt hat (einen Hash-Wert f�r den Austausch und einen gemeinsam genutzten, geheimen Wert), berechnen die beiden Systeme sofort neue Schl�ssel und Algorithmen, um die Authentifizierung und die in der Folge �ber die Verbindung gesendeten Daten zu sch�tzen.
Nachdem eine bestimmte Datenmenge mithilfe eines vorgegebenen Schl�ssels und Algorithmus �bertragen wurde (die genaue Menge h�ngt von der SSH-Implementation ab), erfolgt ein weiterer Schl�sselaustausch, der wiederum einen neuen Hash-Wert und einen neuen, gemeinsam genutzten, geheimen Wert generiert. Auch wenn eine unbefugte Person diese beiden Werte ermitteln sollte, m�sste sie diese Information bei jedem neuen Schl�sselaustausch ermitteln, um die Verbindung zu �berwachen.
20.3.2. Authentifizierung
Nachdem die Transportschicht einen sicheren Kanal geschaffen hat, in dem die Informationen zwischen den beiden Systemen �bertragen werden, teilt der Server dem Client die verschiedenen unterst�tzten Authentifizierungsmethoden mit (beispielsweise eine private, verschl�sselte Signatur oder die Eingabe eines Passworts). Der Client wird anschlie�end versuchen, sich anhand einer der unterst�tzten Methoden gegen�ber dem Server zu identifizieren.
SSH Server und Clients k�nnen konfiguriert werden, um verschiedene Arten der Authentifizierung zu erm�glichen. Diese Methode bietet daher jeder Seite das ideale Ma� an Kontrolle. Der Server kann entscheiden, welche Verschl�sselungsmethoden er auf der Grundlage seines Sicherheitsmodells unterst�tzen m�chte, und der Client kann festlegen, in welcher Reihenfolge er die verschiedenen verf�gbaren Authentifizierungsmethoden verwendet. Dank der Sicherheit der SSH-Transportschicht sind auch scheinbar unsichere Authentifizierungsmethoden, wie Host- und Passwort-basierte Authentifizierung, sicher.
20.3.3. Verbindungskan�le
Nach der erfolgreichen Authentifizierung �ber die SSH- Transportschicht werden mehrere Kan�le (channels) unter Verwendung von Multiplexing[1] ge�ffnet. Jeder der Kan�le bearbeitet die Mitteilungen f�r eine andere Terminal- oder weitergeleitete X11-Sitzung.
Sowohl Clients als auch Server k�nnen einen neuen Kanal erstellen, wobei jedem Kanal an jedem Ende eine unterschiedliche Nummer zugewiesen wird. Wenn eine Seite einen neuen Kanal �ffnen m�chte, wird die Nummer der entsprechenden Seite des Kanals mit der Anforderung �bermittelt. Diese Information wird von der anderen Seite gespeichert und verwendet, um eine bestimmte Mitteilung an diesen Kanal weiterzuleiten. Ziel dabei ist zu vermeiden, dass sich verschiedene Arten von Sessionen beeinflussen und die Kan�le geschlossen werden k�nnen, ohne die prim�re SSH-Verbindung zwischen den beiden Systemen zu unterbrechen.
Kan�le unterst�tzen auch die Datenflusskontrolle, was es ihnen erm�glicht, Daten geordnet zu senden und zu empfangen. Auf diese Weise werden Daten erst dann �ber den Kanal gesendet, wenn der Host-Rechner die Meldung erh�lt, dass der Kanal empfangsbereit ist.
Der Client und Server �bertragen automatisch die Eigenschaften jedes Kanals, je nachdem, welche Art von Dienst der Client abruft und wie der Benutzer mit dem Netzwerk verbunden ist. Dadurch ergibt sich eine gr��ere Flexibilit�t bei der Handhabung der verschiedenen Arten von Remote-Verbindungen ohne die Basis-Infrastruktur des Protokolls �ndern zu m�ssen.
