Inhaltsverzeichnis:
 

1. Grundprinzipien der Kryptographie

1.1 symmetrische Verschlüsselung

1.2 asymmetrische Verschlüsselung

2. SHTTP das „ Secure Hypertext Transport Protokoll“

2.1 Einleitung HTTP „ Hypertext Transport Protokoll “

2.2 Geschichte SHTTP:

2.3 SHTTP Sicherheitsmechanismen

2.3.1 digitale Unterschrift:

2.3.2 digitale Zertifikate

2.3.3 Message Authentification Codes MAC

2.4 Erweiterungen von SHTTP

2.5 Fazit SHTTP

3. SSL  - Secure Sockets Layer

3.1 Einleitung SSL

3.2 Eingesetzte Techniken

3.2.1 Zertifizierung

3.3 Arbeitsweise

3.4 Aufbau

3.4.1 Das Handshake - Protokoll

3.4.2 Ablauf des Handshake - Protokolls
        Phase 1 - Verbindungsanfrage
        Phase 2 - Reaktion des Servers
        Phase 3 - Bestätigung des Client
        Phase 4 - Handshake Abschluß

4. SSH - Die Secure Shell

        4.1 Was ist SSH

        4.2 Was kann SSH

        4.3 Interessante Eigenschaften von SSH

        4.4 Ablauf des Login-Prozesses

        4.5 Wovor schützt SSH

        4.6 Wovor schützt SSH nicht

5. Quellennachweis

    5.1 Quellen im Internet

    5.2 Andere Quellen

1 Grundprinzipien der Kryptographie:

1.1 symmetrische Verschlüsselung:

Beispiel DES: Data Encryption Standard

Beim DES handelt es sich um ein symmetrisches Blockverfahren, daß 1981 durch ANSI als Standard definiert wurde.

Ablauf:

Anfangs wird der Text in 64 Bit Blöcke aufgeteilt. Der Schlüssel selbst hat ebenfalls 64 Bit, oder besser gesagt 56 Bit da jedes achte Bit der Paritätsprüfung dient. Der DES benutzt nun die Textblöcke und den Schlüßelblock zur Verschlüsselung, indem er diese in insgesamt 16 Runden verschlüsselt. Dabei sieht eine Verschlüsselungsrunde folgendermaßen aus:
Zuerst werden die 56 k des Schlüßelblocks geteilt, und durch die Kompressions-Permutation auf 48 Bit reduziert. Anschließend wird ein 64 k Textblock ebenfalls geteilt und eine Hälfte ( die Rechte) durch die Expansion-Permutation auf ebenfalls 48 Bit gebracht. Die eine 48 Bit Hälfte des Textblocks und der 48 Bit Block des Schlüssels werden nun „exklusiv oder“ miteinander verknüpft, und durch die S-Box Substitution auf 32 Bit reduziert. Auf dieses Ergebnis wird nun die P-Box Substitution angewandt. Diese verändert die Position der Bits anhand einer Tabelle. Nach der P-Box Substitution werden die 32 Bits dann noch exklusiv oder mit der noch unveränderten 32 Bit Hälfte des Textblocks ( die linke Hälfte) verknüpft. In der nächsten Runden werden dann einfach immer die Hälften getauscht, dabei werden die Hälften des Schlüssels pro Runde noch um ein oder zwei Bits geshiftet. Nach insgesamt 16 Runden hat der DES dann den Text verschlüsselt.
 
 

Bewertung DES:

Der Des „Data Encryption Standard“ ist heute jedoch schon ohne großen Aufwand leicht zu knacken, und daher nicht mehr sicher. Es gibt auch Nachfolger des DES wie z.B der Triple-DES, oder der         2- Schlüssel-EDE-Triple-DES die etwas sicherer sind.

Probleme der symmetrischen Verschlüsselung:

Bei der symmetrischen Verschlüsselung muss natürlich darauf geachtet werden, daß die Verteilung der Schlüssel auf einem sicheren Weg geschieht, und die Schlüssel regelmaässig ausgetauscht werden. Außerdem ist die Verwaltung der Schlüßel mit zunehmender Anzahl der Partner aufwendig.
 

1.2 asymmetrische Verschlüsselung

Damit dieses System auch funktioniert, müssen einige Richtlinien einghalten werden:
 

• Alle mit dem öffentlichen Schlüssel verschlüsselten Nachrichten müssen mit dem privaten Schlüssel wieder entschlüsselt werden können. Es darf nicht möglich sein, mit demselben Schlüssel zu ver- und entschlüsseln.
• Alle weltweit existierenden Schlüsselpaare (S, P) müssen verschieden sein.
• Die Ableitung von S aus P und umgekehrt muss ebenso schwer sein, wie eine Nachricht ohne Kenntnis des Schlüssels zu entschlüsseln.
• S und P müssen bei ihrer Erstellung leicht berechenbar sein.

Bei der asymmetrischen Verschlüsselung kann, je nach Verwendungszweck, mal mit dem öffentlichen und mal mit dem privaten Schlüssel verschlüsselt werden.

1.2.1 Signatur

1.2.2 Verschlüsselung

1.2.3 Beispiel RSA: Abkürzung aus den Entwicklernamen Rivest, Shamir, Adleman

1.2.4 Ablauf

Trotz dieses relativ aufwendigen Verfahrens schafft der RSA Ver- und Entschlüsselung in linearer Zeit.
 
 

2 SHTTP das „ Secure Hypertext Transport Protokoll“

2.1 Einleitung HTTP „ Hypertext Transport Protokoll “

Das Hypertext Transport Protokoll legt die Regeln für den Transport für Hypertexte fest. Die erste Version kam 1990, wobei  es sich damals um die Version V.0.9 handelte. In der Version V.1.0 wurden dann erstmals noch Metainformationen mit übertragen, die dem Browser Informationen zu den kommenden Daten lieferten. So konnte dem Browser z.B. schon im Voraus gesagt werden das nun ein Bild kommt, und die Verarbeitung etwas optimiert werden. Im Allgemeinen ist das Hypertext Transport Protokoll für den Datenverkehr im WWW zuständig, da dort die Anfragen und Antworten im HTTP Format vorliegen.

HTTP und SHTTP sind Protokolle der Anmwendungsschicht:

2.2 Geschichte SHTTP:

Um den Datenverkehr im WWW sicherer zu machen, hat sich die Firma EIT 1994 vorgenommen das bestehende HTTP weiter zu entwickeln, und nannte das neue Protokoll dann SHTTP, sprich „ Secure Hypertext Transport Protokoll“. Noch im selben Jahr gründete die EIT dann mit der Firma RSA Data Security die Firma Terisa Systems. Im folgenden Jahr stießen dann noch die Firmen America Online, IBM, Netscape und CompuServe dazu. Das Ziel der Firma ist es das WWW also die Datenübertragung im Internet sicherer zu gestalten.

Sucht man heute Informationen zu SHTTP stößt man öfters auch auf HTTPS. Dabei handelt es sich hier jedoch nicht um das gleiche Protokoll. Während das eher veraltete SHHTP nur eine Weiterentwicklung des alten HTTP ist, handelt es sich beim HTTPS um das aktuellere HTTP mit SSL, also einer neuen Technologie, mit Hilfe des „Secure Socket Layers“ das HTTP sicherer zu machen.
 
 

2.3 SHTTP Sicherheitsmechanismen

SHTTP legt fest, wie die Parteien über Sicherheitsmechansismen verhandeln. Dabei kann SHTTP 3 Sicherheitsmechansimen benutzen.

• die digitale Unterschrift
• das digitiale Zertifikat
• Message Authentification Codes MAC

2.3.1 die digitale Unterschrift

• die Unterschrift gemacht wurde
• die Unterschrift nicht wiederverwendet werden kann,
• das Unterschriebene Dokument nicht unbemerkt verändert werden kann.
• Und die Unterschrift nicht abgestritten werden kann.

2.3.2 digitale Zertifikate

Der Aufbau eines digitalem Zertifikats ist im X.509 Standard festgelegt, und enthält den Namen des Besitzers, seinen öffentlichen Schlüssel und den Namen der  Zertifizierungsstelle ( CA Certification Authority). Um ein digitales Zertifikat zu erhalten , muss man dies bei einer Zertifizierungsstelle beantragen. Diese prüft dann die Identität des Antragsstellers und stellt schließlich ein Zertifikat aus. Dieses signiert die Zertifizierungsstelle dann mit einer digitalen Unterschrift, damit man sich auch sicher sein kann, dass das Zertifikat auch von der Zertifizierungsstelle kommt. Hierfür benötigt man allerdings den öffentlichen Schlüssel der Zertifizierungsstelle, wobei man hier natürlich wieder auf das Problem stößt, dass man sich hier nur sicher sein kann, wen man den Schlüssel mit einem digitalen Zertifikat erhält.Um hier den Teufelskreis zu Umgehen erhält man den öffentlichen Schlüssel durch ein Zertifikat einer anderen Zertifizierungsstelle. Die Zertifizierungsstellen selbst sind Hierarchisch organisiert. Außerdem sind die Zertifikate nur eine Zeit lang gültig und müssen in bestimmten Zeitabständen erneuert werden.
 

2.3.3 MAC Message Authentification Codes

2.4 Erweiterungen von SHHTP zu HTTP

Erweiterungen:

• ein neuer Protokollbezeichner im Anchor wurde definiert, denn jedes SHHTP Dokument muss mit der URL „shhtp:\\ anstelle von „htttp:\\“ beginnen.

• Eine andere Erweiterung sind die neuen HTML-Tags CERT und CRYPTOPTS: Das neue CERT Tag dient dazu, um digitale Zertifikate in das HTML Dokument zu platzieren, mit welchem der Empfänger sofort den Schlüssel des Partners erhält, und seine Identität überprüfen kann.

Das CRYPTOPS-Tag enthält die erforderlichen Verschlüsselungsparameter für Hyperlinks im Dokument. Hier kann also z.B. definiert werden, dass eine Anforderung an einen bestimmten Server nur verschlüsselt erfolgen darf.

2.5 Fazit SHTTP:

3. SSL - Secure Sockets Layer

3.1 Einleitung

Das Design des SSL verfolgt folgende Ziele :

- kryptographische Sicherheit

Vertraulichkeit : Ein Lauscher kann aus den abgehörten Daten nicht den Inhalt ermitteln.

Integrität : Die übertragenen Daten können nicht verfälscht werden, d.h. verfälschte Daten werden erkannt.

Authentizität : Die Daten stammen tatsächlich vom Sender, d.h. eventuelle zusätzliche Datenpakete werden erkannt.

- Interoperabilität : Es handelt sich um ein offenes Protokoll, d.h. Regeln der Kommunikation sind genau spezifiziert und bekannt, daher können unterschiedliche Implementationen zusammenarbeiten.

- Erweiterbarkeit : SSL ermöglicht das Einbinden von neuen Verfahren zur Kompression und Verschlüsselung, ohne daß das Protokoll geändert werden muß.

- Effizienz : SSL ermöglicht das Caching von Vebindungen, d.h. einmal erfolgreich aufgebaute Verbindungen können später mit geringem Aufwand wieder benutzt werden.
 

3.2 Eingesetzte Techniken

- Symmetrische Verschlüsselung
- Asymmetrische Verschlüsselung
- sichere Hashfunktionen

SSL wird "hybrid" genannt, weil es eine Kombination einer symmetrischen und einer asymmetrischen Verschlüsselung ist. Unterstützt werden dabei die meisten bekannten Vertreter der Verfahren ( DES, RC4 ; RSA, DSS ; SHA, MD5 ). Durch die schon angesprochene Erweiterbarkeit können aber weitere Verfahren eingebunden werden.

Zusätzlich benutzt SSL noch das Konzept der Zertifizierung. Dies ist notwendig, um die Echtheit der Zuordnung von Server ( bzw. Client ) zum public key zu garantieren.
 

3.2.1  Zertifizierung

3.3 Arbeitsweise

3.4 Aufbau

- Steuerprotokoll : Das Steuerprotokoll ist verantwortlich für die Verbindungsaushandlung. Die während der Aushandlung festgelegten Parameter werden in den Status geschrieben. Das Steuerprotokoll ist austauschbar. Zur Zeit gibt es jedoch nur einen Vorschlag für ein solches Protokoll - das Handshake-Protokoll. Dies wird später noch genauer betrachtet.

- Record Protokoll : Das Record Protokoll ist für das Sichern und Versenden sowie für das Empfangen und Überprüfen von Daten zuständig.
Dabei werden beim Versenden die Daten zuerst fragmentiert und komprimiert. Danach erhält jeder Block eine Nummer und es wird mittels eines Hash-Verfahrens eine Prüfsumme gebildet. Anschließend werden die Daten mit einem symmetrischen Verschlüsselungsverfahren verschlüsselt.
Das Empfangen läuft genau umgekehrt ab : Die Daten werden entschlüsselt und mit Hilfe der Prüfsummewird getestet, ob die Daten unverfälscht sind. Mit Hilfe der Nummer wird überprüft, ob das Paket schon mal gesendet wurde und an welche Stelle es gehört. Danach werden die Daten dekomprimiert und wieder zusammengesetzt.
Fragmentierung und Komprimierung finden aus Effizienzgründen statt. Mit Hilfe der Numerierung kann man erkennen, ob Pakete fehlen oder dupliziert wurden. Die Prüfsumme dient zur Gewährleistung der Authentizität und die Verschlüsselung zur Gewährleistung der Vertraulichkeit.
 

3.4.1 Das Handshake - Protokoll

Das Steuerprotokoll hat folgende grundlegende Aufgaben :

- Aushandeln der Verbindungsmodalitäten
Da SSL verschiedene Kompressions- und Verschlüsselungsverfahren unterstützt, müssen diese zwischen Client und Server vor dem eigentlichen Datenaustausch vereinbart werden.

- Austausch von Zertifikaten
Um dem Client die Möglichkeit zu geben, die Echtheit des Servers zu überprüfen, verschickt der Server sein Zertifikat. Dieses Zertifikat bestätigt die Zuordnung des Servers zu seinem public key. Umgekehrt kann auch der Server die Authentifizierung des Client verlangen.

- Schlüsselaustausch
Um für die spätere Datenübertragung aus Effizienzgründen ein symmetrisches Verschlüsselungsverfahren benutzen zu können, muß ein Schlüsselaustausch zwischen Client und Server erfolgen. Dieser Austausch muß natürlich asymmetrisch verschlüsselt erfolgen.

- Überprüfung der Verbindung
Nach Aushandlung der Verbindungsmodalitäten wird überprüft, ob die Kommunikation zwischen Client und Server funktioniert und erst danch werden die eigentlichen Anwendungsdaten vom Record Protokoll übertragen.
 

3.4.2 Ablauf des Handshake - Protokolls

Phase 1 - Verbindungsanfrage

CLIENT HELLO

Dient dem Verbindungsaufbau und beinhaltet folgende Informationen

- unterstützte Protokollversion des Clients
- SitzungsID : Möchte der Client eine in der Vergangenheit ausgehandelte Verbindungmit diesem Server wieder benutzen, dann wird die alte SitzungsID angegeben, ansonsten ist der Wert der SitzungsID Null.
- Präferenzliste : Diese Liste enthält in der bevorzugten Reihenfolge die unterstützten Kompressions- und Verschlüsselungsverfahren des Clients.

Dieses Paket wird unverschlüsselt gesendet.
Danach wartet der Client auf die Reaktion des Servers.
 

Phase 2 - Reaktion des Servers

Der Server empfängt das CLIENT HELLO. Ist die SitzungsID nicht Null, so prüft der Server, ob er diese SitzungsID kennt und entscheidet, ob die Verbindung ohne neue Aushandlung wieder aufgenommen werden soll. Ist dies der Fall, so schickt er ein Server Hello mit der gleichen SitzungsID zurück und das Handshake-Protokoll ist beendet.

Soll eine neue Verbindung aufgebaut werden, so untersucht der Server das Client Hello und wählt die Verbindungsparameter aus.

SERVER HELLO

Dieses Paket dient zur Mitteilung der Verbindungsparameter

- Protokollversion
Die niedrigere der unterstützten Protokollversionen von Client und Server wird benutzt.

- Verschlüsselungs- / Kompressionsmethoden
Je nach Unterstützung und Präferenz von Client und Server werden diese ausgewählt.
(eine Kompression, ein symmetrisches Verfahren, ein asymmetrisches und ein Hashverfahren)

CERTIFICATE

Wünscht der Server eine Zertifizierung des Clients, so kann er dessen Zertifikat anfordern.

CERTIFICATE REQUEST

Zum Abschluß schickt der Server ein

SERVER HELLO DONE
Ende der Hello-Phase , nicht verschlüsselt.

Der Server wartet nun auf die Antwort des Client.
 

Phase 3 - Bestätigung des Client

Der Client empfängt das SERVER HELLO. An der SitzungsID erkennt er, ob eine alte Verbindung wieder aufgenommen wird, oder ob neu verhandelt werden muß. Wird eine alte Verbindung wieder aufgenommen, so ist der Handshake beendet. Andernfalls wartet der Client auf das Zertifikat des Servers, überprüft es und kennt nun den public key des Servers. Der Client generiert nun einen Master Key und verschlüsselt ihn mit dem public key des Servers und schickt ihn an den Server.

CLIENT KEY EXCHANGE
Dient zur Übermittlung des Master Key und ist mit dem public key des Servers verschlüsselt.

Anschließend werden aus dem Master Key mit in Abhängigkeit der ausgewählten Verschlüsselungsverfahren neue Schlüssel erzeugt. Dazu werden für jedes Verfahren spezifische Algorithmen verwendet. Diese sind in der SSL Spezifikation enthalten.
Der Client kennt nun alle Verbindungsparameter zur sicheren Übertragung und ist bereit zum Verschlüsseln.

CLIENT CIPHER SPEC
Mitteilung, daß ab jetzt verschlüsselt gesendet wird. Die Meldung selber ist aber noch unverschlüsselt.

FINISH
Mitteilung über Ende des Handshakes, verschlüsselt.
 

Phase 4 - Handshake Abschluß

Der Server empfängt CLIENT KEY EXCHANGE und entschlüsselt das Paket mit seinem private key. Aus dem nun vorliegenden Master Key kann der Server nun die selben Schlüssel wie der Client generieren. Nun hat auch der Server alle nötigen Informationen.

CHANGE CIPHER SPEC
s.o.

FINISH
s.o.

Sowohl Client und Server warten auf FINISH. Ist diese korrekt, d.h. richtig verschlüsselt, so kann die Datenübertragung beginnen.

Der Datenaustausch erfolgt nun wie beschrieben über das Record Protokoll.

Schließen der Verbindung
Ist die Datenübertragung beendet und soll die Verbindung geschlossen werden, so wird dies angekündigt und von der Gegenseite mit der selben Meldung bestätigt.

CLOSE NOTIFY

Nur bei ordnungsgemäßem Schliessen der Verbindung wird die Verbindung gespeichert und kann unter Umständen später wieder aufgenommen werden.
 
 

4. SSH - Die Secure Shell

4.1 Was ist SSH

Hier jedoch soll nicht SSH in allen kleinen Einzelheiten erläutert werden, sondern dieses Dokument soll übergreifend Aufschluss darüber geben, was SSH ist, was es kann und wozu es gut ist. Womit man auch schon voll im Thema steckt ...
 

4.2 Was kann SSH

- auf einem entferneten Rechner einzuloggen.
- interaktive und andere Kommandos auf dem entfernten Rechner auszuführen.
- Dateitransfer von und zu einem entfernten Rechner zu veranlassen.

Im Gegensatz zu den älteren Tools aber kommuniziert SSH  auf der Basis von Verschlüsselungsalgorithmen, die es einem potentiellen Angreifer unmöglich oder zumindest sehr schwer machen sollen, die Verbindung abzuhören.
Zu den bei SSH verwendeten Verschlüsselungen zählen unter anderen RSA, DES, Triple-DES, TSS oder Blowfish, von denen einige bereits weiter oben genannt und erklärt wurden.
 

4.3 Interessante Eigenschaften von SSH

- Das SSH-Protokoll tauscht unter Verwendung von RSA für jede einzelne Sitzung zufällige Session Keys aus.
  Dieser Session Key bleibt ausschliesslich im RAM-Speicher der beteiligten Rechner. Er wird niemals auf der Festplatte abgelegt.

- SSH arbeitet bei der Authentifizierung mit mehreren Schlüsseln.

  - Host Authentication Key.
  - User Authentication Key.
  - Session Key.

- Die Authentifizierung basiert auf dem asymmetrischen RSA-Algorithmus, was bereits einige Sicherheitslücken schliesst.

- Die Secure Shell ist sowohl systemweit als auch benutzerdefiniert konfigurierbar. Dies erlaubt dem Administrator recht  genaue
  Voreinstellungen und dem User, in einem vom Administrator festgelegten Rahmen auch eigene Konfigurationsmöglichkeiten.

- SSH unterstützt optional Kompressionsverfahren.

- Es bestehen verschiedene Verfahren zur Client-Server-Authentifizierung:
  Die drei wichtigsten davon sind:

  - RHOSTS-Authentifizierung

  - RHOSTS-RSA-Authentifizierung

  - Passwort-Authentifizierung

- Die Verschlüsselung erfolgt für den Benutzer vollkommen transparent.

- Die Kommunikation ist bereits vor der Passwortübertragung verschlüsselt.
  Das Ganze würde ja sonst auch wenig Sinn machen.

- SSH unterstützt Port Forwarding.
  Bidirektionale Umlenkung der TCP/IP-Ports auf eine zuvor geöffnete, verschlüsselte Verbindung.

- SSH eignet sich auch für sichere X11-Sessions (Display-Forwarding inter UNIX / Linux).
 

4.4 Ablauf des Login-Prozesses

Host Authentication

- Beide Kommunikationspartner tauschen die jeweils verwendete Protokollversion aus. Ist diese inkompatibel, wird die Verbindung
  abgebrochen.

- Beide Partner schalten auf  ein paketorientiertes Protokoll um. Ein Paket dieses Protokolls besteht aus:

  - Paketlänge (max. 262144 Byte).
  - Padding (1 bis 8 Byte zufällig erzeugte Daten zur Erschwerung von Abhörversuchen).
  - Pakettyp.
  - Nutzdaten.
  - CRC-Prüfsumme (vor der Verschlüsselung berechnet).

- Der Server sendet seine beiden öffentlichen RSA-Schlüssel und eine Liste der unterstützten Chiffres an den Client.

- Der Client verifiziert die Schlüssel aus seiner lokalen "Datenbank". Ist der Serverschlüssel unbekannt, kann der Client, je nach Konfiguration,
  diesen Schlüssel "lernen".

- Wurde der Serverschlüssel akzeptiert, so generiert der Client einen zufälligen Session Key, chiffriert diesen mittels der erhaltenen
  RSA-Serverkeys und sendet das Resultat samt der Angabe über das gewählte Verschlüsselungsverfahren an den Server zurück.

User Authentication

- Der Client teilt dem Server mit, dass sich User XY einloggen möchte.
- Server sucht im entsprechenden HOME-Verzeichnis nach dem Public Key für XY@HostZ und verschlüsselt damit eine sog. Challenge.
- Der Cliententschlüsselt diese Challenge mit dem Private Key des Users und authentifiziert sich damit.
- Ist diese Abfolge erfolgreich abgeschlossen, so startet der Server eine Usershell, mit der nun gearbeitet werden kann.
 

Eine Beipielsitzung

SSH Version 1.2.26-afs_pl1 [i686-unknown-linux], protocol version 1.5.
Standard version.  Does not use RSAREF.
kirke: Reading configuration data /home/hot/.ssh/config
kirke: Reading configuration data /etc/ssh_config
kirke: ssh_connect: getuid 324 geteuid 0 anon 1
kirke: Connecting to sisyphus.hrz [134.109.132.18] port 22.
kirke: Connection established.
kirke: Remote protocol version 1.5, remote software version 1.2.26-afs_pl1
kirke: Waiting for server public key.
kirke: Received server public key (768 bits) and host key (1024 bits).
kirke: Host 'sisyphus.hrz' is known and matches the host key.
kirke: Initializing random; seed file /home/hot/.ssh/random_seed
kirke: Encryption type: 3des
kirke: Sent encrypted session key.
kirke: Installing crc compensation attack detector.
kirke: Received encrypted confirmation.
kirke: ClearToken info:
kirke: BeginTimestamp: 906443693 (Tue Sep 22 07:54:53 1998)
kirke: EndTimestamp: 906535274 (Wed Sep 23 09:21:14 1998)
kirke: calculated lifetime: 91581 (25.4392 hours)
kirke: credentials: lifetime=141, issue_date=906443693
kirke: credentials: endTime calculated by krb_life_to_time(906443693,141)=906535274
kirke: Remote: extracted endTime of credentials=906535274
kirke: Remote: lifetime of credentials calculated by krb_time_to_life(906443693,906535274)=141
kirke: Remote: AFS token accepted (afs@tu-chemnitz.de, AFS ID 4324@tu-chemnitz.de)
kirke: No agent.
kirke: Trying RSA authentication with key 'hot@kirke'
kirke: Received RSA challenge from server.
Enter passphrase for RSA key 'hot@kirke':
kirke: Sending response to host key RSA challenge.
kirke: Remote: RSA authentication accepted.
kirke: RSA authentication accepted by server.
kirke: Requesting pty.
kirke: Requesting X11 forwarding with authentication spoofing.
kirke: Requesting shell.
kirke: Entering interactive session.
Last login: Tue Sep 22 11:35:00 1998 from 134.109.192.39
Sun Microsystems Inc.   SunOS 5.5.1     Generic Jan 1997
================================================================
Terminal type ?(xterm):
hot@sisyphus 1 > tokens

Tokens held by the Cache Manager:

User's (AFS ID 4324) tokens for afs@tu-chemnitz.de [Expires Sep 23 09:21]
   --End of list--
hot@sisyphus 2 >

hot@sisyphus 2 >exit
logout
Connection to sisyphus.hrz closed.
kirke: Transferred: stdin 13, stdout 546, stderr 36 bytes in 8.2 seconds
kirke: Bytes per second: stdin 1.6, stdout 66.5, stderr 4.4
kirke: Exit status 0
 

4.5 Wovor schützt SSH

- IP-Spoofing:
  Ein entfernter Rechner meldet sich mit einer falschen IP, um den Eindruck zu erwecken, aus einem vertrauenswürdigen Bereich zu  stammen.

- DNS-Spoofing:
  Hierbei verfäscht ein Angreifer die Antwortpakete eines Nameservers.

- Sniffing:
  Mitschneiden von Verbindungsdaten und natürlich vor allem von Passwörtern.

- Hijacking:
  Dies bezeichnet die Manipulation eines Vermittlungsknotens innerhalb der Punkt-zu-Punkt-Verbindung.

- X-Attacks:
  Mithören und verfälschen der Authentifizierungsdaten einer X-Window-Session.

Gelingt doch jemandem ein Angriff, so ist es für ihn lediglich möglich, eine bestehende Verbindung zu unterbrechen, nicht aber, sie zu übernehmen und zu manipulieren.
SSH folgt hierbei streng der Devise, "vertraue niemals dem Netz", was soweit auch recht gut funktioniert !
Aber der Netzwerkanschluss ist eben nicht alles in und an einem Rechenrsystem ...

4.6 Wovor schützt SSH nicht

- SSH kann niemals den Rechner als solchen schützen. Gelingt es jemandem, auf irgendeinem Netzknoten unerlaubt Administratorrechte zu
  erlangen, so arbeitet SSH als Kommunikatonsmittel zwar unverändert, sein Sinn aber ist unterwandert und sein Dienst wertlos.

- Gelingt es jemandem, an, z. B. über NFS eingebundene, offene HOME-Verzeichnisse zu gelangen, so ist es auch leicht möglich, an die doch
  eigentlich vertraulichen Konfigurationsdaten und Schlüssel heranzukommen, diese zu manipulieren oder einfach zu löschen.
 
 

5. Quellennachweis

5.1 Quellen im Internet

5.2 Andere Quellen