Im Internet können viele Operationen aus der Ferne durchgeführt werden, wie die Verwaltung von Servern oder die Übertragung von Dateien. Das Protokoll Telnet und die BSD r-Befehle (rsh, rlogin und rexec) erlauben die Durchführung dieser Tätigkeiten, mit dem großen Nachteil, dass die ausgetauschten Informationen in Klartext im Netzwerk in Umlauf sind, vor allem die ID (login) und das Passwort für den Zugriff auf den fremden Rechner. Ein Hacker, der sich im Netzwerk zwischen User und Fremdrechner befindet, kann den Traffic abhören, also ein Tool verwenden, das sniffer heißt und im Stande ist die Frames zu erfassen, die im Netzwerk in Umlauf sind, um die ID und das Passwort für den Zugriff auf den Fremdrechner zu erhalten.

Selbst wenn die ausgetauschten Informationen kein hohes Sicherheitsniveau haben, erhält der Hacker so Zufriff zu einem Account am Fremdrechner und kann eventuell auf dem Fremdrechner seine Rechte ausweiten , um einen Administratoren- Account zu erhalten (root).

Da es unmöglich ist, alle physikalischen Infrastrukturen zwischen dem User und dem fremden Rechner zu kontrollieren (Internet ist per definition ein offenes Netzwerk), besteht die einzige Lösung darin, eine Sicherheit auf der logischen Ebene (der Datenebene) zu nutzen.

Das Protokoll SSH (Secure Shell) löst dieses Problem, indem es Usern (oder TCP/IP Diensten) ermöglicht, auf einen Rechner zuzugreifen, und zwar über eine chiffrierte Verbindung (genannt tunnel).

Das Protokoll SSH

Das Protokoll SSH (Secure Shell) wurde 1995 vom Finnen Tatu Ylönen entwickelt.

Es ist ein Protokoll, das es einem Client (User oder auch Rechner) ermöglicht, eine interaktive Session auf einem Fremden Rechner (Server) zu erföffnen, um Befehle oder Dateien auf gesicherte Weise zu übermitteln :

• Die Daten, die zwischen Kunden und Server in Umlauf sind sind chiffriert, das garantiert ihre Vertraulichkeit (niemand außer Client und Server können die Informationen im Netzwerk lesen). Daher ist es nicht möglich, das Netzwerk abzuhören , mittels eines Frame-Analysators.
• Client und Server identifizieren sich beide, um sicherzustellen, dass die beiden kommunizierenden Rechner wirklich die sind, die sie glauben. So ist es einem Hacker nicht mehr möglich, die Identität von Client oder Server zu übernehmen (spoofing).

Die Version 1 des Protokolls (SSH1) von 1995 sollte als Alternative zu interaktiven Sessions (shells) wie Telnet, rsh, rlogin und rexec dienen. Dieses Protokoll hatte allerdings eine Schwachstelle, durch die Hacker Daten in den chiffrierten Strom einschleusen konnten. Aus diesem Grund wurde die Version 2 des Protokolls (SSH2) der IETF als Entwurf (draft) vorgeschlagen. Die Dokumente mit den Definitionen dieses Protokolls sind online verfügbar, auf http://www.ietf.org/html.charters/secsh-charter.html.

Secure Shell Version 2 bietet ebenfalls eine Lösung für die sichere Datenübertragung (SFTP, Secure File Transfer Protocol).

SSH ist einn Protokoll, also eine Standard-Methode zum Aufbau einer gesicherten Verbindung zwischen Rechnern. Daher gibt es viele Implementationen von SSH-Clients oder Servern. Einige sind kostenpflichtig, andere gratis oder open source : Sie finden einige SSH-Clients im Downloadbereich von CommentCaMarche.

Funktionierung von SSH

Der Aufbau einer SSH- Verbindung geschieht in mehreren Etappen :

• Zuerst identifizieren sich sowohl Kunde, als auch Server, um einen gesicherten Kanal aufzubauen (gesicherte Transportebene).
• Danach muss sich der Kunde beim Serverauthentifizieren , um eine Session zu erhalten.

Aufbau eines gesicherten Kanals

Der Aufbau einer gesicherten Transportebene beginnt mit einer Verhandlungsphase zwischen Kunden und Server, um sich auf die zu verwendenden Chiffriermethoden zu einigen. Das SSH Protokoll ist so konzipiert, dass es mit vielen Chiffrier-Algorithmen arbeiten kann, daher müssen Kunde und Server zunächst die von ihnen unterstützten Algorithmen austauschen.

Zum Aufbau der gesicherten Verbindung sendet der Server seinen öffentlichen Host-Key host key an den Kunden. Der Kunde generiert einen Session-Key von 256 Bit, chiffriert ihn mit dem öffentlichen Schlüssel des Servers, und sendet den chiffrierten Session Key und den verwendeten Algorithmus an den Server. Dieser dechiffriert den Session-Key mit seinem Privatschlüssel und sendet eine Bestätigungsnachricht, die mit dem Session- Key chiffriert ist. Von nun an werden alle Kommunikationen mit einem symmetrischen Chiffrier-Algorithmus verschlüsselt, der den gemeinsamen Session-Key von Kunden und Server verwendet.

Die Sicherheit der Übertragung beruht völlig auf der Versicherung, die Kunde und Server betreffend der Validität der Host-Keys haben. Bei der ersten Verbindung zu einem Server wird dem Kunden in der Regel eine Nachricht angezeigt, die um Annahme der Verbindung bittet (und gibt eventuell einen Hash des Host-Keys des Servers an) :

Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)?

Um eine wirklich gesicherte Session zu erhalten, sollte man den Serveradministrator mündlich dazu bitten, den angegebenen öffentlichen Schlüssel zu validieren. Wenn der User die Verbindung validiert, registriert der Kunde den Host-Key des Servers, damit dieser Schritt nicht wiederholt wird.

Umgekehrt kann, je nach Konfiguration, der Server manchmal prüfen, ob der Kunde wirklich derjenige ist, der er vorgibt, zu sein. Hat der Server eine Liste der Hosts, die sich verbinden dürfen, chiffriert er eine Nachricht mit dem öffentlichen Schlüssel des Kunden (der in seiner Datenbank der Host-Keys ist) um zu überprüfen, ob der Kunde ihn mit Hilfe seines privaten Schlüssels dechiffrieren kann (man spricht von challenge).

Die Authentifizierung

Steht die gesicherte Verbindung zwischen Kunden und Server, muss der Kunde sich beim Server identifizieren, um Zugriffsrechte zu erhalten. Es gibt dafür mehrere Methoden :

• die bekannteste Methode ist das traditionelle Passwort. Der Kunde sendet dem Server einen Usernamen und ein Passwort über die gesicherte Verbindung, der Server prüft, ob der jeweilige User Zugriff auf den Rechner hat und ob das angegebene Passwort gültig ist.
• eine weniger bekannte, aber flexiblere Lösung, ist die Nutzung öffentlicher Schlüssel. Wähld der Kunde die Authentifizierung durch Schlüssel, erzeugt der Server einen challenge und läasst den Kunden zugreifen, wenn es ihm geling, den challenge durch seinen Privatschlüssel zu entziffern.

Letzte Änderung am Dienstag 12 Mai 2009 à 17:09:52.Das Dokument mit dem titel « Kryptographie - Secure Shell (Protokoll SSH) » aus Kioskea (de.kioskea.net) zur verfügung gestellt wird unter den bedingungen der Creative Commons lizenz. Können Sie ändern, Kopien dieser Seite, unter den Bedingungen der Lizenz, als diese Bewertung deutlich.