Die Secure Shell Seminar: Kommunikationsprotokolle

Transkript

1 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol Die Secure Shell Seminar: Kommunikationsprotokolle Sommersemester 2002 Andreas Feldmann Matrikelnummer: Betreuung: Stefan Diepolder Lehrstuhl für Informatik IV, RWTH Aachen

2 Inhaltsverzeichnis 1 Einführung: Was ist die Secure Shell? Lizensierung Kommunikation Das Transportschichtprotokoll Verbindungsaufbau Message Authentication Code Der Diffie-Hellmann Schlüsselaustausch RSA Digital Signature Algorithm Komprimierung Das Authentifizierungsprotokoll Authentifizierungsmöglichkeiten Verschlüsselung der Datenübertragung Der SSH-Agent Das Verbindungsprotokoll Tunneln Wovor die SSH schützt bzw. nicht schützt Wovor die SSH schützt Wovor die SSH nicht schützt Quellen 20 1 Einführung: Was ist die Secure Shell? Die Secure Shell (SSH ist ein Ersatz für die als unsicher zu betrachtenden Programme Remote Shell (rsh und Remote Login (rlogin. Sie erfüllen den selben Zweck wie die SSH, d.h. das Einwählen oder das Ausführen von Programmen auf entfernten Rechnern über ein Netzwerk. Dies geschieht jedoch 2

3 ohne Sicherheitsvorkehrungen bei rsh und rlogin, d.h. ohne Verschlüsselung der versendeten Daten oder der Authentifizierung des Clients bzw. des Servers. Was bedeutet, dass Passwörter und sensitive Daten abgehört und manipuliert werden können. Die SSH ist ein Ansatz durch Verschlüsselung der Daten und eindeutiger Identifikation der Clients und Server, in Kombination mit dem frühzeitigen Erkennen von Manipulation um Angriffe von Dritten zu verhindern. Die erste Version der SSH wurde 1995 von Tatu Ylönen an der TU Helsinki in Finnland entwickelt, nachdem jemand das Universitätsnetz nach Passwörtern abgehört hatte [1]. Der Name Secure Shell führt allerdings ein wenig in die Irre. Die SSH ist keine Shell sondern sie ist lediglich für die Übertragung der Aus- bzw. Eingabe eines Programms auf einen entfernten Rechner zuständig. Dies ist standardmäßig eine Shell. Der Name wurde nur aus Kompatibilitätsgründen von der rsh übernommen. Genauso ist SLogin ein Synonym für SSH. Dieser Name wurde auch aus Kompatibilitätsgründen von rlogin übernommen, wird aber von der zweiten Version der SSH nicht mehr benutzt stellte die von Tatu Ylönen gegründete Firma SSH Communications Security (SCS fest, dass die SSH1 zu unsicher war. Z.B. war nicht sicherzustellen, dass niemand die von der SSH versendeten Pakete manipulieren konnte, denn das Verfahren, welches bei der ersten Version verwendet wurde, war zu unsicher (siehe Kapitel Message Authentication Code. Außerdem wurden einige Verschlüsselungsverfahren wie DES aus dem Protokoll entfernt (siehe Kapitel Verschlüsselung der Datenübertragung. Mit Hilfe der neuen Sicherheitsaspekte entwickelte SCS die zweite Version der SSH, die SSH2. Im Anschluss gründete die Internet Engineering Task Force (IETF 1997 eine Arbeitsgemeinschaft namens SECSH, um das Protokoll zu standardisieren und die Arbeit im öffentlichen Interesse zu koordinieren. Die SECSH veröffentlichte einen so genannten Internet Draft [2,3,4] in dem sie das Protokoll der SSH2 definierte. Allerdings konnten die Veränderungen nicht ohne den Verlust der Rückwärtskompatibilität zum Protokoll der SSH1 vollzogen werden wurde die erste Implementierung der SSH2 von SCS veröffentlicht. Sie ist eine komplette Überarbeitung der SSH1, was bedeutete, dass die beiden Programme und ihre Protokolle völlig inkompatibel sind und so eine gemeinsame Nutzung ausgeschlossen ist. Außer der Optimierung einiger Sicherheitsaspekte wurde auch die Performance der SSH2 im Vergleich zum Vorläufer gesteigert [5]. Die SSH1 wird nicht mehr weiterentwickelt, so dass Sicherheitslöcher nicht mehr beseitigt werden. Deshalb wird die Nutzung der SSH2 empfohlen. Ein Vorteil der SSH1 ist, dass sie mehr Plattformen unterstützt als ihr Nachfolger. Dies wird sich aber höchstwahrscheinlich bald ändern. Außer den oben genannten Unterschieden umfasst die SSH2 zusätzlich außerdem ein Tool namens sftp. Es hat die selbe Funktionalität wie ein normaler ftp-client, nur dass die Daten verschlüsselt übertragen werden. 1.1 Lizensierung Die beiden SSH-Versionen haben verschiedene Lizenzmodelle. Die SSH1 ist bei nicht kommerziellem Gebrauch frei verfügbar. Sie darf nicht kommerziell als einzelnes Produkt, als Teil eines größeren 3

4 Produkts oder Projekts, oder für anderen finanziellen Gewinn verkauft werden. Es sei denn, man ist Besitzer einer entsprechenden Lizenz, die bei der SCS einzuholen ist. Unter kommerziellem Gebrauch versteht man im Allgemeinen jeglichen Gebrauch, der zu finanziellem Gewinn führt. Dass sich die SSH2 anfangs nicht durchsetzen konnte, lag zum Großteil an ihrem Lizenzmodell. Die SSH2 war im Gegensatz zur ersten Version ein kommerzielles Produkt und durfte nur von Universitätsmitgliedern (wie Studenten, Professoren oder Universitätspersonal oder anderen nicht kommerziell ausgerichteten Einrichtungen umsonst gebraucht werden. Aus diesen Gründen war sie anfangs trotz der erhöhten Sicherheitsstandards nicht so weit verbreitet wie die SSH1. Dies änderte sich allerdings als das Lizenzmodell gelockert wurde, und frei verfügbare nicht kommerzielle Implementierungen der SSH entwickelt werden durften. Zu diesen gehört unter anderen die weit verbreitete OpenSSH, die aus der OpenBSD-Entwicklung stammt und auf zahlreiche Plattformen portiert wurde. 2 Kommunikation Die SSH sichert drei Schwerpunkte der Kommunikation ab: Authentifizierung, d.h. die Sicherstellung, dass der Kommunikationspartner auch wirklich der ist, für den er sich ausgibt. Sobald man sich auf einem entfernten Rechner einwählt, prüft die SSH die Identität des Clients sowie des Servers. Falls eine der beiden Kommunikationspartner sich nicht korrekt ausweisen kann, wird die Verbindung abgebrochen. Verschlüsselung, d.h. die Sicherstellung, dass die verschickten Daten nicht von einem Dritten abgehört und gelesen werden können. Integrität, d.h. die Sicherstellung, dass die verschickten Daten unmanipuliert beim Empfänger ankommen. Falls ein Angreifer die verschickten Daten verändert, wird das von der SSH erkannt und die Verbindung getrennt. Die SSH garantiert also die Authentizität der Kommunikationspartner, dass die verschickten Daten unmanipuliert ankommen, und dass niemand unerlaubt sensitive Daten abhört. Um dies bewerkstelligen zu können, behilft sich die SSH einer Auswahl mehrerer Verfahren zur Sicherstellung der Authentifizierung, der Verschlüsselung und der Integrität, die in diesem Kapitel eingehender betrachtet werden sollen. Der allgemeine Ablauf der Kommunikation bei der SSH sieht wie folgt aus: Verbindungsanfrage des Clients an Port 22 des Servers. Vergleich der Protokollversionen, um Inkompatibilitäten zu vermeiden. Aushandeln der verwendeten Algorithmen für den Message Authentication Code (MAC, sowie der Verschlüsselung der Datenübertragung, der Komprimierung der Daten und der verwendeten Sprache. 4

5 Austausch des Sitzungsschlüssels mittels des Verfahrens von Diffie-Hellmann, welches verhindert, dass kein Dritter an diesen Schlüssel gelangt. Authentifizierung des Servers mit Hilfe einer digitalen Signatur. Authentifizierung des Benutzers mittels einer der im Kapitel Authentifizierungsmöglichkeiten beschriebenen Verfahren. verschlüsselte Nutzerdatenübertragung, mit Hilfe des zuvor ausgehandelten symmetrischen Verfahrens. Verbindungsabbau. Nachdem die Verbindung aufgebaut wurde, wird die Authentifizierung - und auch die Nutzerdatenübertragung - verschlüsselt durchgeführt. Dadurch wird sichergestellt, dass evtl. zu übertragende Passwörter, die für die Authentifizierung des Clients benötigt werden, nicht von Dritten abgehört werden können (siehe Kapitel Authentifizierungsmöglichkeiten. Wie die Kommunikation schematisch aussieht, zeigt Abbildung 1. Client Server Verbindungsanfrage über TCP/IP(Port 22 Protokollversion Liste der unterstützten Algorithmen Protokollversion unverschlüsselt Liste der unterstützten Algorithmen Diffie Hellmann Zahl e Diffie Hellmann Zahl d und digitale Signatur Authentifizierung Ab hier beginnt der Austausch der Nutzerdaten verschlüsselt Abbildung 1: Schematische Darstellung der Kommunikation Wie alle Internetanwendungen baut das SSH-Protokoll auf dem Schichtenmodell des Internets auf. Das SSH-Protokoll ist insgesamt in der Anwendungsebene einzuordnen, und ist in drei Protokolle 5

6 unterteilt: das Transportschicht-, das Authentifizierungs- und das Verbindungsprotokoll, wobei das Transportschichtprotokoll der SSH nicht mit dem Transportschichtprotokoll des Internets (TCP oder UDP zu verwechseln ist [6]. Die SSH verlässt sich darauf, dass die unter ihr liegenden Schichten, wie z.b. TCP/IP, ihre Arbeit erfüllen, so dass sie sich nicht um die eigentliche Datenübertragung kümmern muss. Dadurch muss sie sich z.b. nicht um Fehlerkorrekturen, die durch elektronische Übertragungsfehler innerhalb der Netzwerkschicht auftreten, kümmern. Diese verschiedenen Schichten arbeiten alle unabhängig voneinander. D.h. dass eine Ebene immer nur Informationen mit der unmittelbar darüber und darunter liegenden austauscht. Jede Schicht verlässt sich darauf, dass die darunter liegende ihre Arbeit richtig erfüllt und somit eine eindeutige und korrekte Kommunikation zwischen den Ebenen stattfindet. 2.1 Das Transportschichtprotokoll Dieses Protokoll ist das unterste innerhalb des SSH-Protokolls und baut auf die darunter liegenden Netzebenen auf. In der Regel handelt es sich dabei um eine TCP/IP Verbindung, aber eine Benutzung von UDP-Datagrammen ist auch möglich. Das Transportschichtprotokoll der SSH ist für den Verbindungsaufbau und die Serverauthentifizierung zuständig. Außerdem übernimmt es die Ver- und Entschlüsselung der Pakete nachdem der Authentifizierungsprozess abgeschlossen wurde. Zusätzlich unterstützt es wahlweise die Komprimierung der Nutzerdaten (siehe Kapitel Komprimierung Verbindungsaufbau Der Verbindungsaufbau beginnt unmittelbar nachdem der Benutzer die SSH startet. Sie schickt eine Verbindungsanfrage an einen Server. Erste Bedingung für den Verbindungsaufbau ist, dass auf diesem Server ein SSH-Daemon läuft. Ein Daemon ist ein Programm, das im Hintergrund läuft und automatisch agiert. In diesem Fall nimmt der Daemon SSH-Einwählanfragen entgegen und bearbeitet sie. Durch die Verbindungsanfrage meldet sich die SSH beim Server und teilt ihm mit, dass sie eine Verbindung zum SSH-Daemon aufbauen möchte. Dies geschieht per TCP/IP. Standardmäßig wird die Anfrage an Port 22 des Servers gerichtet, welcher offiziell bei der Internet Assigned Numbers Authority (IANA für die SSH eingetragen ist. Optional kann auch jeder beliebige Port benutzt werden. Dafür muss die SSH nur anders konfiguriert werden. Sobald der SSH-Daemon den Verbindungswunsch des Benutzers erkannt hat, schickt er ihm seine verwendete Protokollversion. Der Client schickt seinerseits ebenfalls die verwendete Protokollversion an den Server. Falls die Versionen inkompatibel sind, wird die Verbindung abgebrochen. Dies geschieht insbesondere dann, wenn einer der beiden die erste und der andere die zweite Version des SSH-Protokolls benutzt. 6

7 Bis zu diesem Punkt verlief die Kommunikation textbasiert. Ab hier schalten Client und Server auf ein paketbasiertes Binär-Protokoll [2] um. Dabei besteht jedes Paket aus folgenden Feldern: Paketlänge ohne MAC und das Paketlängenfeld selbst. Ohne MAC und Paketlängenfeld sind das maximal Byte. Das Feld ist 4 Byte lang, und zeigt die Länge des Pakets in Bytes an. Paddinglänge. Dieses Feld ist 1 Byte lang, und zeigt die Länge des Paddings in Bytes an. Die Binärdaten des Nutzers. Dies können pro Paket maximal Byte unkomprimierte Daten sein (siehe auch Kapitel Komprimierung. Padding: 4 bis 255 Byte zufällig erzeugte Daten, um Known-Plaintext-Attacken zu erschweren, bei dem der Angreifer den Inhalt des Pakets kennt und so den Schlüssel und das verwendete Chiffrierverfahren herausfinden kann. Ein MAC, mit dem die Integrität der Daten kontrolliert werden kann. Dieses Feld ist optional, je nachdem ob ein MAC genutzt werden soll oder nicht. (siehe Kapitel Message Authentication Code. Paketlänge (4 Byte Paddinglänge (1 Byte Nutzerdaten (max Byte Padding (4 255 Byte MAC (12, 16 oder 20 Byte Abbildung 2: Paketbasiertes Binär-Protokoll. Die Länge eines ganzen Pakets ist nicht vorgeschrieben. Allerdings muss die Länge ein Vielfaches der verwendeten Blockgröße des Chiffrierverfahrens sein (siehe Kapitel Verschlüsselung der Datenübertragung, und ein Paket muss mindestens 16 Byte ohne MAC lang sein. Der im Draft zum Transportschichtprotokoll vorgeschlagene maximale Wert für die Paketlänge ist Bytes [2]. Dies ist allerdings ein willkürlich gewählter Wert, und Implementationen der SSH sollten auch größere Pakete unterstützen. 7

8 Nachdem die Protokollversionen verglichen wurden, schickt der Server eine Liste der von ihm unterstützten Chiffrierverfahren, MAC-Algorithmen, Kompressionsverfahren und Sprachen an den Client. Genauso schickt der Client dem Server eine Liste, der von ihm unterstützten Verfahren. Die zur Auswahl stehenden Verschlüsselungsalgorithmen sind in Tabelle 1 und 2 aufgelistet. Verfahren SSH1 SSH2 Data Encryption Standard (DES - triple DES (3DES International Data Encryption Algorithm (IDEA - Blowfish Twofish - Arcfour - Cast128 - Advanced Encryption Standard (AES - Serpent - Tabelle 1: Verfahren zur Verschlüsselung des Datentransfers [5]. Verfahren SSH1 SSH2 RSA - Digital Signature Algorithm (DSA - Tabelle 2: Verwendete Verfahren zur Signierung bei der Authentifizierung des Servers [5]. Aus den Listen der jeweiligen Verfahren wird von beiden Seiten das erste von der Liste des Clients ausgesucht, das auch auf der Serverliste vorhanden ist. Die Verfahren sollten in den Listen absteigend nach Präferenz bzw. Sicherheitsstufe aufgelistet sein. So kann das jeweils als sicherstes befundene, von beiden Seiten unterstützte, Verfahren automatisch ausgewählt werden. Falls keine übereinstimmenden Verfahren gefunden werden, wird die Verbindung abgebrochen. Dabei wird das Signierverfahren, das bei der Authentifizierung des Servers verwendet wird, nicht ausgehandelt. Da die beiden Versionen der SSH ohnehin verschiedene Verfahren benutzen, ist es eindeutig welches davon zur Verwendung kommt. Optional kann auch der für die MAC-Generierung verwendete Hashalgorithmus ausgewählt werden, falls dieser verwendet werden soll. Zur Auswahl stehen standardmäßig Message Digest 5 (MD5 [8] oder den Secure Hash Algorithm (SHA1 [8] bei der SSH2. Die SSH1 benutzt einen Cyclic Redundancy Check (CRC32. Falls kein MAC erwünscht ist, muss in der Liste der unterstützten Verfahren der Eintrag none stehen (siehe Kapitel Message Authentication Code. Als nächstes beginnt der Austausch des Sitzungsschlüssels für die symmetrische Chiffrierung. Hierfür wird der Diffie-Hellmann Schlüsselaustausch verwendet. Bei diesem Verfahren wird sichergestellt, dass kein Dritter, der die Verbindung abhört, an den Schlüssel gelangen kann (siehe Kapitel Der Diffie-Hellmann Schlüsselaustausch. Die gebrauchten Schlüssel werden standardmäßig jede Stunde oder nach einem Gigabyte Datentransfer geändert, und auch nur in der jeweiligen Sitzung verwendet. Die vom Server gebrauchten Schlüssel 8

9 - und evtl. auch die vom Client (siehe Kapitel Der SSH-Agent - werden nur im Arbeitsspeicher gehalten, damit ein Angreifer nicht die Festplatte auslesen kann, um an sie zu gelangen. Bei jeder Änderung des Sitzungsschlüssels muss erneut ein kompletter Austausch der verwendeten Algorithmen und des Sitzungsschlüssels stattfinden, wobei einzig der Sitzungsidentifikator (siehe unten gleich bleibt. Dies geschieht unter Verwendung des zuvor ausgehandelten Chiffrierverfahrens und Schlüssels. Das Chiffrierverfahren, der verwendete Schlüssel, die Komprimierung, der verwendete MAC-Algorithmus und die Sprache werden erst nach dem kompletten Abschluss des Austauschs geändert. Während eines solchen Schlüsselaustauschs können keine sonstigen Daten übertragen werden. Deshalb sollte man dies nicht zu oft durchführen, auch wenn die Sicherheit dadurch erhöht wird. Der Server erzeugt nun, um sich dem Client gegenüber auszuweisen, aus den SSH-Versionsnummern des Servers und des Clients, den Nutzerdaten der zuvor verschickten Initialisierungspakete des Diffie- Hellmann-Schlüsselaustauschs, den zuvor ausgetauschten Zahlen und und dem Sitzungsschlüssel (siehe Kapitel Der Diffie-Hellmann Schlüsselaustausch eine Prüfsumme [2], die er mit Hilfe seines privaten Schlüssels chiffriert. Die so entstehende Signatur schickt er samt seinem öffentlichen Schlüssel an den Client, der die Signatur überprüft (siehe Kapitel RSA und Kapitel Digital Signature Algorithm. Die Signatur wird als Sitzungsidentifikator genutzt. Er ist für jede SSH-Sitzung eindeutig, und wird während der ganzen Sitzung nicht mehr geändert. Außerdem vergleicht der Client den erhaltenen öffentlichen Schlüssel des Servers mit einer gespeicherten Liste bekannter Serverschlüssel. Dies ist notwendig um einem eventuellen Man-in-the-Middle- Attack vorzubeugen, bei dem ein Angreifer die Daten des einen Kommunikationspartners abfängt, sie manipuliert und unter falschem Namen an den anderen Kommunikationspartner weiterschickt. So bemerken die Kommunikationspartner nicht, dass sich ein Dritter in ihre Kommunikation eingeklinkt hat. Wenn man aber sicher seien kann, dass der erhaltene öffentliche Schlüssel von einem vertrauten Rechner stammt, kann kein Angreifer eine eigene Signatur erstellen und sie an den Empfänger schicken, ohne dass letzterer es merken würde. Falls der Nutzer sicher ist, dass der Server authentisch ist, kann er den öffentlichen Serverschlüssel der Liste hinzufügen, falls er noch nicht darin gespeichert ist. Um ganz sicher zu sein, kann man auch manuell der Liste einen Serverschlüssel hinzufügen, indem man den Schlüssel z.b. per Diskette auf den Clientrechner bringt. Ab jetzt beginnt die verschlüsselte Datenübertragung der Kommunikationspartner mit Hilfe des Sitzungsschlüssels und des abgesprochenen symmetrischen Chiffrierverfahrens Message Authentication Code Der Message Authentication Code (MAC ist eine Prüfsumme, die aus den zu versendenden Paketdaten ohne MAC und unverschlüsselten Nutzerdaten, dem Sitzungsschlüssel, dem Sitzungsidentifikator und einer Sequenz mit Hilfe eines der zuvor ausgehandelten Hashalgorithmen errechnet wird. Die Sequenz ist eine Zahl, die kontinuierlich pro versendetem Paket um Eins inkrementiert wird und nachdem sie beträgt, wieder auf Null gesetzt wird. 9

10 Eine MD5-Prüfsumme ist 128 Bit lang, eine SHA1-Prüfsumme 160 Bit lang. Optional können auch nur die ersten 96 Bit des errechneten MACs verschickt werden. Dies muss jedoch mit dem verwendeten Algorithmus vorher verhandelt werden. Bei Empfang eines Datenpakets wird der MAC mit einem neu errechneten MAC aus den empfangenen Daten verglichen. Da der Sitzungsschlüssel nur den beiden Kommunikationspartnern bekannt ist (siehe Kapitel Der Diffie-Hellmann-Schlüsselaustausch, kann ein Dritter die Daten nicht manipulieren, ohne dass es der Empfänger merken würde. Der Dritte kann nämlich keinen neuen MAC ohne den Sitzungsschlüssel aus seinen manipulierten Daten errechnen. Falls der MAC nicht den Daten entsprechen sollte, wird die Verbindung getrennt. So kann unter anderem ein Angriff wie der Folgender verhindert werden: Ein Dritter schaut einem Benutzer über die Schulter während er die SSH benutzt. Dies kann dadurch erfolgen, dass er z.b. die Tastatureingaben des Benutzers abhört. Gleichzeitig protokolliert er außerdem den Datenverkehr. Wenn der Benutzer jetzt z.b. einen Löschbefehl eingibt, schaut sich der Angreifer an, wie der Befehl aussieht, wenn er verschlüsselt von der SSH übertragen wird. Wenn der Benutzer dann gerade in einem wichtigen Verzeichnis arbeitet, kopiert der Angreifer den vorher abgefangenen Code des Löschbefehls in eines der Datenpakete des Benutzers. So würde in dem Verzeichnis womöglich etwas wichtiges gelöscht, und das obwohl der Angreifer die Datenübertragung noch nicht mal entschlüsseln konnte. Da allerdings jedes Paket mit Hilfe des MAC auf Manipulation geprüft wird, kann so etwas nicht geschehen Der Diffie-Hellmann Schlüsselaustausch Der Diffie-Hellmann Schlüsselaustausch wurde 1976 von Whitfield Diffie und Martin Hellman entdeckt. Er dient dazu, einen Schlüssel so auszutauschen, dass ein Dritter, der die Kommunikation abhört, nicht an den Schlüssel gelangen kann. Das Verfahren baut auf dem Prinzip der asymmetrischen Verschlüsselung auf, welches beinhaltet, dass es keine bekannte Methode gibt, um diskrete Logarithmen schnell und effizient zu berechnen. Falls so ein Verfahren entwickelt würde, wäre die asymmetrische Verschlüsselung nicht mehr sicher. Bei dem Schlüsselaustausch nach Diffie-Hellmann werden zuerst eine Primzahl und eine Zahl festgelegt, so dass gilt, und es für jede Zahl zwischen und einen Exponenten gibt, so (* dass. Bei der SSH2 sind und fest vorgegeben:! " $# %'& %+,&.-/# und :. Der Client generiert eine Zufallszahl ; und berechnet nun!< >=?%?. Er schickt anschließend an den Server, der seinerseits eine generiert unda CBD%? berechnet. Mit berechnet der Server den Sitzungsschlüssel E B %?. Anschließend schickt der Server an den Client, der dann EF = berechnen kann. Die beiden E s sind gleich, da gilt: EG B / = 6 B B 6 = / = %?IH Ein Außenstehender, der die Verbindung abhört, kann so nicht an E kennt aber nicht ; Dadurch kann er den Sitzungsschlüssel E gelangen, da er zwar und nicht berechnen. 10

11 2.1.4 RSA RSA wurde 1978 am MIT von Ron Rivest, Adi Shamir und Len Adleman entdeckt. Die Abkürzung RSA steht für die ersten Buchstaben der Namen seiner Entdecker. RSA baut auf dem Prinzip der asymmetrischen Verschlüsselung auf. Es dient primär zur Verschlüsselung von Daten, kann aber auch - wie bei der SSH1 - für digitale Signaturen verwendet werden. Die SSH2 verwendet hierfür DSA (siehe Kapitel Digital Signature Algorithm. Die RSA-Schlüsselpaare errechnen sich wie folgt: 1. Man wähle zwei große Primzahlen und. Das Produkt von und sollte je nach Sicherheitsstufe 768 oder 1024 Bit lang sein. Je länger die Zahlen, desto schwerer ist die chiffrierte Nachricht zu entschlüsseln, und desto länger dauert die Ver- bzw. Entschlüsselung. 2. Man berechne. Die Zahlen und bleiben geheim. 3. Man berechne 6 6 6, wobei Anzahl der Zahlen angibt, die kleiner und relativ prim zu 6 die Eulersche Phi-Funktion ist, und die 4. Man nehme eine Zahl, die kleiner als ist, und keine gemeinsamen Teiler (außer der Eins mit 6 hat, d.h. ist relativ prim zu 6. Dies lässt sich leicht mit Hilfe des euklidischen Algorithmus berechnen, da dann 6 6 gelten muss. 5. Man finde eine Zahl, so dass durch 6 teilbar ist. Mit anderen Worten D 6,, d.h. ist das multiplikative Inverse zu. Anders ausgedrückt heißt das, dass # 6. Da relativ prim zu 6 gewählt wurde, lässt sich mit dem erweiterten euklidischen Algorithmus ein und ein finden, so dass # 6. sind. 6. Der private Schlüssel besteht aus den Zahlen und, der öffentliche aus und. Der Sender einer verschlüsselten Nachricht kennt nur den öffentlichen Schlüssel des Empfängers. Mit diesem Schlüssel berechnet er eine verschlüsselte Nachricht aus der unverschlüsselten Nachricht nach der Vorschrift D%. Der Empfänger benutzt den nur ihm zugänglichen privaten Schlüssel, mit dessen Hilfe er die ursprüngliche Nachricht aus der empfangenen Nachricht nach der Formel berechnen kann. Aus der empfangenen Nachricht lässt sich eindeutig die gesendeten Nachricht errechnen, denn es gilt: 6 H Da ist und und Primzahlen sind, ist nach Morgan Kaufmann eine Zahl! #"%$'& #((. Wenn man diese Formel auf % anwendet ergibt sich: 11

12 "%$& ( ( H Da durch 6 den Rest Eins ergibt, ist D < 6 6 teilbar ist, und somit beim Teilen durch 0 6! 6 $ 6,. Dadurch erhält man: < 6 "%$!& #(( %?H Die SSH kann den privaten Schlüssel zur zusätzlichen Sicherheit mit einer frei wählbaren Passphrase schützen, indem sie eine MD5-Prüfsumme der Passphrase errechnet. Mit der erhaltenen Prüfsumme verschlüsselt die SSH den privaten Schlüssel mit Hilfe von IDEA (siehe Kapitel Der SSH- Agent. Bei der SSH wird RSA allerdings nicht zur Verschlüsselung verwendet, sondern um digitale Signaturen zu erstellen. Das Prinzip der digitalen Signaturen wird im folgenden Abschnitt beschrieben Digital Signature Algorithm Die zweite Version der SSH verwendet den DSA-Algorithmus. Der zugehörige Standard ist als Digital Signature Standard (DSS bekannt. Sie wurde auf Basis des ElGamal Verfahrens [8] zur Erzeugung digitaler Signaturen von dem National Institute of Standards and Technology (NIST entwickelt. El- Gamal wiederum baut auf dem Diffie-Hellmann Schlüsselaustausch auf. Dadurch, dass es bei der asymmetrischen Verschlüsselung einen öffentlichen Schlüssel gibt, kann jeder eine Nachricht an den Besitzer des privaten Schlüssels schicken. Dadurch kann nicht festgestellt werden, ob der Sender derjenige ist für den er sich ausgibt. Da aber gilt, dass % % (,, und wie oben lässt sich eine Nachricht auch mit dem öffentlichen Schlüssel chiffrieren und anschließend mit dem privaten dechiffrieren. Dies ist das Prinzip der digitale Signaturen: Wenn sich der Sender ausweisen will, chiffriert er eine Nachricht mit seinem privaten Schlüssel und schickt sie an den Empfänger. Dieser kann die Nachricht mit dem öffentlichen Schlüssel dechiffrieren und weiß so, dass der Sender auch derjenige ist für den er sich ausgibt, da nur der Sender im Besitz des privaten Schlüssels ist. Meist wird allerdings nicht die ganze Nachricht verschlüsselt, da das zu viel Rechenzeit kostet. Dafür erstellt man eine Prüfsumme der zu verschickenden Nachricht, und verschlüsselt diese mit dem privaten Schlüssel. Der Empfänger kann dann die entschlüsselte Prüfsumme mit einer neu berechneten Prüfsumme der Nachricht vergleichen, und kann so feststellen ob die Nachricht vom Sender stammt. Zusätzlich kann er dadurch auch feststellen, ob die Nachricht verändert wurde. DSA kann nur für digitale Signaturen verwendet werden. Das Prinzip bei DSA ist vergleichbar mit dem, welches zur Erzeugung digitaler Signaturen bei RSA verwendet wird. Allerdings werden die Zahlen anders berechnet, und der Algorithmus ist ein anderer. 12

13 2.1.6 Komprimierung Falls man nur über eine langsame Netzverbindung verfügt, kann man die automatische Komprimierung der zu verschickenden Daten einschalten. Dies bewirkt, dass die Nutzerdaten jedes Pakets, bevor es abgeschickt wird, mit Hilfe des GNU ZLIB Kompressionsverfahrens komprimiert werden. Dadurch verringert sich die Paketgröße, was bedeutet, dass weniger Daten übertragen werden müssen. Auf der Empfängerseite werden die Daten wieder entpackt. Der Nachteil dieses Verfahrens ist, dass das Komprimieren und Dekomprimieren Rechenzeit kostet. Man muss den Geschwindigkeitsvorteil, den man durch das Verschicken kleinerer Datenpakete erhält, mit der verlorenen Rechenzeit durch die Komprimierung abwägen. Der MAC und die Paketlänge werden erst nach der Komprimierung aus den Daten berechnet. Die Daten werden auch erst nach der Komprimierung verschlüsselt. 2.2 Das Authentifizierungsprotokoll Dieses auf dem Transportschichtprotokoll aufbauende Protokoll ist für die Anmeldung eines Benutzers beim Server zuständig. Es können natürlich auch mehrere Benutzer gleichzeitig angemeldet sein. Durch das Transportschichtprotokoll ist in diesem Protokoll eine sichere Verbindung zwischen Server und Benutzer gegeben. Das Authentifizierungsprotokoll ist im Internet-Draft [3] definiert Authentifizierungsmöglichkeiten Die SSH unterstützt verschiedene Möglichkeiten sich auf einem entfernten Rechner einzuwählen. Diese haben verschiedene Vor- und Nachteile. Am sichersten gilt die auf RSA bzw. DSA basierte Einwählmethode. Basierend auf Rechnernamen: Die SSH1 kann wie rlogin und rsh auf dem Server die Namen verschiedener bekannter Rechner und Benutzer speichern. So kann sie Anfragen mit den gespeicherten Rechnern bzw. Benutzern vergleichen, um festzustellen ob ein anfragender Rechner bzw. Benutzer bereits bekannt ist. Falls eine Anfrage einen bekannten Rechner oder Benutzer als Ursprung hat, gestattet der Daemon das Einwählen. Diese Methode ist allerdings sehr unsicher und wurde deshalb aus der SSH2 entfernt, denn ein Angreifer kann sich mittels IP- Spoofing als vertrauter Rechner ausgeben. Das erreicht er, indem er die Absenderadresse, die so genannte IP-Adresse, seiner verschickten Pakete auf der IP Ebene ändert. Dadurch kann er dem Empfänger vortäuschen, dass er ein vertrauter Rechner sei. Passwort basiert: Eine weitere Möglichkeit, sich auf einem entfernten Rechner einzuwählen, ist die Benutzung von Passwörtern. Der Benutzer gibt dazu sein Benutzerpasswort für das System des Servers ein. Die Übertragung des Passworts geschieht verschlüsselt, damit kein Dritter 13

14 unerlaubt das Passwort lesen und sich somit auf dem entfernten Rechner einwählen kann. Dieses Verfahren ist unsicher und umständlich. Unsicher, da ein Angreifer per Brute-Force-Attack, d.h. einfachem Ausprobieren aller Möglichkeiten, das Passwort erraten kann, und umständlich, da man jedes Mal beim Einwählen zur Eingabe des Passworts aufgefordert wird. RSA bzw. DSA basiert: Bei dieser Methode wird ein Challenge-Response-Dialog geführt. D.h. der einzuwählende Rechner beweist seine Identität indem er nachweist, dass er im Besitz seines privaten Schlüssels ist. Der Server kennt den öffentlichen Schlüssel des Clients, der eine Einwählanfrage stellt, und schickt eine mit diesem Schlüssel chiffrierte 256 Bit lange Zufallszahl an ihn. Der Client entschlüsselt die Zahl mit Hilfe des privaten Schlüssels und schickt eine MD5-Prüfsumme dieser Zahl an den Server zurück. Er schickt nicht die ursprüngliche Zahl, da ein Dritter evtl. bei mehreren Einwählversuchen mithören, und so die Methode zur Zufallszahlenerzeugung herausfinden könnte. Dadurch könnte er sich für den Benutzer ausgeben, ohne den privaten Schlüssel überhaupt zu besitzen. Falls die Prüfsumme, die der Server erhält, der Prüfsumme der von ihm zuerst abgeschickten Zahl entspricht, lässt der Daemon das Einwählen des Clients zu. Der Server kann durch dieses Verfahren sicher sein, dass der Client auch derjenige ist, für den er sich ausgibt, da nur der Besitzer des privaten Schlüssels die Nachricht entschlüsseln kann. Beide SSH-Versionen beherrschen diese Methode, wobei die SSH1 dafür RSA und die SSH2 DSA verwendet (siehe Tabelle 2. Allerdings kann die SSH2 die Methode auch so behandeln, als ob sie Rechnernamen basiert sei, indem sie die Schlüssel anstatt der Rechner- bzw. Benutzernamen in den entsprechenden Dateien speichert Verschlüsselung der Datenübertragung Zu unterscheiden gilt es zunächst zwischen symmetrischen und asymmetrischen Verschlüsselungsverfahren. Die symmetrischen Verfahren sind schneller in ihrer Ausführung als die asymmetrischen, aber dafür für Angreifer leichter zu entschlüsseln. Deshalb wird oft die asymmetrische Verschlüsselung kombiniert mit der symmetrischen verwendet, indem man die zu versendenden Daten symmetrisch chiffriert, und den dazugehörigen Schlüssel asymmetrisch chiffriert mitschickt. Die starke Chiffrierung - also die asymmetrische Verschlüsselung - wird bei der SSH nur für den Authentifizierungsprozess des Servers in Form digitaler Signaturen benutzt. Für die Datenübertragung selbst wird die symmetrische Verschlüsselung genutzt. Bei den symmetrischen Chiffriermethoden wird ein Sitzungsschlüssel verwendet, den beide Kommunikationspartner kennen müssen. Die Teilnehmer der Kommunikation müssen diesen vor Beginn der verschlüsselten Datenübertragung untereinander austauschen (siehe Kapitel Der Diffie- Hellmann-Schlüsselaustausch. Wie in Tabelle 1 aufgelistet, verwendet die SSH die symmetrischen Verschlüsselungsverfahren DES, 3DES, IDEA, Blowfish, Twofish, Arcfour, Cast128, Serpent oder AES zur Datenübertragung. Der Unterschied der einzelnen Verfahren besteht in der Länge des verwendeten Schlüssels, der verwendeten Blockgröße für die Blockverschlüsselung und im Aufbau des Algorithmus, der die Ver- bzw. Entschlüsselung bewerkstelligt. 14

15 Die hier vorgestellten symmetrischen Verfahren - außer Arcfour (siehe unten - sind Blockverschlüsseler, d.h. die zu verschlüsselnden Daten werden nicht Bit für Bit, sondern blockweise chiffriert. Das verwendete Verfahren zur Blockverschlüsselung heißt Cipher Block Chaining (CBC. Dabei wird jeweils ein Block fester Größe zuerst mit dem Sitzungschlüssel chiffriert und dann mit dem darauf folgenden Block mittels XOR verknüpft. Das bedeutet, dass jeder Block von seinem Vorgänger abhängt. Bei der Entschlüsselung wird dementsprechend jeweils ein Block dechiffriert und mit dem vorangegangenen mittels XOR verknüpft. Eine schematische Darstellung des CBC-Verfahrens zeigt Abbildung 3. Abbildung 3: Schematische Darstellung des CBC Verfahrens. Das einzige Verschlüsselungsverfahren, dass nicht im CBC Modus arbeitet ist Arcfour. Es benutzt die so genannte Stromchiffrierung: Nicht die ganzen Blöcke werden mit den vorhergehenden XORverknüpft, sondern die einzelnen Bits der Daten werden verschlüsselt und dann mit dem vorhergehenden XOR-verknüpft. DES wurde 1977 entwickelt und das letzte mal 1993 erneuert. Es benutzt einen 56-Bit langen Schlüssel, der heutzutage allerdings als zu kurz und damit als zu unsicher gilt. Es werden acht Byte große Blöcke benutzt. Durch das DES Verfahren erfährt die SSH eine Leistungseinbuße von 29% gegenüber keiner Verschlüsselung [7]. 3DES ist im Prinzip die dreifache Anwendung des DES Verfahrens mit zwei verschiedenen Schlüsseln. Die effektive Schlüssellänge ist hier 112 Bit lang. Die Blockgröße beträgt wie bei DES acht Byte. Die zu chiffrierenden Daten werden erst mit dem ersten Schlüssel chiffriert. Dann werden sie mit dem zweiten Schlüssel dechiffriert, um nochmals mit dem ersten chiffriert zu werden. Durch dieses Verfahren erfährt die SSH eine Leistungseinbuße von 55% [7]. IDEA ist patentiert, und kann in den meisten Ländern nicht kommerziell verwendet werden. Daher wird 3DES auch als Standardverfahren der SSH verwendet, obwohl IDEA schneller arbeitet. IDEA benutzt einen 128 Bit Schlüssel, acht Byte lange Blöcke, und sorgt für eine eine Leistungseinbuße von 45% [7]. Blowfish wurde konzipiert, um eine schnelle und freie Alternative zu anderen Verfahren zu bieten. Blowfish erlaubt alle Schlüssellängen zwischen 32 und 448 Bit, und die Blockgröße 15

16 beträgt acht Byte. SSH benutzt einen 128 Bit langen Schlüssel. Die Leistungseinbuße beträgt 22% [7]. Twofish baut auf Blowfish auf und ist lizenzfrei. Es kann 128, 192 oder 256 Bit lange Schlüssel verwenden. Die Blockgröße beträgt 16 Byte. Das Verfahren ist schneller als Blowfish. Arcfour erlaubt eine variable Schlüssellänge und ist ein Stromchiffreverfahren. SSH benutzt einen 128 Bit langen Schlüssel. Die Leistungseinbuße beträgt 9% [7]. AES ist der Nachfolger von DES und hieß früher Rijndael. Dieses Verfahren erlaubt 128, 192 und 256 Bit lange Schlüssel. Serpent ist ein von AES abgeleiteter Verschlüsselungsalgorithmus und erlaubt Schlüssel von 128, 192 und 256 Bit Länge. Die drei Standardverfahren zur Verschlüsselung, die bei der SSH1 eingesetzt werden, sind DES, 3DES und IDEA. Bei der SSH2 sind es 3DES, Blowfish und Twofish. Dass diese symmetrischen Verfahren - außer DES - als relativ sicher angesehen werden können veranschaulicht folgendes Beispiel: Um alle IDEA Schlüssel per Brute-Force-Attack (also einfaches Durchprobieren aller Möglichkeiten zu erhalten, braucht man eine Milliarde Chips, die in einer Sekunde eine Milliarde Schlüssel durchprobieren um dann in 10 Billionen Jahren endlich alle Möglichkeiten durchprobiert zu haben [9]. Allerdings ist es wahrscheinlich, dass man ohne alle Schlüssel durchprobiert zu haben, bereits an den richtigen Schlüssel gelangt ist. Die RSA Firma hat z.b. einige Wettbewerbe veranstaltet, bei denen man durch DES verschlüsselte Daten dechiffrieren musste, um zu zeigen, dass DES zu unsicher ist und man sicherere Verschlüsselungsalgorithmen wie etwa RSA benötigt. Bei diesen Wettbewerben wurde jeweils ein Preisgeld von US Dollar ausgeschrieben. Der erste dieser Wettbewerbe fand 1997 statt. Ein Team aus Colorado knackte den Code in weniger als vier Monaten. Der zweite Wettbewerb wurde 1998 von Distributed.Net innerhalb von 41 Tagen gewonnen. Im selben Jahr gewann die Electronic Frontier Foundation (EFF den Wettbewerb innerhalb von 56 Stunden knackten Distributed.Net in Zusammenarbeit mit der EFF den Code innerhalb von 22 Stunden und 15 Minuten. Dies gelang mit Hilfe des über das Internet verteilte Computernetzwerk namens Deep Crack, bei dem fast PCs zusammenarbeiteten. Diese berechneten 245 Billionen Schlüssel pro Sekunde [6]. Dies zeigt, dass DES nicht mehr als sicher angesehen werden kann. Deshalb ist DES auch in der zweiten Version der SSH nicht mehr implementiert Der SSH-Agent Der Vorteil der RSA- bzw. DSA-Authentifizierung (siehe Kapitel Authentifizierungsmöglichkeiten ist, dass man kein Passwort eingeben muss, um sich auf dem entfernten Rechner einzuwählen. Allerdings ist es sinnvoll den privaten RSA bzw. DSA Schlüssel mit einer Passphrase zu schützen, mit dem der Schlüssel dann chiffriert wird. Falls nämlich ein Dritter an den Schlüssel geraten sollte, 16

17 kann er damit ohne die Passphrase nichts anfangen. Umgekehrt bringt ihn die Passphrase alleine auch nicht weiter. Nun muss man aber beim Einwählen in einen Server wieder ein Passwort bzw. die Passphrase eingeben um den RSA bzw. DSA Schlüssel zu dechiffrieren. Dadurch wäre der Vorteil bezüglich der Benutzerfreundlichkeit bei einem RSA- bzw. DSA-Authentifizierungsverfahren gegenüber der auf einem Passwort basierenden Einwahl entfallen. Der SSH-Agent bietet eine Lösung bei dem man die Passphrase zur Dechiffrierung des Schlüssels nur einmal eingeben muss. Der SSH-Agent behält den Schlüssel nach der Dechiffrierung im Arbeitsspeicher. Dadurch kommt niemand ohne weiteres an den Schlüssel heran, da er nur in chiffrierter Form auf der Festplatte gespeichert wird, gleichzeitig kann die SSH trotzdem jederzeit auf den Schlüssel zurückgreifen. Der SSH-Agent läuft als eigenständiger Prozess im Hintergrund. Wenn die SSH gestartet wird, erkennt sie einen laufenden SSH-Agent und greift bei Bedarf auf den vom SSH-Agent gespeicherten Schlüssel zu. 2.3 Das Verbindungsprotokoll Das oberste auf dem Authentifizierungsprotokoll aufbauende Protokoll ist für das Umleiten von Portverbindungen (siehe Kapitel Tunneln, das Übertragen von Steuersignalen, die Weiterleitung von Umgebungsvariablen, das Umleiten des Displays auf einen anderen Rechner und das Ausführen von Programmen auf dem Server zuständig [4]. Das Verbindungsprotokoll ist insbesondere dafür zuständig, dass diese Dienste parallel ablaufen können. Dies bewerkstelligt es mit Hilfe von Kanälen, die das Protokoll zu einer Verbindung multiplexen kann. Für jeden angeforderten Dienst wird ein neuer Kanal geöffnet. Wenn ein Dienst beendet wird, muss der zugehörige Kanal geschlossen werden. Die Ausgabe eines Dienstes wird über seinen Kanal an den Client geschickt. Genauso wird die Eingabe des Benutzers eines Dienstes über den entsprechenden Kanal an den Server geschickt. Jeder Kanal kann eine maximale Paketgröße festlegen. Diese Option kann z.b. dazu genutzt werden, effizienter mit interaktiven Diensten auf langsamen Verbindungen zu arbeiten, indem man einen kleinen Wert für die Paketgröße vorschreibt. Insbesondere ist das bei der Übertragung von Mausbewegungen von einem Window-System nützlich, da die zu übertragenen Daten sehr klein sind und eine schnellst mögliche Reaktion des Window-Systems wünschenswert ist. Normalerweise ist der Standarddienst, der als erster gestartet wird, eine sogenannte Shell, die als Arbeitsoberfläche dient und auf der Befehle ausgeführt werden können. Alternativ kann auf einem Unix-System auch eine X11-Session, die auf den lokalen Rechner umgeleitet wird, als Arbeitsoberfläche dienen. X11 ist ein weit verbreitetes Window-System. Für alle Arbeitsoberflächen gilt, dass Dienste, die von dort aus gestartet werden, einen neuen Kanal öffnen müssen. So kann verhindert werden, dass ein Dienst, von dem aus ein anderer Dienst gestartet wird, automatisch beendet wird, sobald der zweite Dienst beendet wird. 17

18 2.3.1 Tunneln Unter Tunneln versteht man das Umleiten von Portverbindungen. So wird einem anderen Dienst wie Electronic Mail oder File Transfer eine durch die SSH verschlüsselte Verbindung gewährleistet. Dazu starten die SSH auf dem Klientenrechner und der SSH-Daemon auf dem Server jeweils einen lokalen Proxyserver. Der zu tunnelnde Dienst kommuniziert nur über diesen Proxy. Wenn man beispielsweise seine Mail über einen sicheren Kanal abrufen will, startet man die SSH mit der Angabe, sie solle sich als Proxyserver verhalten. Dann konfiguriert man das Mailprogramm so, dass es die Mail nicht direkt über den Mailserver holt, sondern den Proxy anspricht. Voraussetzung ist natürlich, dass auf dem Server ein entsprechender SSH-Daemon läuft. Wenn nun das Mailprogramm die Mail abrufen will, sendet es seine Datenpakete an den SSH-Proxy, der die Pakete verschlüsselt und an den SSH-Daemon weiterleitet. So werden die Datenpakete des Post Office Protokolls (POP in dem Binär-Protokoll der SSH gekapselt. Der SSH-Daemon des Servers entschlüsselt die SSH-Pakete und leitet die darin enthaltenen POP-Pakete an den lokalen Mailserver weiter. Der Mailserver kann dann wiederum seine Pakete an den lokalen SSH-Daemon schicken, so dass das ganze dann in die andere Richtung verläuft. Abbildung 4: Schematische Darstellung des Tunnelns. 3 Wovor die SSH schützt bzw. nicht schützt 3.1 Wovor die SSH schützt Die SSH garantiert bei richtiger Handhabung die Geheimhaltung der versendeten Daten, die Unversehrtheit der empfangenen Daten und die Authentisierung von Clients und Server. Sie schützt vor 18

19 passiven, d.h. der Beobachtung des Datenverkehrs, und aktiven Angriffen, d.h. der Manipulation des Datenverkehrs. Die SSH schützt vor folgenden Attacken: IP-Spoofing: Ein Angreifer ändert die IP-Adresse eines Datenpakets, so dass es so aussieht, als ob das Paket von einem anderen Rechner stammt. Dies kann ein Angreifer bei Einwählprogrammen wie rsh, die keine sichere Authentifizierung durchführen, so ausnutzen, dass er sich für einen vertrauenswürdigen Client oder Server ausgibt. Durch die sichere Authentifizierung kann die SSH mit Hilfe des MAC feststellen, ob ein Paket tatsächlich vom Kommunikationspartner stammt. DNS-Spoofing: Der Angreifer leitet den angesprochenen Rechnernamen auf seine IP-Adresse um, und kann sich so für den angesprochenen Rechner ausgeben. Genau wie beim IP-Spoofing kann er dies nutzen, um sich als einen vertrauenswürdigen Rechner ausgeben zu können. Das Abhören von Klartext und Passwörtern durch einen Angreifer. Durch die Verschlüsselung der Daten, und den Einsatz des eindeutigen Sitzungsschlüssels, kann man diese Attacke erfolgreich abwehren. Die Manipulation von übertragenen Daten von einem Angreifer. Dies kann mit Hilfe des MACs verhindert verhindert werden. Zwar besitzen die unter dem SSH-Protokoll liegenden Schichten wie TCP/IP Schutzmechanismen, um Netzwerkfehlern vorzubeugen. Das schützt aber natürlich nicht vor Manipulationen oder dem Abhören von Daten. Die SSH garantiert, dass Daten nicht manipuliert oder abgehört werden, oder dass ein Angreifer sich fälschlicherweise als ein vertrauenswürdiger Partner ausgibt. Falls ein Angreifer Kontrolle über den Netzverkehr erhalten sollte, kann er die SSH höchstens dazu bringen die Verbindung abzubrechen. 3.2 Wovor die SSH nicht schützt Die SSH schützt einen Benutzer nicht vor sich selbst. D.h. er muss darauf achten, Passwörter und Schlüssel, z.b. durch entsprechende Benutzerrechtvergabe, geheim zu halten. Ein durch eine Passphrase geschützter Schlüssel gibt zusätzlichen Schutz, da ein Angreifer mit einer der beiden Informationen wenig anfangen kann. Falls ein Angreifer allerdings Zugriff auf das lokale System hat, kann er unter Umständen Passwörter und Schlüssel auslesen, und sich so auf anderen Rechnern unter falschem Namen einwählen. Zugriff kann ein Angreifer durch Unterlaufen des Systems erhalten. Falls ein Verzeichnis, das sensitive Daten enthält, mit NFS exportiert wird, kann das dem Angreifer das Auslesen erleichtern. Auch bei Betriebssystemen wie Windows 9.x, bei denen es keine Benutzerrechtvergabe gibt, hat es ein Angreifer leichter an sensitive Daten zu gelangen. Außerdem sollte man die benutzte Version der SSH regelmäßig aktualisieren. Das verhindert Angriffe über bekannte Sicherheitslücken [10], die in den neuesten Versionen der Implementierungen behoben werden. 19

20 4 Quellen 1. Daniel J. Barrett, Richard E. Silverman: SSH - The Secure Shell. The Definitive Guide. O Reilly Tatu Ylönen: SSH Transport Layer Protocol, März Tatu Ylönen: SSH Authentication Protocol, Februar Tatu Ylönen: SSH Connection Protocol, Januar Anne Carasik, Steve Acheson: The Secure Shell (SSH Frequently Asked Questions, 2. November Ross Keith, Kames F. Kurose: Computer networking: a top-down approach featureing the Internet, Addison-Wesley Mathias Brandstetter: Secure Shell, Linux Magazin 03/98 8. Otto Spaniol, Mesut Günes: Sicherheit in Kommunikationsnetzen, 14. Juli Oliver Litz, Daniel Rößler: Sichere Internetkommunikation mit SSH (Secure Shell, Bugtraq, 20