Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux Rerenzhandbuch- Die Abfolge der Vorg�nge einer SSH-Verbindung

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.

AchtungAchtung
 

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.

Fu�noten

[1]

Eine Multiplex-Verbindung besteht aus verschiedenen Signalen, die �ber ein gemeinsam genutztes Medium gesendet werden. Bei SSH werden verschiedene Kan�le �ber eine gemeinsame, verschl�sselte Verbindung gesendet.

 
 
  Published under the terms of the GNU General Public License Design by Interspire