Seminarbeitrag

SSH2 Sicherheit auf derAnwendungsschicht

zum Seminar

Sicherheit inKommunikationsprotokollen

Björn Wargenau

EINLEITUNG...............................................................................................................2

Aktuelle Versionen und Implementierungen von SSH.......................................................3

DIE SSH2 PROTOKOLLE...........................................................................................3

Protokollarchitektur .............................................................................................................3

Das Transport Layer Protokoll............................................................................................5

Binary Packet Protocol........................................................................................................5Kompression.......................................................................................................................7Verschlüsselung...................................................................................................................7Integrität der übermittelten Daten........................................................................................8Schlüsselaustausch..............................................................................................................9

Diffie−Hellman Key Exchange...........................................................................................11

Das User Authentication Protocol .....................................................................................13

Authentication Requests....................................................................................................13None Authentication Request............................................................................................14Banner Messages...............................................................................................................16Public Key Authentisierung...............................................................................................16Authentisierung mittels Passwort.......................................................................................17Hostbased Authentisierung................................................................................................18

DAS CONNECTION PROTOCOL.............................................................................19Kanäle...............................................................................................................................19Sessions.............................................................................................................................21TCP/IP Port Forewarding..................................................................................................24

SICHERHEIT VON SSH2.........................................................................................26Sicherheit gegen aktive Angriffe.......................................................................................26Sicherheit gegen passive Angriffe.....................................................................................27Weitere Sicherheitsrisiken.................................................................................................27

QUELLEN .................................................................................................................28

Einleitung

Viele Programme die heute in Netzwerken für Kommunikation und Datenübertragungverwendet werden sind unsicher, dazu zählen zum Beispiel die häufig verwendetenAnwendungen Telnet, ftp, Pop sowie die r−Tools. All diese Programme haben zweiProbleme:

Die Übertragung von Benutzername und Passwort im KlartextKeine Authentisierung des Kommunikationspartners

Dies kann von Angreifern leicht ausgenutzt werden, um sich Zugang zu Postfächern oderBenutzerlogins zu beschaffen.Empfängt zum Beispiel ein Benutzer mittels Pop in einem Ethernet seine E−Mail, so kannsein Login und Passwort leicht mit einem Snifferprogramm abgefangen werden.Diese Programme können auch von Laien bedient werden, z.b. wird mit KDE das ProgrammKSniff ausgeliefert, welches sogar eine graphische Oberfläche hat.

Mit Hilfe von SSH hat der Benutzer die Möglichkeit die Datenübertragung zu verschlüsselnund sicherzustellen das der mit dem richtigen Partner kommuniziert.

Das Hauptanwendungsfeld von SSH ist der Ersatz von Telnet, es gibt aber noch weitereNutzungsmöglichkeiten.SSH kann auch dazu verwendet werden die Übertragung von Benutzerdaten durch unsichereProtokolle, wie z.B. Pop zu sichern.

SSH kann vom Benutzer auf dem System installiert werden, falls es auf dem System nichtvorhanden ist, es sind keine root Rechte erforderlich.

Aktuelle Versionen und Implementierungen von SSH

Die aktuelle Versionsnummer von SSH ist 2.3SSH2 ist nicht kompatibel mit der Version SSH1. Das bedeutet ein SSH1 Server kann keineAnfragen von SSH2 Clients beantworten. Der umgekehrte Fall SSH2 Server und SSH1 Clientkann vom Server unterstützt werden, allerdings muss beim Client in diesem Fall eineWarnung angezeigt werden.

Implementierungen von SSH2 gibt es unter anderem vonSSH Communications Security www.ssh.comEine freie Implementierung gibt es vom Open SSH Project www.openssh.org

Die SSH2 Protokolle

Protokollarchitektur

Jeder SSH2 Server muss einen Host Key besitzen. Er kann aber auch mehr als einen besitzen.Mehrere Server können sich den gleichen Host Key teilen. Jeder Host muss mindestens einenHost Key für jedes zu unterstützende Verschlüsselungsverfahren besitzen. Der host key wird während des Schlüsselaustausches verwendet, um zu überprüfen, ob derClient wirklich mit dem korrekten Server spricht. Damit dies möglich ist, muss der Clientvorher den public key des Servers kennen. Dazu können zwei verschiedene VertrauensModelle benutzt werden:

Client Datenbank

Der Client verfügt über eine lokale Datenbank in der jedem Hostnamen der public key desHosts zugeordnet ist. Der Vorteil dieser Methode ist das keine zentrale Stelle zurAuthentisierung erforderlich ist.Ein Nachteil ist das der Benutzer sich selbst um die Verwaltung der public keys kümmernmuss.

Certification Author ity CA

Hier wird die Verknüpfung von Hostname und public key von einer certification authorityzertifiziert. Der Vorteil dieser Variante ist das diesem Verfahren der Client nur den CA keyzu kennen braucht.Nachteile sind: jeder host key muss von der CA zertifiziert werden und der Benutzer muss derCA vertrauen.

SSH2 Implementierungen sollten bei dem Test von public keys nach der "best effort"Strategie vorgehen. Das bedeutet das bei der Zuordnung von Hostname zu public key Fehlerauftreten können. Im Protokoll ist die Möglichkeit vorgesehen, das bei der ersten Verbindungzwischen einem Client und einem Host die Hostname − public key Verknüpfung nichtüberprüft wird. In diesem Fall ist die Verbindung weiterhin sicher gegen passives Abhören,aber nicht gegen man−in−the−middle Angriffe. Dies vereinfacht die Benutzung von SSH, dader public key des Servers in diesem Fall bei der ersten Verbindung runtergeladen werdenkann. Allerdings ist diese Art sich einen public key zu beschaffen auch einSicherheitsproblem. Daher wird vorgeschlagen diese Option zu deaktivieren.

SSH2 Implementierungen können zusätzliche Methoden zur Verifikation von Host keys zurVerfügung stellen. Ein Beispiel ist ein hexadezimaler Fingerprint der mit Hilfe des Hasch−Algorithmus SHA−1 erzeugt wurde. Derartige Fingerprint können einfach übers Telefon oderVisitenkarten übermittelt werden.

SSH wird in 3 Protokollen definiert:

� Transport layer protocol [SSH−TRANS]

� User authentication protocol [SSH−USERAUTH]

� Connection protocol [SSH−CONN]

Das Transport Layer Protokoll

Dieses Protokoll stellt Server Authentisierung, Vertraulichkeit und Integrität zur Verfügung.

Verbindungsaufbau

Der Client baut eine TCP Verbindung zum Server auf. Dazu wird in der Regel Port 22benutzt, dieser wurde für SSH registriert. Nun senden Server und Client einen "identificationstring" der Form: "SSH−protoversion−softwareversion comments" .

Der Server kann, bevor er den "identification string" sendet, noch andere Daten senden.Clients müssen in der Lage sein diese Daten zu erkennen, sie dürfen aber ignoriert werden.Die Versionsinformationen müssen aus printable us−ascii bestehen und dürfen keineLeerzeichen oder Minuszeichen enthalten. Der im "identification sting" enthalteneKommentarteil kann zusätzliche Informationen enthalten, die dem Benutzer beiProblemlösungen helfen sollen. Nachdem beide Seiten die Versionsinformationenausgetauscht haben beginnt der Schlüsselaustausch. Alle Pakete die von nun an ausgetauchtwerden sollten das "binary packet protocol" benutzen.

Binary Packet Protocol

Pakete dieses Protokolls haben die folgende Form:

packet_length

padding_length

payload

randompadding

mac

Bedeutung der Felder:

uint32 packet_length:Die Länge des Paketes in Bytes ohne das Feld packet_length und ohne den MAC.

byte padding_length:Enthält die Länge des Feldes padding in Bytes.

byte[packet_length − padding_length − 1] payload:Dieses Feld enthält die Nutzdaten.

byte [padding_length] random padding:Zufällige Bytefolge mit der das Paket vergrößert wird, bis die Paketlänge ohne MACentweder Vielfaches von 8 oder der "cipher block size" ist, je nachdem welcher derbeiden Werte größer ist. Mindestens 4 Bytes lang.

byte [mac_length] mac:Dieses Feld enthält den "message authentication code", nachdem einer ausgehandeltwurde. Am Anfang ist dieses Feld leer.

Die minimale Länge eines Binary Packet Protocol Packetes ist 16 Bytes. Alle SSH2Implementierungen müssen in der Lage sein Pakete zu verarbeiten bei denen die Länge desplayloads 32768 Bytes oder kleiner ist.

Kompression

Es kann zwischen Client und Server ein Kompressionsverfahren ausgehandelt werden. Mitdiesem wird dann das Feld payload verschlüsselt. Bislang sind zwei Kompressionsverfahrendefiniert:

none

muss implementiert werden es erfolgt keine Kompression

zlib

kann implementiert werden GNU ZLIB (LZ77) Kompression [RFC−1950] und [RFC−1951].

Verschlüsselung

Verschlüsselungsalgorithmus und Schlüssel werden während des Schlüsselaustauschesausgehandelt.Ist Verschlüsselung aktiviert dann müssen die Felder packet length, paddinglength, payloadund padding verschlüsselt werden. Es sollen Schlüssel mit einer effektiven Schlüssellängevon mindestes 128 Bit verwendet werden. Die Verschlüsselungsverfahren müssen für beideRichtungen unabhängig sein, das bedeutet es ist möglich für die Richtung Client Server einanderes Verfahren zu verwendet als bei der Richtung Server Client.

Folgende Verschlüsselungsverfahren sind momentan definiert:

Verfahren Implementierung

3des−cbc REQUIRED

blowfish−cbc

RECOMMENDED

twofish−cbc RECOMMENDED

arcfour OPTIONAL

idea−cbc OPTIONAL

cast128−cbc OPTIONAL

none OPTIONAL

Integrität der übermittelten Daten

Um die Integrität der übermittelten Daten sicherzustellen wird jedem Packet ein MAC(message authentication code) hinzugefügt. Dieser wird aus dem Inhalt des Paketes, derSequenznummer des Paketes und einen Geheimnis, das nur Client und Server kennen,berechnet.Mac−Algorithmus und Schlüssel werden während des Schlüsselaustausches ausgehandelt.Am Anfang der Verbindung ist kein MAC− Algorithmus aktiv und die Länge des MACFeldes ist 0. Nach dem Schlüsselaustausch wird der MAC folgendermaßen berechnet:

MAC = mac(key, sequence_number, unencrypted_packet)

wobei

� keyein Geheimnis ist, das nur Client und Server kennen

� sequence_numberdie Sequenznummer des aktuelles Paketes istes wird von 0 gezählt, bei 2^32 springt der Zähler wieder auf 0Die Sequenznummer wird nie gesendet.

� unencrypted_packetdie Felder packet_length,padding_length,payload and padding sind

Schlüsselaustausch

Es gibt für SSH2 nur eine definierte Methode um Schlüssel auszutauschen, hierbei handelt essich um das Diffie−Hellman Verfahren.

Der Schlüsselaustausch beginnt damit das Client und Server das folgende Paket senden:

SSH_MSG_KEXINIT

cookie (random bytes)

kex_algorithms

server_host_key_algorithms

encryption_algorithms_client_to_server

encryption_algorithms_server_to_client

mac_algorithms_client_to_server

mac_algorithms_server_to_client

compression_algorithms_client_to_server

compression_algorithms_server_to_client

languages_client_to_server

languages_server_to_client

first_kex_packet_follows

uint32 0 (reserved for future extension)

Bedeutung der Felder:

byte SSH_MSG_KEXINIT:Ein Byte, das den Typ des Paketes bestimmt

byte[16] cookie (random bytes):Zufälliger Wert, soll verhindern das die andere Seite die Schlüssel undSitzungskennung feststellen kann

String kex_algor ithms:Der Schlüsselaustauschalgorithmus

String server_host_key_algor ithms:List der Algorithmen die der host key des Servers unterstützt

String encryption_algor ithms_client_to_server :Liste der akzeptierbaren symmetrischen Verschlüsselungsalgorithmen

String encryption_algor ithms_server_to_client:Liste der akzeptierbaren symmetrischen Verschlüsselungsalgorithmen

String mac_algor ithms_client_to_server :Liste der akzeptierbaren MAC− Algorithmen

String mac_algor ithms_server_to_client:Liste der akzeptierbaren MAC− Algorithmen

String compression_algor ithms_client_to_server :Liste der akzeptierbaren Kompressions−Algorithmen

String compression_algor ithms_server_to_client:Liste der akzeptierbaren Kompressions−Algorithmen

Der für die Verbindung verwendete Verschlüsselungs−, Kompressions− und MessageAuthenticationalgorithmus ist jeweils der erste in der Liste des Clients, der auch beim Servervorhanden ist.

Nach dem sich Client und Server mit dem KEXINIT−Packet auf Verschlüsselungs−,Kompressions− und Message− Authentisierungsalgoithmen geeinigt haben wird derSchlüsselaustauschalgorithmus aufgerufen.

Diffie−Hellman Key Exchange

x=ZufallsZahl() y=ZufallsZahl() e=g^x mod p f=g^y mod p

e

f

K=e y mod pH=hash(V_C, V_S, I_C, I_S, K_S, e, f, K)S=signatur(H)

S

K_S

Verifiziert K_SK=f^x mod pH=hash(V_C, V_S, I_C, I_S, K_S, e, f, K)Teste ob s stimmt

CLIENT SERVER

K Gemeinsames Geheimnis von Server und Clientx Zufallszahl, nur dem Client bekanty Zufallszahl, nur dem Server bekantg Generator, hier in der Regel 2e wird Client berechnet und gesendet lässt ohne y keine Rückschlüsse auf

Geheimnis zuder Server benötigt e um das Geheimnis zu ermitteln

f wird Server berechnet und gesendet lässt ohne x keine Rückschlüsse aufGeheimnis zuder Client benötigt f um das Geheimnis zu ermitteln

K_S Public key des Serversp Primzahl

17976931348623159077083915679378745319786029604875601170644423684197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007

V_S, V_C Version Strings von Client und ServerI_S, I_C Payload der Keyexchange Packete

Das User Authentication Protocol

Das User Authentication Protokoll setzt auf dem SSH Transport Layer Protokoll auf.Es authentisiert den Benutzer beim Server. Es geht davon aus das Integrität undVertraulichkeit durch die darunter liegenden Protokolle zur Verfügung gestellt werden.

Authentication Requests

Authentication Requests müssen die folgende Form haben:

Bedeutung der Felder:

byte : SSH_MSG_USERAUTH_REQUESTEin Byte, das den Typ des Paketes bestimmt

String user name :Name des Benutzers der sich beim Server anmelden will

String service name : Name des Dienstes den der Benutzer nach der Authentisierung benutzen will

String method name :Die Methode mit der sich der Benutzer authentisieren will

Existiert der vom Client übermittelte Benutzername nicht, dann kann der Server dieVerbindung beenden, oder eine Liste der möglichen Authentisierungsmethoden senden, aberjeder Authentisierungs−Versuch muss dann fehlschlagen. Damit wird es einem Angreifernicht ermöglicht zu testen, ob ein bestimmter Benutzername existiert.

SSH_MSG_USERAUTH_REQUESTuser name (in ISO−10646 UTF−8 encoding)service name (in US−ASCII)method name (US−ASCII)Rest des Paketes ist abhängig von der gewählten Authentisierungs−Methode

Lehnt der Server einen Authentisierungsversuch des Clients ab dann antwortet er mit demPacket:

SSH_MSG_USERAUTH_FAILUREauthentications that can continuepartial success

Bedeutung der Felder:

byte : SSH_MSG_USERAUTH_FAILUREEin Byte, das den Typ des Paketes bestimmt

String user name :Eine Liste der Authentisierungsmethoden die noch zum Erfolg führen können

boolean partial success : Falsch, da die Authentisierung fehlgeschlagen ist

War die Authentisierung des Clients erfolgreich dann antwortet der Server mit :

SSH_MSG_USERAUTH_SUCCESS

Bedeutung der Felder:

byte : SSH_MSG_USERAUTH_SUCCESSEin Byte, das den Erfolg der Authentisierung anzeigt

Alle Nachrichten, die von nun an vom Client empfangen werden, werden an den Dienstweitergeleitet , der über dem User Authentication Protocoll läuft.Nach Empfang der Nachricht SSH_MSG_USERAUTH_SUCCESS startet der Server denvom Benutzer angegebenen Dienst.

None Authentication Request

Ein Client kann die vom Server unterstützten Authentisierungsmethoden anfordern, indem erdem Server einen Authentication Request mit dem method namen "none" sendet.Daraufhin kann der Server die Liste mittels eines SSH_MSG_USERAUTH_FAILUREPaketes zum Client senden.

Banner Messages

Das User Authentication Protocoll erlaubt es dem Server eine sogenannte Banner Messagezum Client zu senden bevor die Authentisierung stattfindet. Diese sollte dann vom Client anden Benutzer weitergeleitet werden.

Public Key Authentisierung

Diese Art der Authentisierung muss von allen SSH2 Implementierungen unterstützt werden.Bei diesem Verfahren gilt der Besitz des privaten Schlüssels als Authentisierung.Der private Schlüssel des Benutzers ist in der Regel verschlüsselt gespeichert und muss vordem Erstellen der Signatur mit Hilfe der Passphrase entschlüsselt werden.

Um die Authentisierung durchzuführen sendet der Client das folgende Packet.Die allgemeine Form eines SSH_MSG_USERAUTH_REQUEST ist weiter obenbeschrieben.

SSH_MSG_USERAUTH_REQUESTuser nameservice"publickey"TRUEpublic key algorithm namepublic key to be used for authenticationsignature

Bedeutung der Felder:

string : signature

Eine mit dem privaten Schlüssel des Benutzers erstellte Signatur von session identifier und dem oben angegebenen Packet ohne das Feld Signatur

Der Server muss überprüfen ob der vom Client verwendete Schlüssel für Authentisierungenverwendet werden darf und ob die Signatur stimmt. Falls dies der Fall ist, ist dieAuthentisierung erfolgreich.

Authentisierung mittels Passwort

Bei diesem Verfahren gilt die Kenntnis eines geheimen Passwortes als Authentisierung.Der Client sendet dazu folgendes Packet an den Server:

SSH_MSG_USERAUTH_REQUESTuser nameservice"password"FALSEplaintext password (ISO−10646 UTF−8)

Da über das SSH2 Transport Layer Protokoll eine verschlüsselte Datenübertragungdurchgeführt wird, stellt die Übermittlung des Passwortes kein Sicherheitsrisiko dar. DerServer antwortet entweder mit der Nachricht SSH_MSG_USERAUTH_SUCCESS oderSSH_MSG_USERAUTH_FAILURE.

Hostbased Authentisierung

Dieses Verfahren zur Authentisierung basiert auf dem Rechnernamen des Clients, dem Logindes Benutzers auf diesem Rechner und einem privaten Schlüssel auf dem Client. Es istbequem aber nicht besonders sicher.

Der Client authentisiert sich indem er eine mit dem privaten Schlüssel des Clients erstellteSignatur sowie den Rechnernamen und das Login des Benutzers zu Server sendet:

SSH_MSG_USERAUTH_REQUESTuser nameService"host based"public key algorithm for host keypublic host key and certificates for client hostclient host name (FQDN; US−ASCII)client user name on the remote host (ISO−10646 UTF−8)Signature

Bedeutung der Felder:

string : signature

Eine mit dem privaten Schlüssel des Clients erstellte Signatur von session identifier, und dem oben gezeigten Packet ohne das Feld Signatur.

Der Server überprüft ob der host key zu dem Namen des Client Rechners passt, ob derangegebene Benutzer sich von diesem Rechner aus einloggen darf und ob die Signatur gültigist. Der Benutzername kann bei der Authentisierung auch ignoriert werden.

Falls dieses Verfahren verwendet wird muss darauf geachtet werden, das ein normalerBenutzer nicht Zugriff auf den privaten Schlüssel des Client Rechners hat.

Das Connection Protocol

Das Connection Protokoll läuft über dem SSH2 User Authentication Protocol.Es multiplext den verschlüsselten Kanal in verschiedene logische Kanäle. Die vomConnection Protokoll zur Verfügung gestellten Kanäle können von vielen Anwendungenbenutzt werden.

Standardmäßig wird Unterstützung für sichere interaktive Shellsitzungen, Tunneln beliebigerTCP/IP Ports und sichere X11 Verbindungen zur Verknüpfung gestellt.

Kanäle

Alle Terminal Sitzungen, X11 Verbindungen usw. laufen über Kanäle. Diese können vonClient und Server erstellt werden. Will eine Seite einen Kanal öffnen, dann ordnet sie diesem zuerst eine Nummer zu undsendet dann folgendes Packet:

SSH_MSG_CHANNEL_OPENchannel type (restricted to US−ASCII)sender channelinitial window sizemaximum packet sizeHier folgen vom Kanal abhängige Daten

Bedeutung einiger Felder:

String : channel type Die Art der Verbindung z.B.− X11− Shell

uint32 sender channel :Lokale Nummer des Kanals

uint32 maximum packet size : maximale Größe von Paketen die empfangen werden

Nun entscheidet die andere Seite ob der Kanal geöffnet werden kann und antwortet mit:

SSH_MSG_CHANNEL_OPEN_CONFIRMATIONrecipient channelsender channelinitial window sizemaximum packet sizeHier folgen vom Kanal abhängige Daten

oder mit

SSH_MSG_CHANNEL_OPEN_FAILURErecipient channelreason codeadditional textual information (ISO−10646 UTF−8) [RFC−2044])language tag (as defined in [RFC−1766])

Daten werden dann mit Paketen der folgenden Form übertragen:

SSH_MSG_CHANNEL_DATArecipient channelData

Bedeutung der Felder:

byte SSH_MSG_CHANNEL_DATA :ein Byte, das den Typ des Paketes bestimmt

uint32 recipient channel : der Zielkanal

byte[] data : Nutzdaten

Das Schließen eines Kanals erfolgt mit dem Packet:

SSH_MSG_CHANNEL_EOFrecipient_channel

Bedeutung der Felder:

byte SSH_MSG_CHANNEL_DATA :ein Byte, das den Typ des Paketes bestimmt

uint32 recipient channel : der Zielkanal

Sessions

Eine Session ist die Ausführung eines entferntes Programms. Dabei kann es sich um eineShell, ein Anwendungsprogramm oder um ein Systemprogramm handeln.Eine Session wird mit folgendem Packet eröffnet:

SSH_MSG_CHANNEL_OPEN"session"sender channelinitial window sizemaximum packet size

Eine Session kann durch einen "session chanel open request" vom Client beim Serverangefordert werden.Clients sollten aus Sicherheitsgründen session chanel open requests ablehnen.

Pseudo Terminal anfordern

Eine Pseudo Terminal wird mit folgendem Packet vom Server angefordert.Dieses wird für interaktive Shellsitzungen benötigt

SSH_MSG_CHANNEL_REQUESTrecipient_channel"pty−req"want_replyTERM environment variable value (e.g., vt100)terminal width, characters (e.g., 80)terminal height, rows (e.g., 24)terminal width, pixels (e.g., 480)terminal height, pixels (e.g., 640)encoded terminal modes

Daraufhin erstellt der Server einen Kanal:

SSH_MSG_CHANNEL_OPEN"pty"sender channelinitial window sizemaximum packet size

Sichere X11 Verbindungen

Eine sichere X11 Verbindung wird mit folgendem Packet vom Server angefordert:

SSH_MSG_CHANNEL_REQUESTrecipient channel"x11−req"want replysingle connectionx11 authentication protocolx11 authentication cookiex11 screen number

Daraufhin kann der Server mit folgendem Packet die sichere X11 Verbindung herstellen:

SSH_MSG_CHANNEL_OPEN"x11"sender channelinitial window sizemaximum packet sizeoriginator address (e.g. "192.168.7.38")originator port

Starten von Programmen oder einer Shell auf dem Server

Es muss schon eine Session existieren. Dann kann der Client mit dem folgenden Packet einInteraktive Shell starten.

SSH_MSG_CHANNEL_REQUESTrecipient channel"shell"want reply

Der Client kann auch andere Programme starten, falls er auf der Server die entsprechendenRechte hat. Dies erfolgt durch Senden des Paketes:

SSH_MSG_CHANNEL_REQUESTrecipient channel"exec"want replyCommand

TCP/IP Port Forewarding

Port Forewarding bedeutet, das Nachrichten die normalerweise über eine unsichereVerbindung zu einem bestimmten Port des Servers gesendet werden, stattdessen zuerst aneinen lokalen Port gesendet werden. Der SSH Client lauscht auf diesem lokalen Port und fallsdort Daten eintreffen sendet er sie über einen sicheren Kanal zum SSH− Server auf derGegenseite weiter, dieser übergibt die Daten dann an den eigentlichen Zielport.Mit dieser Methode kann zum Beispiel die Übergabe von Benutzername und Passwort beimAbfragen von Mails gesichert werden, allerdings werden die Daten vom Server zum Clientunverschlüsselt übertragen.

Normalfall:

Login, Passwort pop client pop server

Client Server

Abgesicher t:

sicherer Kanal

SSH Client SSH Server

Login , Passwort

pop client pop server

Client Server

Port Forewarding wird mit folgendem Paket vom Server angefordert:

SSH_MSG_GLOBAL_REQUEST"tcpip−forward"want replyaddress to bind (e.g. "0.0.0.0")port number to bind

Dieser Dienst wird in der Regel nur vom Server zur Verfügung gestellt. Erhält ein Clientdiesen Request sollte er ihn ablehnen.

Nachdem ein Server diesen Request erhalten hat kann er mit folgendem Packet das portforewarding aktivieren.

SSH_MSG_CHANNEL_OPEN"forwarded−tcpip"sender channelinitial window sizemaximum packet sizeaddress that was connectedport that was connectedoriginator IP address

Sicherheit von SSH2

Sicherheit gegen aktive Angriffe

SSH2 kann durch sogenannte "man−in−the−middle" Attacken angegriffen werden.

Normalfall:

public key

Client Server

Angr iff:

Client Server

public key des Angreifers

Angreifer

Dies wird dadurch möglich, das es dem Client erlaubt werden kann den public key desServers herunterzuladen, wenn sich der Client zum ersten Mal mit dem Server verbindet.

Dies kann von einem Angreifer ausgenutzt werden, indem er bei der erstenVerbindungsaufnahme des Clients mit dem Server vorgibt selbst der Server zu sein, etwadurch DNS− oder IP Spoofing. Der Client würde in diesem Fall den public key desAngreifers runterladen. Der Client geht nun davon aus das am anderen Ende der gewünschteKommunikationspartner ist und sendet diesem geheime Informationen.

Vor diesem Angriff kann sich der Client schützen indem

das Runterladen des public keys beim Servers deaktiviert wird, in diesem Fall muss derpublic key anders verteilt werden, was die Benutzbarkeit von SSH erschweren würde.

Der Client hat die Möglichkeit die Echtheit des runtergeladenen public keys etwa durch einenFingerprint zu überprüfen, dieser ist relativ kurz und kann übers Telefon oder überVisitenkarten weitergegeben werden.

Der Server kann seinen public key durch eine dritte Stelle (CA) beglaubigen lassen.Verfügt der Client dann über den public key dieser Stelle kann er diese Beglaubigung prüfen

Sicherheit gegen passive Angriffe

SSH2 ist gegen passive Angriffe, das bedeutet das Abhören der Kommunikation von zweiParteien, ohne direkte in diese einzugreifen sicher, wenn man davon ausgeht das dieverwendeten kryptographischen Verfahren sicher sind.

Weitere Sicherheitsrisiken

Erlangt ein Angreifer root Rechte auf dem Server kann die Sicherheit nicht mehrgewährleistet werden, da er dann auch Zugriff auf den private key des Servers hat.Ein weiteres Risiko ist eine schwache Passphrase, mit der der private key auf dem Rechnerdes Clients geschützt wird. Kann ein Angreifer diese Passphrase erraten und hat Zugriff aufdie Datei in welcher der private key des Benutzers liegt , dann kann er sich beim Server alsBenutzer authentisieren.

Quellen

http://www.ietf.org/html.charters/secsh−charter.html Seite der IETF mit Definition des SSH2 Protokolls

http://www.gfnet.de/security/ssh.htmlEin Übersicht über SSH

http://kepler.offis.uni−oldenburg.de/lehre/Seminar/SemSichWS99/10/index.htmlSeminarbeitrag vom letzten Jahr

http://www.ssh.org/download.htmlKommerzielle SSH2 Version von SSH Communications Security

www.openssh.com Das Open SSH Projekt bietet eine freie Implementierung von SSH2.

Andrew s. Tannenbaum Computernetzwerke, 3. AuflageErläuterung des Diffie−Hellman Verfahren auf Seite 640 bis 642