8.4.4. SSH - Secure Shell

Neben Telnet und FTP haben im UNIX-Umfeld die sog. r-Utilities (das r steht für remote) eine sehr weite Verbreitung gefunden. Sie gestatten u.a. das mit Telnet vergleichbare interaktive Arbeiten auf entfernten Maschinen (Kommando rlogin), die entfernte Kommandoausführung (Kommando rsh) sowie die Übertragung von Dateien über das Netz (Kommando rcp).

Die Authentifizierung der Klienten basiert entweder auf im Klartext übertragenen Nutzer-Paßwörtern oder auf Paaren von Nutzernamen und IP-Adressen, die in einer speziellen Datenbasis registriert sein müssen. So kann man z.B. festlegen, daß sich der Nutzer abc ohne Angabe eines Paßworts auf dem Server anmelden kann, wenn die Verbindung vom Rechner host1.hrz.tu-chemnitz.de aus aufgebaut wurde. Der Server vertraut dabei darauf, daß auf der Klienten-Seite bereits eine korrekte Authentifizierung (typischerweise anhand des Paßworts) durchgeführt wurde.

Diese Vorgehensweise ist zwar sehr bequem, allerdings (genau wie die offene Übertragung von Paßwörtern) potentiell hochgradig unsicher. Um dieses Problem zu beseitigen, hat der finnische Informatiker Tatu Ylönen mit dem SSH (Secure Shell) Remote Login Protocol ein komplett neues kryptographisches Protokoll entworfen, das sich durch ein sehr hohes Sicherheitsniveau auszeichnet. Es gestattet eine zuverlässige gegenseitige Authentifizierung der Partner und garantiert die Integrität und Vertraulichkeit der zwischen ihnen ausgetauschten Daten.

Anders als z.B. bei SRA-Telnet oder -FTP wurde hier also nicht der Weg gewählt, ein bereits existierendes Protokoll im nachhinein um Sicherheitsfunktionen zu erweitern.

Im Juli 1995 gab Ylönen die Quelltexte der Version 1.0 der von ihm selbst in ANSI C geschriebenen und nur auf UNIX-Systemen lauffähigen Referenzimplementierung der Version 1.0 seines neuen Protokolls frei. Dieses Paket trägt den Namen Secure Shell (SSH) und ist für den nichtkommerziellen Gebrauch kostenlos nutzbar.

Die darin enthaltenen Klienten ssh und scp sind als vollständiger funktionaler Ersatz für rlogin, rsh und rcp gedacht, wobei es einige wenige, für die meisten Nutzer absolut irrelevante Situationen gibt, in denen ein Austausch von rsh gegen ssh nicht möglich ist.

Das Programm ssh gestattet es, sich auf einer entfernten Maschine anzumelden, diese interaktiv zu nutzen oder nichtinteraktiv Kommandos auf ihr auszuführen. scp dient dem Kopieren von Dateien zwischen verschiedenen Rechnern eines Netzes, wobei es ssh für den sicheren Datentransfer verwendet.

In den meisten Fällen kann die Secure Shell daher nicht nur die r-Utilities, sondern auch Telnet und teilweise sogar FTP ersetzen. Der Ersatz von Telnet und FTP ist bei SSH 2.x im Gegensatz zur Version 1.x erklärtes Ziel. SSH 2.x stellt mit dem Kommando sftp ein zusätzliches Werkzeug für den sicheren Dateitransfer zur Verfügung, das hinsichtlich Funktionalität und Bedienung sehr stark an den kommandozeilenorientierten FTP-Klienten von UNIX angelehnt ist und so speziell für die interaktive Arbeit einen höheren Komfort als scp bietet.

Ylönen gab folgende Entwurfsziele für die SSH an:

Die Secure Shell wurde sowohl bezüglich des Protokolls als auch der Implementierung von Anfang an kontinuierlich weiterentwickelt und verbessert, was nicht zuletzt den vielen kritischen Hinweisen des stetig gewachsenen Nutzerkreises zu verdanken ist. Im Umfeld der Netzwerk-Sicherheit stellt SSH eine der interessantesten Entwicklungen der letzten Zeit dar, die sehr schnell eine weite Verbreitung und viele Freunde gefunden hat.

Neben der kostenfreien Version existieren auch kommerzielle SSH-Produkte. Die Firma Data Fellows bietet u.a. unter der Bezeichnung F-Secure SSH Tunnel&Terminal [http://www.Europe.DataFellows.com/f-secure/fclintp.htm] kommerzielle SSH-Klienten für Windows (3.1x, NT, 95/98) und den Macintosh an.

Bei Implementierungen der Secure Shell ist zu beachten, welche Version des SSH-Protokolls unterstüzt wird. Von Bedeutung sind gegenwärtig vor allem die miteinander inkompatiblen Protokoll-Versionen 1.5 und 2.0. Letztere ist seit Ende 1996 Gegenstand der Arbeit der Secure Shell Working Group [http://www.ietf.org/html.charters/secsh-charter.html] der IETF, deren Aufgabe darin besteht, das SSH-Protokoll zu aktualisieren und international zu standardisieren. Die Protokoll-Spezifikation ist in Form von Internet-Drafts öffentlich verfügbar. Wir werden uns weiter unten mit verschiedenen Aspekten näher beschäftigen.

Im August 1998 stellte die von Tatu Ylönen gegründete Firma SSH Communications Security Ltd. [http://www.ssh.fi/] mit SSH 2.0.7 eine erste Implementierung des neuen SSH-Protokolls 2.0 öffentlich bereit. Zum Zeitpunkt der letzten Überarbeitung des vorliegenden Textes sind folgende SSH-Versionen aktuell:

SSH-Version Protokoll-Version
SSH 1.2.27 1.5
SSH 2.0.13 2.0

Die SSH 1.2.27 läuft auf fast allen UNIX-Systemen und ist weltweit im Einsatz. Des weiteren gibt es verschiedene Portierungen unterschiedlicher Versionen von SSH 1.2.x für Win32. Informationen dazu erhalten Sie z.B. auf der SSH-Seite des URZ der TU Chemnitz: http://www.tu-chemnitz.de/~hot/ssh/.

Eine formale Spezifikation des SSH-Protokolls 1.5 ist z.B. in der Datei RFC zu finden, die Bestandteil der nichtkommerziellen Distribution von SSH 1.2.27 ist, allerdings keinen RFC darstellt, wie der Name evtl. suggeriert. Die Version 1.5 des SSH-Protokolls ist schon relativ alt und mit verschiedenen konzeptionellen Mängeln behaftet. Ein Beispiel ist die Anfälligkeit gegen eine sog. Insertion Attack. Informationen dazu finden Sie beispielsweise unter http://www.tu-chemnitz.de/~hot/ssh/ssh.html#insattack. Gezielte Weiterentwicklungen von SSH 1.2.27 sind daher nicht mehr zu erwarten. Eine evtl. Pflege dieses Produkts wird sich mit hoher Wahrscheinlichkeit auf die Beseitung von kleineren oder größeren Fehlern bzw. Problemen beschränken.

Eine relativ umfangreiche und aktuelle Diskussion verschiedener Aspekte der in der heutigen nichtkommerziellen Praxis (noch) dominierenden SSH 1.2.x finden Sie auf der oben bereits erwähnten SSH-Seite des URZ der TU Chemnitz. Auf ihr werden u.a. die Eigenschaften der SSH, das zugrunde liegende kryptographische Protokoll sowie Installation und Nutzung der Software genauer vorgestellt. Des weiteren enthält sie eine Beispielsitzung sowie Verweise auf eine ganze Reihe weiterer Informationsquellen im Internet.

Allen Interessenten sei das Studium dieser Seite empfohlen, da wir uns nachfolgend hauptsächlich den Protokollen und weniger der Implementierung sowie deren Nutzung zuwenden wollen.


SSH 1.x

  1. Interessante Eigenschaften

    Die folgende Liste nennt einige interessante Eigenschaften von SSH 1.x:

  2. Prinzipieller Ablauf beim Login

    Das Login auf einem Server läuft gemäß SSH-Protokoll 1.x prinzipiell so ab:

  3. Gegenseitige Authentifizierung der Partner

    Der Server weist seine Authentizität implizit nach. Letztlich kann er nur bei Kenntnis der privaten Keys dH und dS den vom Klienten generierten und verschlüsselten Sitzungsschlüssel ermitteln. Gelingt ihm das nicht, endet die Kommunikation, da er dann die Pakete des Binärprotokolls weder entschlüsseln noch korrekt erzeugen kann.

    Unerläßliche Voraussetzung für die Sicherheit dieses Verfahrens ist, daß der Klient überprüfen kann und überprüft, ob der öffentliche Host-Key des Servers wirklich diesem zugeordnet ist. Ein beliebiges Schlüsselpaar kann jeder, auch ein potentieller Angreifer, ohne Probleme generieren und in den Authentifizierungsdialog einbringen.

    Die Zusammengehörigkeit von Server und öffentlichem Host-Key wird an Hand der Einträge in entsprechenden Administrationsdateien überprüft.

  4. Verfahren zur Authentifizierung des Klienten

    Die Secure Shell unterstützt in der Grundversion die vier nachfolgend genannten Verfahren zur Authentifizierung des Klienten, wobei die Nutzung der einzelnen Verfahren durch Kommandozeilen-Optionen bzw. Einträge in den Konfigurationsdateien gezielt zugelassen bzw. unterdrückt werden kann. Die in einer konkreten Konstellation verfügbaren Verfahren werden nacheinander bis zum ersten Erfolg oder bis zum definitiven Mißerfolg versucht:

    1. Rhosts-Authentifizierung

      Dieses Verfahren entspricht der von den r-Utilities her bekannten Authentifizierung auf der Basis von aus Nutzernamen und IP-Adressen der Klienten bestehenden Paaren.

      Warnung: Diese Methode ist absolut unsicher und wird daher sinnvollerweise vom Server in der Regel nicht unterstützt!!

    2. Rhosts-RSA-Authentifizierung

      Hierbei handelt es sich um eine Kombination der Rhosts-Authentifizierung (Verfahren 1) mit einer RSA-basierten Authentifizierung des Klienten-Rechners. Der Klient muß in einem Challenge-Response-Dialog nachweisen, daß er den ihm zugeordneten privaten Schlüssel kennt.

    3. reine RSA-Authentifizierung

      Sie stellt die flexibelste und potentiell sicherste Methode dar. Hierbei weist der Nutzer die Kenntnis seines privaten Schlüssels und damit seiner Identität über ein Challenge-Response-Verfahren nach.

      Jeder Nutzer kann eine beliebige Anzahl von RSA-Schlüsseln zu seiner eigenen Identifikation verwalten und verwenden. Zu deren bequemer Handhabung steht der SSH-Agent zur Verfügung.

    4. Paßwort-Authentifizierung

      Die Authentifizierung erfolgt durch Angabe eines Nutzerpaßworts, wobei dieses immer verschlüsselt übertragen wird.

      Im Standardfall handelt es sich dabei um das normale UNIX-Paßwort. Allerdings lassen sich auch andere Paßwörter nutzen, z.B. von AFS bzw. Kerberos oder von den SecurID-Karten der Firma Security Dynamics [http://www.securitydynamics.com]. Mitunter sind dafür spezielle Patches erforderlich.

    Je nach Installation können weitere Authentifizierungsverfahren zur Verfügung stehen. So enthalten z.B. die Quellen der SSH 1.2.27 eine optionale Unterstützung des zum TIS Internet Firewall Toolkit [http://www.tis.com/research/software/fwtk/] gehörenden Authentifizierungs-Servers sowie von Kerberos-Tickets. Standardmäßig wird Kerberos Version 5 verwendet. Mit entsprechenden Patches läßt sich aber auch die beispielsweise bei AFS eingesetzte Version 4 von Kerberos nutzen.


SSH 2.0

Bei SSH 2.x werden die einzelnen Aufgaben durch verschiedene Protokolle realisiert, deren Spezifikation jeweils in einem eigenen Dokument erfolgt. Am 22. Juni 1999 wurden folgende Drafts verabschiedet:
Anmerkung: Im folgenden Text sollen die Abkürzungen SSH-TLP, SSH-AP und SSH-CP in dieser Reihenfolge die drei o.g. Protokolle bezeichnen.

Zusätzlich zu diesen Dokumenten wurde durch die IETF-Arbeitsgruppe am 7. März 1999 der Draft Generic Message Exchange Authentication For SSH veröffentlicht, der eine allgemeine Authentifizierungsmethode beschreibt, die für interaktive Authentifizierungsvorgänge geeignet ist, bei der die Authentifizierungsinformationen in der Regel über die Tastatur eingegeben werden. Mit dieser Methode soll erreicht werden, daß der SSH-Klient nur wenig oder gar kein Wissen über den jeweils vom SSH-Server genutzten Authentifizierungsmechanismus benötigt.

Wir wenden uns zunächst der SSH-Architektur und anschließend den einzelnen Protokollen zu. Dabei beziehen wir uns immer auf die genannten Drafts.

  1. Architektur

    Das SSH-Protokoll besteht aus den folgenden drei Hauptkomponenten:

    Jeder Server-Rechner muß für jeden obligatorischen Public-Key-Algorithmus (momentan ist das nur der im DSS spezifizierte DSA) mindestens einen sog. Host-Key besitzen. Es handelt sich natürlich auch hierbei wieder um ein Schlüsselpaar, das aus einem privaten und einem öffentlichen Host-Key besteht. Eine Maschine benötigt mehrere solche Schlüsselpaare, wenn unterschiedliche asymmetrische Algorithmen genutzt werden sollen. Mehrere verschiedene Rechner können sich auch einen bestimmen Host-Key teilen.

    Der Host-Key eines Servers dient dem Klienten im Rahmen des Schlüsselaustauschs zur Feststellung der Authentizität des Servers. Der Klient muß daher den öffentlichen Host-Key des Servers a priori kennen.

    Hierbei lassen sich zwei unterschiedliche Vertrauensmodelle (trust models) nutzen:

    Das SSH-Protokoll bietet allerdings die Option, beim allerersten Aufbau einer SSH-Verbindung zu einem bestimmten Server auf die Überprüfung von dessen Host-Key zu verzichten, um so auch ohne vorherigen Austausch von Host-Keys bzw. deren Zertifizierung eine Kommunikation zu ermöglichen.

    Eine derart aufgebaute Verbindung bietet Schutz gegen passive, nicht aber gegen aktive man-in-the-middle attacks und stellt somit ein potentielles Sicherheitsproblem dar. Implementierungen sind deshalb angehalten, solche Verbindungen im Standardfall nicht zu erlauben und generell für eine bestmögliche Verifizierung von Host-Keys zu sorgen, z.B. dadurch, daß sie einen ungeprüft akzeptierten Schlüssel in einer lokalen Datenbasis aufbewahren, um ihn bei allen späteren Verbindungen zu dem betreffenden Server überprüfen zu können.

    Sicherheits-Merkmale

    Datentypen

    Die folgende Tabelle nennt kurz die in den SSH-Protokollen verwendeten Datentypen:

    Typbezeichnung Erläuterung
    byte beliebiger 8-Bit-Wert

    Daten fester Länge werden manchmal als Byte-Feld repräsentiert. Dafür schreibt man byte[n], wobei n die Anzahl der Bytes des Feldes (bzw. dessen Länge) angibt.

    boolean Boolescher Wert der Länge ein Byte

    Der numerische Wert 0 repräsentiert den Wahrheitswert falsch, und der Wert 1 entspricht dem Booleschen Wert wahr. Alle Werte verschieden von Null werden als wahr interpretiert.

    uint32 vorzeichenlose ganze Zahl der Länge 32 Bit

    Die 4 Bytes werden in network byte order gespeichert (also in der Reihenfolge abnehmender Wertigkeit).

    Bsp.: Die Hexadezimalzahl 0x29b7f4aa wird durch die Bytefolge 29 b7 f4 aa repräsentiert.

    string Binär-String (Byte-Folge) beliebiger Länge

    Den eigentlichen Daten-Bytes geht die als uint32 gespeicherte Länge (Anzahl der Bytes) voraus. Bei einem leeren String hat diese Länge den Wert Null. Durch die explizite Längenangabe benötigt man kein Zeichen zur Symbolisierung des Endes einer Bytefolge.

    mpint multiple precision integer: ganze Zahl beliebiger Genauigkeit (bzw. Länge) im Zweierkomplement

    Diese langen Zahlen werden als Bytefolgen gespeichert, mit dem MSB (most significant bit) zuerst. Für weitere Details sei auf die Spezifikation verwiesen.

    Algorithmennamen und Erweiterbarkeit

    Alle Algorithmen werden durch Zeichenfolgen identifiziert, die aus maximal 64 druckbaren US-ASCII-Zeichen bestehen, wobei Groß- und Kleinschreibung unterschieden werden.

    Es gibt zwei Formate für Algorithmennamen:

    Dieses Konzept, durch die Verwendung von Domainnamen lokale Namensräume zu schaffen, gilt bei SSH generell, d.h. für Algorithmen, Methoden, Formate und Erweiterungsprotokolle. Es gestattet, experimentelle oder geheime (classified) Erweiterungen vorzunehmen, ohne dabei Konflikte mit anderen Implementierungen hervorzurufen.

    Ein Entwurfsziel bestand darin, das Basis-Protokoll so einfach wie möglich zu halten und die Menge der obligatorischen Algorithmen so weit wie möglich zu begrenzen. Natürlich muß jede Implementierung eine Minimalmenge von Verfahren unterstützen, um die Interoperabilität zu gewährleisten.

  2. SSH Transport Layer Protocol

    Dieses Protokoll läßt sich (ähnlich wie z.B. SSL/TLS) als Basis für eine Reihe von sicheren Netzwerkdiensten nutzen. Es bietet eine starke Verschlüsselung, Server-Authentifizierung, Integritätssicherung sowie optional eine Daten-Kompression. Die Partner handeln die jeweils von ihnen in einer Verbindung verwendeten kryptographischen Verfahren aus. Dazu gehören die Methode des Schlüsselaustauschs, die symmetrische Chiffre, das Public-Key-Verfahren, der MAC-Algorithmus sowie die Einweg-Hashfunktion.

    Die Authentifizierung des Servers erfolgt rechnerbezogen. SSH-TLP gestattet keinerlei Nutzer-Authentifizierung.

    SSH benötigt als Basis auf der Ebene der Transportschicht einen zuverlässigen (reliable) Datenkanal, der beliebige 8-Bit-Zeichen unverfälscht überträgt.

    Alle Verbindungen werden generell vom Klienten iniitiert. Nach dem Verbindungsaufbau senden beide Seiten einen Identifikations-String der Form

    SSH-Protokollversion-Softwareversion Kommentare
    gefolgt von CRLF (Carriage Return und Line Feed).

    Anschließend beginnt sofort der Schlüsselaustausch, wobei ab diesem Moment alle folgenden Daten nur noch unter Verwendung des pakektorientierten Binär-Protokolls (Binary Packet Protocol) ausgetauscht werden dürfen, das in der Spezifikation des SSH-TLP definiert wird und dessen Pakete folgenden Aufbau haben:

    Bezeichnung des Feldes Bedeutung Datentyp
    packet_length Paketlänge in Bytes

    Bei der Bestimmung dieses Wertes werden die beiden Felder für die Paketlänge sowie den MAC nicht mitgezählt.

    uint32
    padding_length Länge der Padding-Daten byte
    payload Binärdaten des Nutzers (Nutzlast) byte[n1]
    n1 = packet_length - padding_length - 1
    
    random padding zufällig erzeugte Padding-Daten byte[n2]
    n2 = padding_length
    
    mac MAC (Message Authentication Code) Bytefeld der durch den MAC-Algorithmus vorgegebenen Länge
    Es sei hier nochmals darauf hingeweisen, daß SSH 2.0 im Gegensatz zu SSH 1.x zur Integritätssicherung keinen kryptographisch schwachen CRC, der z.B. die oben erwähnte Insertion Attack ermöglichte, sondern einen zuverlässigen MAC verwendet.

    Kompression

    Sofern eine optionale Kompression ausgehandelt wurde, wird genau das Payload-Feld mit Hilfe des vereinbarten Algorithmus komprimiert. Paketlänge sowie MAC beziehen sich jetzt auf die komprimierte Nutzlast.

    Kompression kann je nach der verwendeten Methode zustandsbehaftet, muß aber generell für die beiden Kommunikationsrichtungen unabhängig voneinander sein. Implementierungen müssen die Wahl unterschiedlicher Kompressionsalgorithmen für die beiden Richtungen gestatten.

    Gegenwärtig sind zwei Kompressionsmethoden definiert:

    Bezeichnung Status Bedeutung
    none obligatorisch keine Kompression
    zlib optional Kompression gemäß GNU ZLIB (LZ77)

    Symmetrische Verschlüsselung

    Die symmetrische Verschlüsselung dient der Gewährleistung der Vertraulichkeit.

    Im Rahmen des Schlüsselaustauschs werden ein symmetrisches Verschlüsselungsverfahren sowie ein Key ausgehandelt. Sofern eine Verschlüsselung stattfindet, müssen mit Ausnahme des MAC alle Felder eines Pakets (Paketlänge, Länge der Padding-Daten, Nutzlast und zufällig erzeugte Padding-Daten) mit dem gewählten Algorithmus chiffriert werden.

    Alle symmetrischen Verschlüsselungsverfahren sollten in der Regel Keys mit einer effektiven Länge von mindestens 128 Bit nutzen.

    Die Chiffrierung muß für beide Kommunikationsrichtungen unabhängig voneinander erfolgen. Außerdem müssen Implementierungen die Wahl unterschiedlicher Algorithmen für die beiden Richtungen gestatten, sofern mehrere Verfahren zur Verfügung stehen.

    Momentan sind folgende Chfiffren definiert:

    Bezeichnung Status Erläuterung
    3des-cbc obligatorisch Triple DES mit 3 Schlüsseln, EDE, im Modus Outer-CBC (äußere Verkettung)
    blowfish-cbc empfohlen Blowfish im Modus CBC mit 128-Bit-Schlüsseln
    twofish-cbc empfohlen Twofish im Modus CBC mit 256-Bit-Schlüsseln
    arcfour optional die Stromchiffre ARCFOUR
    idea-cbc optional IDEA im Modus CBC
    cast128-cbc optional CAST-128 im Modus CBC
    none optional keine Verschlüsselung; NICHT EMPFOHLEN!

    Datenintegrität

    Der MAC wird jeweils von einem zwischen Klienten und Server geteilten Geheimnis (d.h. einem Schlüssel), der Sequenznummer und dem unverschlüsselten Inhalt eines Pakets berechnet:

    mac = MAC(key, sequence_number || unencrypted_packet)
    
    Das Operator || symbolisiert in der Protokollspezifikation die Verkettung der Operanden.

    Die Sequenznummer ist eine implizite Sequenznummer der Pakete, dargestellt als uint32. Sie wird

    Die MAC-Berechnung muß für beide Kommunikationsrichtungen unabhängig voneinander erfolgen. Außerdem müssen Implementierungen die Wahl unterschiedlicher MAC-Algorithmen für die beiden Richtungen gestatten.

    Die MAC-Bytes müssen generell unverschlüsselt als letzter Teil eines Pakets transferiert werden.

    Gegenwärtig sind die folgenden MAC-Algorithmen definiert:

    Bezeichnung Status Erläuterung
    hmac-sha1 obligatorisch HMAC auf der Basis des SHA-1 (Länge = 20 Byte)
    hmac-sha-96 empfohlen die ersten 96 Bit des hmac-sha1 (Länge = 12 Byte)
    hmac-md5 optional HMAC auf der Basis des MD5 (Länge = 16 Byte)
    hmac-md5-96 optional die ersten 96 Bit des hmac-md5 (Länge = 12 Byte)
    none optional kein MAC; NICHT EMPFOHLEN!

    Schlüsselaustauschverfahren

    In der SSH-Spezifikation wird nur ein einziges Schlüsselaustauschverfahren definiert:

    Bezeichnung Status
    diffie-hellman-group1-sha1 obligatorisch

    Es handelt sich hierbei um einen Diffie-Hellman-Schlüsselaustausch, wobei die privaten Schlüssel beider Partner jeweils zufällig gewählt werden. Im Ergebnis des Schlüsselaustauschs entsteht ein gemeinsamer Schlüssel, der durch keinen der beiden Partner allein bestimmt werden kann.

    Um sich gegenüber dem Klienten zu authentifizieren, sendet der Server-Rechner außerdem eine mit seinem privaten Host-Key erstellte digitale Signatur. Bei der dabei signierten Nachricht handelt es sich um einen Hashwert, der mittels des SHA-1 aus einer Bytefolge berechnet wird, die ihrerseits durch die Verkettung der folgenden Elemente zu bilden ist:

    Die Beschreibung des Schlüsselaustauschs sowie der konkret zu nutzenden Diffie-Hellman-Parameter (Generator g, Primzahl p) ist im Draft des SSH-TLP vom 22.2.1999 im Abschnitt 6 zu finden.

    Public-Key-Algorithmen

    Das Protokoll wurde so entworfen, daß es mit fast allen Public-Key-Formaten, Kodierungen sowie Signatur- und/oder Verschlüsselungsalgorithmen arbeiten kann.

    Es gibt verschiedene Aspekte, die den Typ eines öffentlichen Schlüssels definieren:

    Gegenwärtig sind die folgenden Formate für öffentliche Schlüssel und/oder Zertifikate definiert, wobei alle ausschließlich für digitale Signaturen und nicht für Verschlüsselungen genutzt werden:

    Bezeichnung Status Erläuterung
    ssh-dss obligatorisch DSS, der Digital Signature Standard der US-Regierung
    x509v3 empfohlen X.509v3-Zertifikate
    spki optional SPKI-Zertifikate (s. dazu http://www.ietf.org/html.charters/spki-charter.html)
    pgp optional OpenPGP-Zertifikate (s. dazu http://www.ietf.org/html.charters/openpgp-charter.html)

    Schlüsselaustausch (key exchange)

    1. Aushandlung der Algorithmen

      Der Schlüsselaustausch beginnt damit, daß beide Seiten ein KEXINIT-Paket folgender Struktur senden:

      byte      SSH_MSG_KEXINIT
      byte[16]  cookie (random bytes)
      string    kex_algorithms
      string    server_host_key_algorithms
      string    encryption_algorithms_client_to_server
      string    encryption_algorithms_server_to_client
      string    mac_algorithms_client_to_server
      string    mac_algorithms_server_to_client
      string    compression_algorithms_client_to_server
      string    compression_algorithms_server_to_client
      string    languages_client_to_server
      string    languages_server_to_client
      boolean   first_kex_packet_follows
      uint32    0 (reserved for future extension)
      
      Das cookie ist ein vom jeweiligen Sender generierter zufälliger Wert. Sein Zweck besteht darin zu verhindern, daß eine Seite allein in der Lage ist, die Schlüssel sowie den Sitzungsidentifikator voll zu bestimmen.

      Bei den dem cookie folgenden Angaben zu den verschiedenen kryptographischen Algorithmen sowie Sprachen handelt es sich um Listen, deren Elemente (jeweils ein Name eines Algorithmus oder ein Symbol für eine Sprache) durch Kommas voneinander zu trennen sind und fallend nach der Präferenz geordnet werden.

      Dem Austausch der KEXINIT-Pakete schließt sich das Schlüsselaustauschverfahren an. Es kann je nach Algorithmus den Austausch mehrerer Pakete umfassen.

      Falls das Feld first_kex_packet_follows des KEXINIT-Paketes den Wert wahr hat, signalisiert dies, daß dem KEXINIT-Paket unmittelbar (also ohne auf das KEXINIT der Gegenseite zu warten) ein Paket für den Schlüsselaustausch folgt. Natürlich kennt der Sender in diesem Falle die Liste der vom Partner unterstützten Schlüsselaustauschverfahren noch nicht und muß daher eines "erraten". Falls sich diese Entscheidung als unzutreffend herausstellt, wird das entsprechende Paket für den Schlüsselaustausch vom Empfänger stillschweigend ignoriert. Anderenfalls ist der Schlüsselaustausch unter Beachtung dieses Pakets durchzuführen.

    2. Resultat des Schlüsselaustauschs

      Der Schlüsselaustausch erzeugt zwei Werte: ein gemeinsames Geheimnis K (ein Schlüssel) sowie einen Hashwert H. Aus ihnen werden die zur Verschlüsselung und Authentifizierung genutzten Keys abgeleitet. Der Hashwert H des ersten Schlüsselaustauschs (später kann es noch weitere geben) dient zusätzlich als Sitzungsidentifikator (session_id), der eine Sitzung eineindeutig identifiziert und sich nach seiner einmaligen Berechnung nicht mehr verändert. Dieser Sitzungsidentifikator wird durch die Authentifizierungsverfahren als Teil derjenigen Daten verwendet, die jeweils signiert werden, um den Besitz eines bestimmten privaten Schlüssels nachzuweisen.

      Jedes Schlüsselaustauschverfahren spezifiziert eine Einweg-Hashfunktion HASH, die beim Schlüsselaustausch zum Einsatz kommt. Dieselbe Hashfunktion muß auch beim Ableiten der einzelnen Schlüssel aus dem gemeinsamen Geheimnis K eingesetzt werden.

      Die für die Verschlüsselung genutzten Schlüssel und Initialisierungsvektoren (IVs) werden durch Anwendung der Funktion HASH auf einen bekannten Wert sowie das Geheimnis K nach folgender Vorschrift berechnet:

      Anfangs-IV vom Klienten zum Server HASH(K || H || "A" || session_id)

      K wird als mpint kodiert, "A" steht für das ASCII-Zeichen A mit dem numerischen Wert 65.

      Anfangs-IV vom Server zum Klienten HASH(K || H || "B" || session_id)
      Schlüssel für symmetrische Verschlüsselung vom Klienten zum Server HASH(K || H || "C" || session_id)
      Schlüssel für symmetrische Verschlüsselung vom Server zum Klienten HASH(K || H || "D" || session_id)
      Schlüssel für Integritätssicherung vom Klienten zum Server HASH(K || H || "E" || session_id)
      Schlüssel für Integritätssicherung vom Server zum Klienten HASH(K || H || "F" || session_id)
      Sämtliche IVs und Schlüssel müssen dabei stets vom Anfang des jeweils berechneten Hashwertes entnommen werden. Für Chiffren mit variabler Schlüssellänge (z.B. Blowfish und Twofish) wird eine Schlüssellänge von 128 Bit empfohlen. Falls die Länge des benötigten Schlüssels (bzw. IVs) die Länge des durch HASH generierten Hashwertes übersteigt, sind nach folgender Vorschrift so lange weitere Hashwerte zu berechnen und mit dem bisherigen Resultat zu verketten, bis genügend Schlüsselbits zur Verfügung stehen:
      K1 = HASH(K || H || X || session_id)   (X ist z.B. "A")
      K2 = HASH(K || H || K1)
      K3 = HASH(K || H || K1 || K2)
      K4 = HASH(K || H || K1 || K2 || K3)
      ...
      key = K1 || K2 || K3 || K4 || ...
      
      Das Resultat key entsteht durch die Verkettung der iterativ berechneten Hashwerte bzw. Teilschlüssel K1, K2 usw. Ab K2 fließen in die Berechnung des aktuellen Teilschlüssels die Werte K und H sowie der aktuelle Wert von key (und damit alle zuvor ermittelten Teilschlüssel) ein.

    3. Wiederholung des Schlüsselaustauschs (key re-exchange)

      Es wird empfohlen, die Schlüssel einer Sitzung spätestens entweder nach jedem Transfer von einem Gigabyte Daten oder nach jeder Stunde (je nachdem, was zuerst eintritt) durch die Wiederholung des Schlüsselaustauschs zu ändern. Aus Performance-Gründen (Public-Key-Operationen sind relativ aufwendig) sollte der Schlüsselaustausch allerdings auch nicht zu oft erfolgen.

    Anforderung von Diensten (service request)

    Nach dem Schlüsselaustausch fordert der Klient vom Server Dienste an. Der jeweilige Dienst wird durch einen Namen identifiziert. Gegenwärtig wurden die folgenden beiden Namen reserviert:

    Das sind die Bezeichnungen für die Dienste, die vom SSH-AP bzw. dem SSH-CP erbracht werden.

  3. SSH Authentication Protocol

    Hierbei handelt es sich um ein allgemeines Protokoll zur Authentifizierung von Nutzern. Es wird davon ausgegangen, daß sich dieses Protokoll auf dem SSH-TLP abstützt und daß letzteres die Integrität und Vertraulichkeit der Kommunikation gewährleistet.

    Die Spezifikation beschreibt eine nutzerbezogene Authentifizierung auf der Basis von öffentlichen Schlüsseln oder Paßwörtern sowie eine rechnerbezogene Authentifizierung der Klienten-Maschine. Weitere Verfahren können bei Bedarf in separaten Dokumenten spezifiziert werden.

    Das SSH-AP stellt dem darüberliegenden SSH-CP genau einen authentifizierten Tunnel zur Verfügung.

    Beim Start des SSH-AP erhält dieses vom darunterliegenden Protokoll den Sitzungsidentifikator, der bekanntlich eine Sitzung eineindeutig identifiziert und sich daher für Signaturen eignet, die den Besitz eines privaten Schlüssels nachweisen.

    Die folgende Liste beschreibt die drei oben genannten Authentifizierungsmethoden:

  4. SSH Connection Protocol

    Zum Leistungsumfang dieses Protokolls gehören:

    Die Daten aller derartigen (logischen) Kanäle werden zeitmultiplex über einen einzigen verschlüsselten Tunnel übertragen. Das SSH-CP wurde so konzipiert, daß es oberhalb des SSH-TLP sowie des SSH-AP zum Einsatz kommt und so einen authentifizierten, integren und verschlüsselten Kanal vorfindet.

    Kanal-Mechanismus

    Alle Terminal-Sitzungen, weitergeleiteten Verbindungen etc. werden als Kanäle (channels) bezeichnet. Jede Seite ist berechtigt, einen neuen Kanal zu eröffnen. Kanäle realisieren eine fensterbasierte Flußkontrolle (vgl. TCP). Es dürfen so lange keine Daten an einen Kanal übergeben werden, bis eine Nachricht empfangen wurde, die anzeigt, daß Platz im Fenster vorhanden ist.

    Als zwei spezielle Kanäle werden in der Spezifikation des SSH-CP

    genauer beschrieben. Unter einer Sitzung (session) wird dabei die entfernte Ausführung eines Programms (Shell, Applikation, System-Kommando, eingebautes Subsystem) verstanden. Eine solche Sitzung kann optional über ein Terminal verfügen sowie eine X11-Weiterleitung nutzen. Mehrere Sitzungen können simultan aktiv sein.

    Im Gegensatz zu SSH 1.x gestattet SSH 2.0, Signale an entfernte Prozesse zu senden. Dies ist natürlich nur auf Systemen möglich, die Signale unterstützen (z.B. UNIX).


Frage 8.4.4.1:

Sehr häufig befinden sich die Administrationsdateien der SSH in netzbasierten Dateisystemen (NFS, AFS, ...). Welche Gefahren können daraus erwachsen? Beschreiben Sie das Prinzip eines möglichen Angriffs unter der Annahme, daß die Daten im NFS liegen. Welche Vorteile bringt hier das AFS?


Frage 8.4.4.2:

In der unter http://www.tu-chemnitz.de/~hot/ssh/#beispiel gezeigten Beispielsitzung wurde eine Verschlüsselung des privaten RSA-Keys des Anwenders vorgenommen. Warum ist das sinnvoll?


© Holger Trapp, 30.6.1999