Sichern Sie Ihre Verbindungen mit SSH

ArticleCategory:

AuthorImage:

TranslationInfo:[Author and translation history]

original in fr Bernard Perrot  

fr to en Guy Passemard  

en to de Hermann-Josef Beckers

AboutTheAuthor

Abstract

Dieser Artikel wurde zuerst in einer Spezialausgabe des franz�sischen Linux-Magazins publiziert, deren Schwerpunkt auf Sicherheit lag. Der Editor, die Autoren und die �bersetzer haben LinuxFocus freundlicherweise gestattet, jeden Artikel aus dieser Spezialausgabe zu publizieren. Dementsprechend wird LinuxFocus diese Artikel herausbringen, sobald sie ins Englische �bersetzt sind. Dank an alle Menschen, die an dieser Arbeit beteiligt sind. Dieser Abstrakt wird f�r jeden Artikel reproduziert, der aus der gleichen Quelle stammt.

Die Ambition dieses Artikels ist ein guter Ausblick auf SSH, warum es benutzt wird. Dies ist kein Tutorial oder ein Installations-Handbuch, eher eine Einf�hrung in das Vokabular und die Eigenschaften von SSH. Die Verweise und Dokumentation in diesem Artikel geben Ihnen alle Einzelheiten der Implementation.

ArticleIllustration:

ArticleBody:[The article body]

Wof�r wird SSH benutzt?

Vor allem (und historisch) ist SSH (der Befehl ssh) eine sichere Version der Befehle rsh (und rlogin). SSH bedeutet "Secure SHell" wie rsh f�r "Remote SHell" steht. Wenn Ihnen rsh leichten Shell-Zugang zu einem entfernten Rechner geben kann, aber ohne Mechanismen f�r die Benutzerauthentifizierung, bietet Ihnen ssh den gleichen Dienst, jedoch mit hoher Sicherheit auf mehreren Ebenen.

Wenn wir kurz an einen Benutzer denken, der nicht mehr wissen (oder tun) m�chte, k�nnten wir hier aufh�ren und sagen, dass der Administrator seinen Job getan und die Software installiert hat (was heute sehr leicht ist), dann brauchen Sie nur noch den Befehl ssh als Ersatz f�r telnet, rsh oder rlogin, und alles funktioniert wie vorher, aber mit viel mehr Sicherheit.

Wenn Sie bisher

% rlogin serveur.org (oder telnet serveur.org)

benutzt haben, geben Sie jetzt ein:

% ssh serveur.org

und es ist schon viel besser!

Um diese kurze Einf�hrung zu beenden, will ich nur feststellen, dass bis heute alle Sicherheits-Zwischenf�lle, die durch die einfache Benutzung von SSH anstelle von rsh (rlogin,telnet) h�tten vermieden werden k�nnen, nur eine Konsequenz der Nachl�ssigkeit des Opfers sind.

Was sind die Bed�rfnisse?

Um mehr auf Einzelheiten einzugehen, hier sind einige der kritischsten und schwachen Aspekte interaktiver Verbindungen, die man gel�st haben m�chte:

• Vor allem sollte man vermeiden, dass Passw�rter �bers Netz �bertragen werden;
• Benutzung starker Authentifizierung in verbundenen Systemen, nicht nur basierend auf dem Namen oder der IP-Adresse, die leicht gef�lscht werden k�nnen;
• Ausf�hrung entfernter Befehle in vollst�ndiger Sicherheit;
• Schutz von Datei-�bertragungen;
• sichere X11-Sitzungen, die sehr angreifbar sind.

Als Antwort auf diese Bed�rfnisse gibt es einige L�sungen, die nicht wirklich zufriedenstellen:

• Die "R-Befehle": diese Befehle �bertragen das Passwort nicht im Klartext, aber der benutzte "rhosts"-Mechanismus besitzt zahlreiche Sicherheitsprobleme;
• Die "Einmal-Passw�rter (One Time Password),(OTP)" sch�tzen nur die Authentifizierung, nicht aber die folgenden Daten. Obwohl dieses System aus Sicherheitssicht sehr attraktiv ist, unterliegt es Beschr�nkungen, die eine Akzeptanz durch die Benutzer schwierig machen. Konsequenterweise wird es meist in Umgebungen benutzt, die keinen ergonomischen Erw�gungen unterliegen;
• telnet mit Verschl�sselung: diese L�sung ist nur anwendbar auf ... telnet. Au�erdem umfasst dies nicht das X11-Protokoll, was eine oft ben�tigte Erg�nzung ist.

Und dann gibt es SSH, eine gute L�sung f�r:

• Ersatz der R-Befehle: ssh anstelle von rsh und rlogin, scp mit rcp, sftp mit ftp;
• benutzt starke Authenfitizierung, basiert auf Verschl�sselungs-Algorithmen unter Benutzung von �ffentlichen Schl�sseln (sowohl f�r Systeme wie f�r Benutzer);
• erm�glicht die Umleitung des TCP-Datenstroms in einem Sitzungs-"Tunnel" und in X11-Sitzungen, hier kann dies automatisch erfolgen;
• Verschl�sselt den Tunnel und komprimiert ihn, wenn dies n�tig ist und angefordert wird.

SSH Version 1 und SSH Version 2

Da nichts in dieser Welt perfekt ist, gibt es zwei inkompatible Versionen des SSH-Protokolls: die 1.x-Version (1.3 und 1.5) und die 2.0-Version. Der Wechsel von einer zur anderen Version ist f�r die Benutzerin nicht schmerzhaft, wenn sie die richtigen Clients und Server zur Verf�gung hat, die mit der Version kompatibel sind.

Das SSH Version 1-Protokoll ist integriert, w�hrend SSH Version 2 das vorherige Protokoll in drei "Schichten" redefiniert hat.

1. SSH Transport Layer Protocol (SSH-TRANS)
2. SSH Authentication Protocol (SSH-AUTH)
3. SSH Connection Protocol (SSH-CONN)

Jede Protokollschicht ist speziell in einem Dokument (Draft) definiert, das von der IETF normiert wurde, gefolgt von einem vierten Dokument, das die Architektur beschreibt (SSH Protocol Architecture, SSH-ARCH). Man findet alle Details unter: http://www.ietf.org/html.charters/secsh-charter.html

Ohne zu sehr in die Einzelheiten zu gehen, dies finden Sie in SSHv2:

• die Transport-Ebene bietet Integrit�t, Verschl�sselung und Komprimierung, die Authentifizierung von Systemen
• die Authentifizierungs-Ebene bietet ... Authentifizierung (Passwort, Host-basiert, �ffentlicher Schl�ssel)
• die Verbindungs-Ebene, die den Tunnel verwaltet (Shell, SSH-agent, Port-Weiterleitung, Flu�steuerung).

Die wichtigsten technischen Unterschiede zwischen SSH Version 1 und 2 sind:

Handhabung eines Schl�sselbundes

Lassen Sie mich eben die SSH-Schl�sseltypen definieren:

• Benutzer-Schl�ssel: Ein Schl�sselpaar, das aus einem �ffentlichen und einem privaten Schl�ssel besteht (beide asymmetrisch), Benutzer-definiert und permanent (auf Platte gespeichert). Dieser Schl�ssel erlaubt Benutzer-Authentifizierung, wenn die Authentifizierungsmethode �ffentlicher Schl�ssel genutzt wird (weiter unten beschrieben).
• Rechner-Schl�ssel: auch ein aus �ffentlichem und privatem Schl�ssel bestehendes Schl�sselpaar (beide asymmetrisch), aber zur Installations-/Konfigurations-Zeit vom Systemadministrator definiert und permanent (auf Platte gespeichert). Dieser Schl�ssel erlaubt Authentifizierung zwischen Systemen.
• Server-Schl�ssel: erneut ein aus �ffentlichem und privatem Schl�ssel bestehendes Schl�sselpaar (beide asymmetrisch), aber von einem D�mon beim Systemstart generiert und regelm��ig erneuert. Dieser Schl�ssel verbleibt im Hauptspeicher, um den Austausch des Sitzungsschl�ssels in SSHv1 zu sichern (In SSHv2 gibt es keinen Server-Schl�ssel, da hier der Austausch �ber das Diffie-Hellman-Protokoll gesichert wird).
• Sitzungs-Schl�ssel: dies ist ein geheimer Schl�ssel, der vom symmetrischen Verschl�sselungs-Algorithmus zur Verschl�sselung des Kommunikations-Kanals genutzt wird. Wie in modernen kryptografischen Produkten �blich, ist dieser Schl�ssel zuf�llig und verg�nglich. SSHv1 benutzt einen Schl�ssel per Sitzung auf beiden Seiten. SSHv2 benutzt zwei regenerierte Sitzungsschl�ssel, einen auf jeder Seite.

Die Benutzerin f�gt einen Passwort-Satz hinzu, der den privaten Schl�ssel der erw�hnten Schl�ssel-Paare sch�tzt. Dieser Schutz wird erreicht durch die Verschl�sselung der Datei mit dem privaten Schl�ssel durch einen symmetrischen Algorithmus. Der zur Verschl�sselung der Datei genutzte geheime Schl�ssel wird aus dem Passwort-Satz abgeleitet.

Authentifizierungs-Methoden

Es gibt verschiedene Benutzer-Identifikations-Methoden, die Wahl wird in Abh�ngigkeit von den Anforderungen der Sicherheits-Regeln getroffen. Die Authentifizierungsmethoden werden in der Konfigurationsdatei des Servers aktiviert (oder auch nicht). Hier sind die Hauptkategorien:

• "telnet �hnlich":

  Dies ist die "traditionelle" Passwort-Methode: Beim Verbinden wird der Benutzer, nachdem er sich angemeldet hat, nach einem Passwort gefragt, das an den Server weitergeleitet wird, der es mit dem Passwort vergleicht, das dem Benutzer zugeordnet ist. Das verbleibende Problem (das eine astronomische Anzahl von Piratereien im Internet verursacht) ist, dass dieses Passwort im Klartext im Netz uml�uft, und es daher von jedermann abgeh�rt werden kann, der �ber einen einfachen "sniffer" verf�gt. Hier bietet SSH die gleiche Oberfl�che, (es ist eine einfache Methode f�r Anf�nger, um von telnet zu SSH zu migrieren, weil man nichts Neues lernen muss ...), nichtsdestoweniger hat das SSH-Protokoll den Kanal verschl�sselt und das klar lesbare Passwort ist eingekapselt.

  Eine noch sicherere Variante, konfigurierbar, wenn man die erforderlichen Programme auf dem Server hat, ist ein "One time password" (S/Key zum Beispiel): es ist sicherlich besser, offensichtlich sicherer, aber die ergonomischen Beschr�nkungen lassen eine Benutzung nur bei bestimmten Rechnern zu. Das System funktioniert wie folgt: Nachdem man seine Identit�t eingegeben hat, wird vom Server eine sog. "challenge (Herausforderung)" gesendet (anstatt nach einem statischen Passwort zu fragen), auf die die Benutzerin antworten muss. Da diese Herausforderung sich st�ndig �ndert, mu� die Antwort sich auch �ndern. Konsequenterweise ist das Abh�ren der Antwort nicht wichtig, da sie nicht nochmals verwendet werden kann. Die erw�hnte Beschr�nkung liegt in der Kodierung der Antwort, die berechnet werden muss (durch ein Token, Software auf dem Client usw), und die Eingabe ist ziemlich "kabalistisch" (im besten Fall sechs englische Einzel-Silben).
  

• "rhosts �hnlich" (host-basierend):

  In diesem Fall ist die Identifikation �hnlich zu den R-Befehlen mit den Dateien wie /etc/rhosts oder ~/.rhosts, die die Client-Rechner "zertifizieren". SSH tr�gt hier nur zu einer verbesserten Rechnererkennung bei mittels Benutzung privater "shosts"-Dateien. Von einem Sicherheits-Standpunkt her ist dies nicht ausreichend und ich rate davon ab, diese Methode allein zu verwenden.

• Durch �ffentliche Schl�ssel

  Hier basiert das Authentifizierungssystem auf asymmetrischer Verschl�sselung (s. den Artikel �ber Verschl�sselung wegen weiterer Einzelheiten; kurz: SSHv1 benutzt RSA und SSHv2 f�hrte DSA ein). Der �ffentliche Schl�ssel des Benutzers wird zuvor auf dem Server registriert und der private Schl�ssel ist auf dem Client gespeichert. Mit diesem Authentifizierungssystem laufen keine Geheimnisse �ber das Netz und werden niemals zum Server gesendet.

  Dies ist ein ausgezeichnetes System, aber seine Sicherheit ist immer noch begrenzt (in meiner Sicht), weil sie fast ausschlie�lich von der ""Ernsthaftigkeit" des Benutzers abh�ngt (dieses Problem ist nicht SSH-spezifisch, aber ich glaube, dass dies DAS Hauptproblem von Systemen mit �ffentlichen Schl�sseln ist, wie z. B. den heutzutage popul�ren PKI-Systemen): um die Komprimierung des �ffentlichen Schl�ssels auf dem Client zu vermeiden, ist der Schl�ssel normalerweise durch ein Passwort gesch�tzt (zumeist als Passwort-Satz bezeichnet, um die Notwendigkeit zu betonen, mehr als ein Wort zu benutzen). Wenn die Benutzerin ihren privaten Schl�ssel nicht sorgf�ltig (oder �berhaupt nicht) sch�tzt, kann jemand sehr leicht Zugriff auf alle ihre Ressourcen erhalten. Daher sage ich, dass die Sicherheit von der Ernsthaftigkeit des Benutzers und seinem Vertrauen abh�ngt, weil in diesem System der Server-Verwalter keine M�glichkeit hat, zu erfahren, ob der private Schl�ssel gesch�tzt ist oder nicht. Z. Z. verwaltet SSH noch keine Widerrufslisten (wie viele nicht, selbst PKI nicht ...). Wenn z.B. ein privater Schl�ssel ohne einen Passwort-Satz auf einem Heim-Computer gespeichert wird (es gibt keine schlechten Menschen zuhause, warum soll man sich da mit einem Passwort-Satz belasten ...?) und eines Tages mu� dieses Ger�t zur Reparatur-Abteilung eines wichtigen H�ndlers (lachen Sie nicht, das wird passieren, wenn elektronische Signaturen selbstverst�ndlich werden), wird der Mechaniker (sein Sohn, seine Freunde) in der Lage sein, an die privaten Schl�ssel auf jedem Computer zu gelangen, der �ber seinen Tisch l�uft.

  Die Konfiguration des SSH Authentifizierungs-Mechanismus f�r den Bnutzer ist leicht unterschiedlich, je nachdem, ob man SSHv1, SSHv2 oder OpenSSH nutzt oder einen MacOS^tm- oder Windows^tm- Client. Die grundlegenden Prinzipien und Schritte sind:

  • wie man ein "asymmetrisches Schl�sselpaar" generiert (d.h. ein privates/�ffentliches RSA/DSA-Schl�sselpaar), zumeist auf dem Client-System, (wenn mehrere Client-Systeme verbunden sind, generieren wir das Schl�sselpaar auf einem der Clients und replizieren die Schl�ssel auf den anderen Clients). Einige der Windows^tm- und MacOS^tm-Clients verf�gen nicht �ber Dienstprogramme zur Schl�sselgenerierung; hier m�ssen Sie die Schl�sselgenerierung auf einem Unix-Rechner vornehmen und dann duplizieren. Das Schl�sselpaar wird im Benutzer-Verzeichnis ~/.ssh gespeichert.
  • Kopieren des �ffentlichen Schl�ssels auf einen Server, der f�r die Authentifizierung benutzt wird. Dies geschieht, indem einer Datei auf dem Server eine Zeile hinzugef�gt wird, die mit dem generierten Schl�sselpaar aus dem ~/.ssh-Verzeichnis der Benutzerin korrespondiert. (Der Name der Datei ist abh�ngig von der SSH-Version, entweder authorized_keys oder authorization).
  • Und das ist alles ... wenn die Konfiguration weitere Authentifizierung auf der Serverebene verlangt, wird der Client zur Verbindungszeit nach einem "Passwort-Satz" fragen.
    

Au�erdem ist es n�tzlich, zumindest zwei weitere Elemente zu kennen, die die Authentifizierung betreffen:

• ssh-agent

  Einer der Gr�nde, warum man seinen privaten Schl�ssel nicht sch�tzt, ist die damit verbundene Bel�stigung, dass man den Schl�ssel bei jeder interaktiven Verbindung eingeben muss und man den Schl�ssel nicht in Hintergrund-Skripten benutzen kann. Es existiert eine Abhilfe, der SSH agent. Es ist ein Dienstprogramm (ssh-agent), das Ihnen nach der Aktivierung hilft, eine dreifache Identifizierung (Benutzername/Rechnername/Passwort-Satz) zu speichern und diese Identifizierungsmerkmale an Ihrer Stelle abzusetzen, wenn dies beim Verbindungsaufbau erforderlich ist. Auf der Clientseite wird nur einmal nach dem Passwort gefragt, so dass man von SSO (Single Sign On) sprechen k�nnte.

  Nun sind Sie informiert, niemand zwingt Sie, Ihren privaten Schl�ssel zu sch�tzen, aber wenn Sie das nicht tun, dann ist das Fahrl�ssigkeit und Sie sind verantwortlich f�r die Konsequenzen.

• "verbose"-Modus

  Es kann sein, dass die Verbindung aus Gr�nden nicht m�glich ist, die der Benutzerin unbekannt sind: f�gen Sie einfach die Option "-v" (steht f�r "verbose", geschw�tzig) dem ssh-Befehl hinzu. Damit erhalten Sie w�hrend der Verbindung zahlreiche detaillierte Nachrichten auf dem Bildschirm, die Ihnen genug Informationen geben, um den Grund f�r die Verbindungsverweigerung zu bestimmen.

Die Verschl�sselungs-Algorithmen

Hier muss man unterscheiden zwischen denen f�r die Verschl�sselung von Kommunikations-Kan�len (Verschl�sselung mit geheimen Schl�sseln) und jenen, die f�r die Authentifizierung benutzt werden (Verschl�sselung mit �ffentlichen Schl�sseln).

F�r die Authentifizierung k�nnen wir in der Version 2 des Protokolls zwischen RSA und DSA w�hlen, f�r Version 1 steht nur RSA zur Verf�gung (daher keine Wahlm�glichkeit ...). DSA wurde aus historischen Gr�nden gew�hlt, weil RSA in einigen L�ndern patentiert war. Seit dem Ende des Sommers 2000 ist RSA frei von Rechten, so dass diese Beschr�nkung entfallen ist. Ich habe wirklich keine Vorliebe der guten oder schlechten Wahl (nur das DSA ein "reines" NSA-Produkt ist).

F�r die symmetrische Verschl�sselung gibt es schon fast zu viel Auswahl ... Das Protokoll schreibt einen gemeinsamen Algorithmus vor, der in allen Implementationen vorhanden sein muss: triple-DES mit drei Schl�sseln. Daher wird er benutzt, wenn die Verhandlung zwischen Client und Server hinsichtlich der anderen Algorithmen scheitert. Wenn Sie k�nnen, versuchen Sie einen der anderen Algorithmen auszuhandeln, da 3DES nun mit die geringste Performanz aufweist. Nichtsdestoweniger werden wir die exotischen oder alten (arc4, DES, RC4, ...) beiseite lassen und uns auf folgende beschr�nken:

• IDEA: bessere Performanz als 3DES, aber unter bestimmten Konditionen nicht vollst�ndig lizenzfrei (es war oft der Standard-Algorithmus in Unix-Versionen);
• Blowfish: sehr schnell, wahrscheinlich sicher, aber der Algorithmus muss sich im Lauf der Zeit noch beweisen;
• AES: der neue Standard (ersetzt DES), wenn er auf beiden Seiten verf�gbar ist, nutzen Sie ihn, daf�r wurde er geschaffen.

Pers�nlich frage ich mich nach dem Interesse, so viele Algorithmen vorzuschlagen; obwohl das Protokoll die M�glichkeit erlaubt, einen "privaten" auszuhandeln (z. B. f�r eine bestimmte Benutzergruppe), dies scheint f�r mich wesentlich, aber f�r den normalen Gebrauch denke ich, dass AES im Laufe der Zeit zum Standard werden wird. Falls AES komprimittiert wird, werden die Sicherheitsprobleme gr��er sein als die von SSH verursachten ...

Port-Weiterleitung, Tunnelung

SSH erm�glicht Redirektion (Weiterleitung) eines jeden TCP-Datenstroms durch einen "Tunnel" in einer SSH-Sitzung. Das bedeutet, dass der Datenfluss einer Anwendung, statt direkt �ber die Client- und Serverports zu gehen, "eingeschlossen " wird in einem "Tunnel", der zur Verbindungs-/Sitzungszeit erstellt wird (schauen Sie sich das folgende Diagramm an).

F�r das X11-Protokoll geschieht dies ohne spezielle Eingriffe (des Benutzers), mit transparenter Behandlung von Displays und erlaubt kontinuierliche Weiterleitung, falls es �ber mehrere Stationen geht.

F�r andere Datenstr�me gibt es Befehlszeilen-Optionen f�r jede Seite:

• Direkte Verbindung zwischen Client und Server
  

  

  (Beispiel: user@alice% telnet bob.org)
  

• Lokale Port-Weiterleitung (Client) zu einem entfernten Port (Server)

  

  example: user@alice% ssh -L 1234:bob.org:143 bob.org

  Dieses System erm�glicht Zugriff von "alice.org" auf den imap-Server bei "bob.org",
  Verbindungen von au�erhalb auf das lokale Netzwerk werden abgewiesen. Sie werden nur �ber die localhost-Adresse zugelassen, Port 1234, von dem imap-Client, der auf "alice.org" ausgef�hrt wird.

  • (1) die Benutzerin auf "alice.org" �ffnet (Verbindung) den SSH-Tunnel
  • (2) die Benutzerin auf "alice.org" konfiguriert den lokalen imap-Client f�r Zugriff auf den lokalen imap-Server auf localhost Port 1234
    
  
  
  
• Weiterleitung eines entfernten Ports (Client) auf einen lokalen Port (Server)
  

  

  Beispiel: root@alice% ssh -R 1234:bob.org:143 bob.org

  Dies ist die gleiche Situation wie oben, aber der Port auf dem entfernten Rechner wird weitergeleitet. Nur root hat die Rechte, um diesen SSH-Befehl auszuf�hren, aber jeder Benutzer kann diesen weitergeleiteten Port/Tunnel nutzen.

Diese m�chtige F�higkeit f�hrt dazu, das SSH manchmal als "ein Tunnel f�r die Armen" bezeichnet wird. Hier bezeichnet Armut diejenigen, die keine Administrator-Rechte auf dem Client haben. Nur in speziellen F�llen kann ein lokaler Port mit niedrigen Privilegien (Port > 1024) und ohne Superuser-Rechte ("root") weitergeleitet werden. Andererseits, wenn die Weiterleitung eines privilegierten lokalen Ports ben�tigt wird, muss dies entweder unter einer root-Kennung erfolgen oder der Client muss mit Superuser-Privilegien ("suid") installiert werden (tats�chlich erlaubt ein privilegierter lokaler Port die Redefinition eines Standard-Dienstes).

Wie mit IP, ist es recht einfach, etwas in etwas anderes einzupacken (und umgekehrt), es ist nicht nur m�glich, althergebrachte TCP-Datenstr�me weiterzuleiten, sondern auch PPP-Verbindungen, so dass wir einen "realen" IP-Tunnel in IP erstellen k�nnen (der verschl�sselt und daher sicher ist). Die Methode �berschreitet den Rahmen dieses Artikels, Sie k�nnen jedoch "Linux VPN-HOWTO" wegen Einzelheiten und Setup-Skripten lesen (Sie finden auch richtige VPN-L�sungen f�r Linux wie "stunnel", die Sie erw�gen sollten, bevor Sie eine endg�ltige Entscheidung treffen).

Denken Sie daran, dass die erste M�glichkeit ist, telnet-Datenstr�me umzuleiten: Dies scheint total nutzlos, da SSH automatisch interaktive Verbindungen implementiert. Sie k�nnen jedoch beim Weiterleiten von telnet-Verbindungen Ihren bevorzugten Client anstelle des interaktiven SSH-Modus benutzen. Dies k�nnten Sie besonders sch�tzen in einer Windows^tm- oder MacOS^tm-Umgebung, wo der SSH-Client nicht den Vorlieben des Benutzers entspricht. Zum Beispiel leidet der "terminal emulation"-Teil des "Mindterm"-Clients (Javas SSH-Client, verf�gbar auf allen modernen Systemen) unter der mangelnden Performanz der Sprache JAVA: es kann vorteilhaft sein, den Client nur zum Er�ffnen des SSH-Tunnels zu nutzen.

Auf die gleiche Weise k�nnen Sie einen entfernten Client wie "xterm" starten (zum Beispiel mittels automatischer X11-Weiterleitung in SSH), was uns die Benutzung von SSH auf X-Terminals erlaubt.

Beachten Sie, dass der Tunnel offen bleibt, solange Daten fliessen, selbst wenn sie nicht vom Initiator kommen. Daher ist der "sleep"-Befehl sehr n�tzlich zum �ffnen eines neuen SSH-Tunnels, um eine neue TCP-Verbindung weiterzuleiten.

% ssh -n -f -L 2323:serveur.org:23 serveur.org sleep 60

% telnet localhost 2323

... welcome to serveur.org ...

Die erste Zeile �ffnet den Tunnel, startet den Befehl "sleep 60" auf dem Server und leitet den lokalen Port 2323 auf den entfernten Port Nummer 23 (telnet) weiter. Die zweite startet einen telnet-Client auf dem lokalen Port 2323 und benutzt dann den (verschl�sselten) Tunnel, um sich mit dem telnetd-D�mon auf dem Server zu verbinden. Der "sleep"-Befehl wird nach einer Minute beendet (es bleibt nur eine Minute Zeit, um telnet zu starten), aber SSH wird den Tunnel erst schliessen, wenn der letzte Client beendet wurde.

Haupt-Distributionen: frei verf�gbar

Wir m�ssen zwischen Clients und/oder Servern auf den verschiedenen Plattformen unterscheiden und Sie sollten wissen, dass SSH Version 1 und SSH Version 2 inkompatibel sind. Die Referenzen am Ende des Artikels helfen Ihnen, andere Implementationen zu finden, die nicht in der folgenden Tabelle enthalten sind, welche sich auf freie Produkte mit gen�gend stabilen F�higkeiten beschr�nkt..

Beachten Sie, dass MindTerm sowohl eine unabh�ngige Java-Implementation (Sie ben�tigen nur eine Java-runtime-Umgebung ) als auch ein servlet ist, das innerhalb eines kompatiblen und gut gestalteten Webbrowsers ausgef�hrt werden kann. Leider sind die letzten Versionen dieser exzellenten Distribution gerade kommerzielle Produkte geworden.

OpenSSH

Heute ist diese Distribution wahrscheinlich diejenige, die in einer Unix/Linux-Umgebung eingesetzt wird (kontinuierliche Unterst�tzung, gute Antwortzeiten, quell-offen und frei).

Die OpenSSH-Entwicklung begann mit der Original-Version (SHH 1.2.12) von Tatu Ylonen (die wirklich letzte freie) im OpenBSD2.6-Projekt (�ber OSSH). Nun wird OpenSSH von zwei Gruppen entwickelt, eine, die nur f�r das OpenBSD-Projekt entwickelt, die andere passt den Code kontinuierlich an, um eine portable Version zu erstellen.

All dies hat einige Konsequenzen, insbesondere wurde der Code gr��er und gr��er, eine konstante Monster-Anpassung (ich merke, wie das "sendmail"-Syndrom am Horizont erscheint, und das ist nicht gut f�r eine Anwendung, die der Verschl�sselung gewidmet ist und welche besonders rigoros sein sollte).

Neben dem reinen und lesbaren Code st�ren mich zwei Punkte besonders:

• OpenSSH benutzt f�r seine Verschl�sselungsdienste die OpenSSL-Bibliothek, und diese Bibliothek wird generell dynamisch gelinkt. In unserem Fall der Implementation eines Verschl�sselungspaketes, das Eigenschaften wie einen guten Sicherheitsstandard und voll verl�ssliche Eigenschaften hat, l�sst mir den vorhergehenden Ansatz als vollkommen falsch erscheinen. Nat�rlich entspricht eine Attacke auf die Bibliothek einer Attacke auf das Produkt. Anders als eine zerst�rerische Attacke, die Verschl�sselungs-Charakteristik (Qualit�t) in OpenSSH ist die der Bibliothek, die unabh�ngig von OpenSSH existiert.
• OpenSSH benutzt f�r einige seiner empfindlichen Dienste (z. B. einen Zufallszahlen-Generator) die OpenBSD-Systemdienste. Nur in diesem Kontext mache ich die gleichen Bemerkungen zur externen Abh�ngigkeit wie in OpenSSL. Noch st�render ist, dass die portable Version von OpenSSH, die auf anderen Plattformen arbeitet, die von OpenBSD ben�tigten Dienste an verschiedene Mechanismen auf den anderen Zielplattformen delegiert. Z. B., ob ein Zufallszahlen-Generator auf Ihrem System verf�gbar ist oder nicht, werden wir diesen benutzen oder einen anderen internen. Konsequenterweise wird die effektive Entropie von OpenSSH abh�ngig von der Laufzeit-Plattform.

Nach meiner Meinung (und ich bin da nicht allein), sollte ein Mehr-Plattform-Verschl�sselungsprodukt ein bewiesenes, bestimmtes und konstantes Verhalten aufweisen, unabh�ngig von der Plattform und die speziellen Eigenschaften der Plattform und deren Entwicklung in Betracht ziehen (ausgleichen).

Nachdem wir dies gesagt haben, m�ssen wir zugeben, dass die Implementationen der Wettbewerber weder zahlreich noch besonders attraktiv sind. Ich glaube, dass es pragmatischer ist, zu erw�gen, dass OpenSSH die schlimmste Implementation ist, wenn man alle anderen ausschlie�t ...! Es w�re ein n�tzliches Projekt f�r die Gemeinschaft, den Code neu zu gestalten und zu schreiben.

Schlechte Neuigkeiten ...

SSH bewirkt keine Wunder! Es tut das gut, wof�r es geschaffen wurde, aber nach mehr d�rfen Sie nicht fragen. Insbesondere wird es keine "berechtigten" Verbindungen verhindern: Wenn ein Konto kompromittiert ist, ist es f�r den Eindringling m�glich, sich selbst mittels SSH mit Ihrem Computer zu verbinden, auch wenn es der einzige Weg ist, denn er kontrolliert die Authentifizierung. Sie k�nnen sich auf SSH nur dann vollst�ndig verlassen, wenn es verbunden ist mit einer geeigneten und koh�renten Sicherheitspolitik: Wenn jemand nur ein Passwort benutzt und nicht �berall SSH benutzt, ist das potentielle Risiko nur leicht vermindert. In dieser Situation kann SSH "fehlschlagen", da der Eindringling eine gesicherte verschl�sselte Verbindung mit Tunnelung nutzen kann, kann er wahrscheinlich alles tun, was er m�chte, ohne die M�glichkeit einer effektiven Verfolgung durch Sie.

In dem gleichen Sinne mu� man auch gut gemachte "rootkits" ber�cksichtigen, die generell einen SSH-D�mon enthalten, um eine diskrete R�ckkehr in Ihr System zu erm�glichen, aber mit einigen Modifizierungen: er lauscht nat�rlich nicht auf Port 22, stoppt das Logging, ist nach einem gew�hnlichen D�mon benannt (z. B. httpd), und auch unsichtbar f�r einen "ps"-Befehl (der sicherlich auch durch das Rootkit ver�ndert wurde).

Andererseits sollte man nicht zu sehr �ber die Gefahr besorgt sein, die ein SSH-D�mon darstellen kann, der es Eindringlingen erm�glicht, noch mehr verdeckt zu unternehmen: Sie wissen (so hoffe ich), dass es m�glich ist, in IP alles in alles einzupacken, einschlie�lich "Fehldarstellung" der grundlegenden Protokolle �ber eine Firewall: HTML-Tunnelung, ICMP-Tunnelung, DNS-Tunnelung, .... Wenn Sie ein 100 % sicheres System haben m�chten, m�ssen Sie Ihren Computer ausgeschaltet lassen ;-).g

SSH ist nicht frei von Sicherheits-"Schlupfl�chern", die aus der Implementation abgeleitet wurden (viele wurden in der Vergangenheit korrigiert, da es kein perfektes Programm gibt), aber auch auf der Protokoll-Ebene. Diese "Schlupfl�cher", obwohl sie als sehr alarmierend angek�ndigt wurden, betreffen h�ufig Schwachstellen, die schwierig auszunutzen sind, weil sie technisch sehr komplex sind: Man mu� im Kopf behalten, dass die Sicherheitszwischenf�lle, die durch die Benutzung von SSH vermieden werden, t�glich auftreten, andererseits diejenigen, die auf Schwachstellen von SSH beruhen, oft theoretischer Natur sind. Es ist interessant, die Studie zu lesen, die sich mit "man in the middle"-Attacken befasst: http://www.hsc.fr/ressources/presentations/mitm/index.html. Nichtsdestoweniger ist es n�tig, diese m�glichen Verletzlichkeiten f�r "Hoch-Sicherheits"-Anwendungen {Finanzen, Milit�r, ...} in Rechnung zu stellen, wo die vom Cracker benutzten Mittel erheblich sein k�nnen, wenn er hochmotiviert wegen der Ziele und des Profits angreift.

• "Man in the middle"-Attacke:
  

  

  Der Angreifer f�ngt die Pakete von beiden Seiten ab und generiert seine Pakete, um jede Seite zu t�uschen
  (es sind verschiedene Szenarien m�glich, bis dahin, die Verbindung zu einer Seite zu beenden,
  und mit der anderen Seite fortzufahren und vorzut�uschen, es handele sich um den normalen Partner).

Ich weise oft auf eine unverst�ndliche Schw�che im Protokoll hin, die das Auff�llen betrifft (als verdeckter Kanal bekannt): In beiden Versionen 1 und 2 haben die Pakete eine L�nge, die ein Mehrfaches von 64 Bit ist, und werden mit einer Zufallszahl aufgef�llt. Dies ist recht ungew�hnlich und bringt einen klassischen Fehler zum Vorschein, der in Verschl�sselungsprodukten sehr bekannt ist: ein "versteckter" oder ("unterbewusster") Kanal. Normalerweise f�llt man mit einer verifizierten Sequenz auf, z. B. der Wert n f�r den Byterang n (selbstbeschreibendes Auff�llen). Da in SSH die Sequenz (per Definition) zuf�llig wird, kann sie nicht gepr�ft werden. Daher ist es m�glich, dass eine der kommunizierenden Parteien die Kommunikation komprimittieren kann, die von einer dritten Partei abgeh�rt wird. Man kann sich auch eine fehlerhafte Implementierung vorstellen, die beiden Parteien unbekannt ist (leicht zu realisieren bei Produkten, wo nur die Bin�rprogramme geliefert werden, wie es generell bei kommerziellen Produkten �blich ist). Dies kann leicht getan werden und in diesem Fall muss man nur Client oder Server "infizieren". Solch einen unglaublichen Fehler im Protokoll zu lassen, obwohl es universell bekannt ist, dass die Installation eines versteckten Kanals in einem Verschl�sselungsprodukt DER klassische und einfachste Weg ist, die Kommunikation zu korrumpieren, scheint mir unglaublich. Es mag interessant sein, Bruce Schneiers Bemerkungen zu lesen, die die Implementation solcher Elemente in von Regierungs-Agenturen beeinflu�ten Produkten betreffen (http://www.counterpane.com/crypto-gram-9902.html#backdoors).

Ich beende diesen Punkt mit dem letzten Fehler, den ich w�hrend der Portierung von SSH nach SSF (franz�sische Version von SSH) fand, der sich in der Kodierung der Unix-Versionen vor 1.2.25 findet. Die Konsequenz war, dass der Zufallsgenerator ... vorhersagbare ... Ergebnisse produzierte (diese Situation ist in einem kryptographischen Produkt bedauerlich; ich werde nicht in die Einzelheiten gehen, aber man kann die Kommunikation durch einfaches Abh�ren kompromittieren). Zu der Zeit hatte das SSH-Entwicklungsteam den Fehler korrigiert (es war nur eine Zeile zu �ndern), allerdings ohne irgendeine Warnung zu versenden, noch nichtmals eine Erw�hung im "changelog" des Produktes ... Wenn mann nicht will, dass dies bekannt wird, h�tte man nicht anders gehandelt. Nat�rlich besteht keine Verbindung zu dem Link zum obigen Artikel.

Schlu�folgerung

Ich wiederhole, was ich in der Einf�hrung geschrieben habe: SSH, kein Produkt bewirkt Wunder noch l�st es alle Sicherheitsprobleme, aber es erm�glicht es, die schw�chsten Aspekte der historischen interaktiven Verbindungsprogramme (telnet, rsh, ...) effizient zu behandeln.

Bibliographie, wesentliche Links

Die folgenden zwei B�cher behandeln SSH Version 1 und SSH Version 2:

• SSH: the Secure Shell
  Daniel J. Barret & Richard E. Silverman
  O'Reilly - ISBN 0-596-00011-1
  
• Unix Secure Shell
  Anne Carasik
  McGraw-Hill - ISBN 0-07-134933-2
• openssh: http://www.openssh.com

Und wenn Sie etwas Geld ausgeben m�chten, k�nnen sie hier anfangen ...:

• http://www.ssh.com

Ausnutzung des verdeckten Kanals (verursacht durch das zuf�llige Auff�llen in SSHv1)

Hier ist eine M�glichkeit, den verdeckten (unterbewu�ten) Kanal auszunutzen, der durch das zuf�llige Auff�llen in SSHv1 (und v2) m�glich ist. Ich lehne jede Verantwortung f�r Herzattacken ab, die die ganz Paranoiden treffen k�nnten.

Die SSHv1-Pakete haben folgende Struktur:

Nur ein Feld ist nicht verschl�sselt: die "Gr��e". Die Gr��e des verschl�sselten Teils ist immer ein Vielfaches von acht, angepasst durch "Auff�llen". Das Auff�llen wird immer vorgenommen, wenn die L�nge der drei letzten Felder bereits ein Vielfaches von acht ist, wird das Aufgef�llte 8 Bytes lang sein (5+p+n Rest 0 modulo 8). Man betrachte die Verschl�sselungsfunktion C, symmetrisch, im CBC-Modus genutzt und die Entschl�sselungsfunktion C^-1. Um diese Demonstration zu vereinfachen, nehmen wir nur die Pakete mit 8-Byte-Auff�llung. Wenn eines der Pakete ankommt, nehmen wir einen Wert von C^-1(M), 8 Bytes in diesem Fall, anstatt mit einer Zufallszahl aufzuf�llen. Dies bedeutet die Entschl�sselung einer Nachricht M mit der Funktion C , die zur Verschl�sselung des Kanals benutzt wurde (die Tatsache, das M "entschl�sselt" wird, ohne vorher verschl�sselt worden zu sein, hat aus einer streng mathematischen Betrachtungsweise keine Wichtigkeit, ich gehe hier nicht auf die Einzelheiten der praktischen Implementation ein). Als n�chstes f�hren wir die normale Verarbeitung des Paketes durch, d.h. die Verschl�sselung von Bl�cken mit 8 Bytes.

Das wird das Ergebnis sein:

Was ist hier erstaunlich? Der erste verschl�sselte Block enth�lt C(C^-1(M)). Da C eine symmetrische Verschl�sselungsfunktion ist, gilt C(C^-1(M)) = M. Dieser erste Block wird entschl�sselt in einem verschl�sselten Datenstrom gesendet! Das bedeutet nur, dass jemand, der Kenntnis von dieser Liste hat und die Kommunikation belauscht, auch weiss, wie er diese Information ausnutzen kann. Nat�rlich kann man annehmen, dass die Nachricht M selbst verschl�sselt ist (z.B. gegen einen �ffentlichen Schl�ssel, womit vermieden wird, ein Geheimnis in den pervertierten Code einzuf�gen), was immer noch die Entschl�sselung durch jemanden verhindert, der nicht informiert ist.

So ben�tigt es z.B. drei Pakete diesen Typs, um den triple-DES(168 bit)-Sitzungsschl�ssel durchzureichen, wonach der Datenfluss-Sniffer die gesamte Kommunikation entschl�sseln kann. Wenn der Schl�ssel gesendet wird, ist es nicht l�nger n�tig, das pervertierte Auff�llen "vorzuentschl�sseln", es ist m�glich, Auff�llungen beliebiger Gr��e zu nehmen, wenn man noch mehr Informationen hinzuf�gen m�chte.

Die Benutzung dieses verdeckten Kanals ist absolut nicht zu erkennen! Man muss vorsichtig sein, jedes Element der Nachricht wie eben erl�utert zu verschl�sseln, damit die Entropie des Blocks nicht die List verr�t. Unentdeckbar, da das Auff�llen zuf�llig geschieht, was m�gliche Validierungs-Tests eliminiert. Zuf�lliges Auff�llen sollte niemals in kryptographischen Produkten angewandt werden.

Was diesen Kanal noch gef�hrlicher macht als andere im Protokoll, wird eingef�hrt durch Nachrichten wie SSH_MSG_IGNORE, wo Sie es nutzen k�nnen, ohne den Verschl�sselungs-Schl�ssel zu kennen.

Um die perversen Effekte des zuf�lligen Auff�llens zu vermeiden, muss man im Protokoll nur die Benutzung des deterministischen Auff�llens definieren, allgemein als "selbstbeschreibendes Auff�llen" bezeichnet, was bedeutet, dass das Byte an Offset n auch n enth�lt. Zuf�lliges Auff�llen ist in SSH v2 noch verblieben, es ist eine M�glichkeit, so denken Sie daran ...

Zum Schluss m�chte ich sagen, wenn ich den verdeckten Kanal kritisiere, dann deshalb, weil ich m�chte, dass ein Produkt wie SSH, das von sich hohe Sicherheit behauptet, auch wirklich ein Maximum an Sicherheit bietet. Nun k�nnen Sie sich vorstellen, dass in vielen kommerziellen Produkten potentielle M�glichkeiten zur Manipulation existieren: nur quelloffene Produkte bieten die L�sung der prim�ren Anforderung, die M�glichkeit zur Pr�fung des Codes (selbst wenn die Pr�fung oft noch durchgef�hrt werden muss).