Das Secure Shell Protokoll

The Protocols that Run the Internet Das Secure Shell Protokoll Stefan Klinger Fachbereich Informatik, Universität Konstanz 26. April 2003 Zusammenfassung SSH bietet Sicherheit für remote login und andere Dienste über ein unsicheres Netzwerk. Dieser Vortrag im Rahmen des Seminars The Protocols that Run the Internet soll einen Überblick über das Secure Shell Protokoll (Version 2.0) geben. Schwerpunkt ist dabei die Darstellung des Schichtenkonzepts und der Flexibilität, indem am Beispiel einer einfachen remote login session die betroffenen Protokolle besprochen werden. Eine vollständige Besprechung von SSH ist im gesteckten Rahmen leider nicht möglich. Aus diesem Grund wird auch nicht auf die verwendeten Verschlüsselungs- und Authentifizierungsalgorithmen eingegangen. 1 SSH - Das Secure Shell Protokoll SSH bietet Sicherheit für remote login und andere Dienste über ein unsicheres Netzwerk. Sicherheit bedeutet hier: Authentifizierung des Servers und des Clients bzw. Users Vertraulichkeit durch starke Verschlüsselung Integrität der Daten Mit unsicherem Netzwerk ist gemeint: Daten können abgehört und verändert werden jedoch schützt das Protokoll vor Übertragungsfehlern Meist setzt SSH auf TCP/IP auf. stefan.klinger@uni-konstanz.de 1

2 Die Architektur Einzelheiten über die Architektur erfährt man in [ssharch] Das Protokoll ist erweiterbar Algorithmen und Formate können nach Bedarf ergänzt oder ersetzt werden, z.b. wenn sich ein Algorithmus als unsicher erweist, oder jemand gerne andere Algorithmen einsetzen möchte. Jede dieser Komponenten hat einen eindeutigen ASCII Bezeichner. Die Eindeutigkeit bei lokalen 1 Erweiterung wird durch Anhängen des DNS Namens gewährleistet (z.b. myalgo@foo.com). Die Benamsung ist im Protokoll geregelt. Das Protokoll ist flexibel. Für jede Verbindung werden unabhängig für beide Richtungen die zu verwendenden Methoden verhandelt. Die verhandelten Methoden können später jederzeit gewechselt werden. Das Protokoll sind eigentlich Die Protokolle. Die SSH-Protokolle bilden einen Stapel voneinander relativ unabhängiger Schichten. Nur die unterste Schicht ist für Verschlüsselung und Integrität verantwortlich. 3 Die Protokollschichten Was passiert hier? Selbst bei einer einfachen login session sind bereits mehrere der SSH Protokolle vertreten. 1. Das SSH TRANSPORT LAYER Protokoll [sshtrans] 2. Das SSH AUTHENTICATION Protokoll [sshauth], hier in Verbindung mit dem SSH AUTHENTICATION AGENT Protokoll [sshagent] 3. Das SSH CONNECTION Protokoll [sshconn] Ich werde diese Protokolle im Folgenden kurz und oberflächlich besprechen, ohne dabei auf die zur Authentifizierung, Verschlüsselung und Integritätswahrung verwendeten Algorithmen einzugehen. SSH ist weitgehend unabhängig von kryptographischen Algorithmen da diese ausgetauscht werden können. Auch 1 Die Erweiterung wird nur in einem Netzwerk verwendet, z.b. innerhalb einer Universität, und ist nicht für die weitere Verbreitung vorgesehen. 2

gehören weit mehr Protokolle zu SSH als hier gezeigt, diese findet man bei [secsh]. Trotzdem bietet diese Besprechung einen ersten Einblick in die Konzepte und Flexibilität von SSH. Die folgende Grafik stellt die an einer interaktiven login session beteiligten Protokolle und ihre Beziehungen zueinander dar. Die gestrichelten Pfeile geben an, welche Komponente welche andere startet (z.b. wird das SSH CONNEC- TION Protokoll meist vom SSH AUTHENTICATION Protokoll gestartet). Dünne durchgezogene Linien stellen Kommunikation zur Authentifikation dar (z.b. müssen sowohl Client als auch Server Zugriff auf den Server-Hostkey haben damit sich der Server Authentifizieren kann; Der User teilt dem SSH AUTHEN- TICATION AGENT seine passphrase mit). Die dicke durchgezogen Linie stellt schließlich die Nutzdaten dar. Grau hinterlegt sind die einzelnen Protokollebenen. Terminal Login shell z.b. tty oder xterm z.b. bash Authentication Agent Verwaltet private Schlüssel startet Kommunikation für Nutzdaten......und für die Authentifizierung C l i e n t SSH Client Connection Multiplexing Startet Services Authentication Authentifiziert Client / User SSH Server Connection Multiplexing Startet Services Authentication Authentifiziert Client / User S e r v e r Transport Layer ver & entschlüsselt Authentifiziert Server? Server Hostkey Transport Layer ver & entschlüsselt Authentifiziert Server TCP/IP Port 22 3.1 Das SSH TRANSPORT LAYER Protokoll Das SSH TRANSPORT LAYER Protokoll ist in [sshtrans] definiert. Setzt auf einem zuverlässigen binären 8-Bit Protokoll auf, meist TCP/IP. Dieses schützt vor Übertragungsfehlern. Es bietet Verschlüsselung, Authentifizierung des Servers, Integrität der Daten und Kompression. Nach dem Verbindungsaufbau (bei TCP/IP an Port 22) werden die zu verwendenden Methoden zwischen Client und Server verhandelt, die Schlüssel ausgetauscht, und der Server authentifiziert. 3

3.1.1 Verbindungsaufbau 1. Schritt Der Client kontaktiert den Server an Port 22 [IANA] 2. Schritt Beide Seiten senden ihren Version-String SSH-$ protokollversion -$ softwareversion <CR><LF> Methoden zur Wahrung der Kompatibilität zwischen Protokollversion 2.0 (hier beschrieben) und früheren Versionen sind hier implementiert. 3.1.2 Datenübertragung Nach dem Version-String werden Daten ausschließlich in Binärpaketen übertragen: packet length Diese Daten padding length werden alle [ ] payload verschlüsselt [ ] random padding [m] mac klartext Ist ein Verschlüsselungs-Algo vereinbart, werden die Daten mit diesem verschlüsselt. Der Empfänger sollte die Paketlänge nach Empfangen der ersten vier Bytes entschlüsseln. hängt vom verhandelten Message Authentication Code Algorithmus ab. Das random padding wird so gewählt, daß gilt: wo!" $#&% ('*) Blockgröße des Verschlüsselungs-Algos Alle im Folgenden dargestellten Pakete sind der Inhalt des payload Feldes. Das erste Byte identifiziert dabei jeweils den Inhalt. Hinweis Initial (vor den Verhandlungen) wird nicht verschlüsselt, und es ist + da noch kein mac-algo vereinbart wurde. Es gibt also noch keine Verschlüsselung und keine Integrität. 3.1.3 Schlüsselaustausch & Verhandlung der Methoden 1. Schritt Jede Seite sendet eine SSH MSG KEXINIT Nachricht 4

SSH MSG KEXINIT [16] random cookie string kex algorithms Jede Seite zählt die Algorithmen auf, string server host key algorithms die sie unterstützt string encryption algorithms c2s Die Strings enthalten, durch Komma string encryption algorithms s2c getrennt, standardisierte Bezeichner string mac algorithms c2s string mac algorithms s2c c2s: Client to Server string compression algorithms c2s s2c: Server to Client string compression algorithms s2c string languages c2s language tags nach [RFC1766] string languages s2c boolean first kex packet follows Versuche Schlüsselaustausch 0 reserviert Die Bedeutung des random cookie erschließt sich nicht ganz aus der Protokolldefinition. Es soll wohl verhindern, daß eine Seite Wissen über den verwendeten Schlüssel erlangen kann. Wie dies funktioniert wird nicht ganz klar. Die verwendeten Bezeichner für die Algorithmen sind festgelegt. Für lokale Erweiterungen ist die Art der Benamsung festgelegt. Verwendet wird aus jeder Liste der erste Algo, der von beiden Seiten akzeptiert wird. Dabei ist auf Abhängigkeiten zwischen den Algos zu achten: z.b. unterstützen manche Host-Key Algorithmen nicht das Signieren und Verschlüsseln von Daten, und sind daher nicht für alle Schlüsselaustausch -Methoden geeignet. Optional (vollkommen beliebig, nur durch first kex packet follows angezeigt) wird gleich danach noch das erste Paket für die Schlüsselaustausch -Methode verschickt. Dieses Paket ist genau dann zu beachten, wenn der vermutete Algo auch angewendet wird. 2. Schritt Der verhandelte Schlüsselaustausch -Algo wird gestartet. Der Schlüsselaustausch -Algo nach DIFFIE-HELLMAN ist in [sshtrans] erklärt. Mit einer speziellen Primzahl ist er als diffie-hellman-group1-sha1 Algorithmus im Protokoll vorgesehen. Eine Beschreibung dieses Algorithmus findet man z.b. bei [rsa], eine sehr kurze Implementation in C bei [dh-c]. Der Algo liefert eine Hashfunktion, einen gemeinsamen Hash-Wert, und ein gemeinsames Geheimnis welches nur den beiden Parteien bekannt ist. Obwohl in der Protokolldefinition nicht explizit erwähnt, muß auch ein gemeinsames Geheimnis sein. Dies folgt auch aus der Definition des diffie-hellman-group1-sha1 Algorithmus. Der Server wird authentifiziert (z.b. als Folge des erfolgreichen Schlüsselaustausch s: Es existieren Schlüsselaustausch -Methoden, die die Authentifizierung des Servers implizieren). Dazu ist ein Host-Key des Servers nötig, den der Client kennen muß. 5

% % Beim ersten Schlüsselaustausch nach dem Verbindungsaufbau wird!" gesetzt. Dieser eindeutige Bezeichner für eine Verbindung wird auch bei späteren Verhandlungen nicht mehr geändert. Alle Schlüssel werden wie folgt berechnet:!" 1.!" 2. solange zu kurz: ist ein im Protokoll festgelegtes im Bereich A - F Die nötige Länge eines Schlüssels ergibt sich aus dem verhandelten Algorithmus. Zur Authentifizierung des Servers muß der Client den Host-Key des Servers kennen. Um die Verwendung von SSH zu vereinfachen, kann auf die Authentifizierung des Servers verzichtet werden. Dies sollte nur beim aller ersten Verbindungsaufbau zu dem fremden Server erfolgen. Vorteil: SSH wird öfter angewendet, erhöht also insgesamt die Sicherheit. Nachteil: Bei der ersten Verbindung kann eine man in the middle attac durchgeführt werden. Dies ist jedoch sehr unwahrscheinlich. Alternativen: Der Server-Key kann von einer zentralen vertrauenswürdigen (???) Stelle signiert zur Verfügung gestellt werden. Der Server-Key kann per Fingerprint und persönlichem oder telefonischem Kontakt überprüft werden 3. Schritt Jede Seite sendet eine SSH MSG NEWKEYS Nachricht. Diese Nachricht wird mit den alten Methoden (falls welche definiert waren, initial also keine) verschlüsselt. Auch ohne Verschlüsselung impliziert die Schlüsselaustausch -Methode jedoch die Integrität des Servers. Danach sind ausschließlich die neuen Methoden erlaubt. Jede Seite kann jederzeit (außer während dem Schlüsselaustausch ) mit einer neuen SSH MSG KEXINIT Nachricht erneute Verhandlungen erzwingen. Dies sollte regelmäßig erfolgen, etwa jede Stunde oder nach 1GB Daten. Sichere Kommunikation Alle Daten vom Client zum Server und umgekehrt werden unabhängig voneinander durch die verhandelten Algorithmen verschlüsselt. Der Empfänger ist jeweils dafür verantwortlich die Daten zu entschlüsseln und die Integrität zu prüfen. 6

Zur Sicherung der Integrität wird (bei verhandeltem MAC) an jede Nachricht noch eine Signatur!" angehängt. Die Länge von mac ist beiden Seiten durch die Verhandlung des MAC-Algos bekannt. Alle weiteren Protokollschichten kommunizieren über das SSH TRANS- PORT LAYER Protokoll, müssen sich also weder um Verschlüsselung, Integrität noch Authentifizierung des Servers kümmern. Nach dem Schlüsselaustausch 1. Schritt Der Client fordert einen Service vom Server an. string SSH MSG SERVICE REQUEST service name Im Protokoll sind zwei Service definiert: ssh-userauth ssh-connection 2. Schritt Der Server bietet den Service an und erlaubt dem Client diesen zu benutzen, indem er eine SSH MSG SERVICE ACCEPT Nachricht übergibt: string SSH MSG SERVICE ACCEPT service name Andernfalls muß der Server die Verbindung unterbrechen (siehe unten) 3.1.4 Administrative Nachrichten Abgesehen von den Datenpaketen die das Protokoll von den darüberliegenden Protokollschichten empfängt, oder an diese weiterleitet, gibt es noch ein paar Nachrichten, die das SSH TRANSPORT LAYER Protokoll steuern: Die Verbindung wird durch eine SSH MSG DISCONNECT Nachricht getrennt. SSH MSG DISCONNECT reason code ist im Protokoll definiert string description Beschreibung in Worten string language tag language tags nach [RFC1766] Versteht eine Seite den angegebenen Nachrichtentyp nicht, so antwortet sie mit SSH MSG UNIMPLEMENTED sequence number der betreffenden Nachricht 7

Debug Nachrichten erleichtern die Fehlersuche Es gibt sogar einen Nachrichtentyp der zwar akzeptiert wird, dessen Daten (ein string) jedoch ignoriert werden. Das Senden dieser Nachricht mit zufälligen Daten erschwert known plaintext und traffic analysis Angriffe. Auch kann diese Nachricht verwendet werden, um versteckte Nachrichten zu übermitteln. Client und Server müssen entsprechend modifiziert werden. 3.2 Das SSH AUTHENTICATION Protokoll Das SSH AUTHENTICATION Protokoll ist in [sshauth] definiert. Setzt auf dem SSH TRANSPORT LAYER Protokoll auf. Es bietet den Aufsatzpunkt für eine Verbindung mit dem SSH CONNEC- TION Protokoll, bei der der User/Client authentifiziert ist. um dieses Protokoll zu starten setzt der Client in seinem SSH MSG SER- VICE REQUEST das Feld service name = ssh-userauth. 1. Schritt Um sich zu authentifizieren sendet der Client eine SSH MSG USER- AUTH REQUEST Nachricht an den Server SSH MSG USERAUTH REQUEST string user name Name des Users string service name starte Service nach Authentifizierung string method name Authentifizierungsmethode...... hängt von der Methode ab 2. Schritt Die jetzt ablaufende Kommunikation zwischen Server und Client ist abhängig von der gewählten Methode. 3. Schritt Danach antwortet der Server mit SSH MSG USERAUTH SUCCESS falls er die Authentifizierung akzeptiert, oder mit SSH MSG USERAUTH FAILURE string authentications continue Liste möglicher Methoden boolean partial success Letzter Versuch war erfolgreich falls die Authentifizierung nicht vollständig war. Besteht der Authentifizierungsvorgang aus mehreren Schritten, so sendet der Server auch nach jedem erfolgreichen Schritt der die Authentifizierung nicht erfolgreich abschließt eine SSH MSG USERAUTH FAILURE Nachricht, bei der jedoch partial success auf TRUE gesetzt ist. Die Liste authentications continue enthält dann eine Liste der noch verbleibenden möglichen Methoden von der der Client eine auswählen kann. 8

Wird als Authentifizierungsmethode none gewählt, so muß der Server diesen Versuch zurückweisen. Zweck dieser Methode ist es, eine Liste möglicher Authentifizierungsmethoden abzufragen: Der Server übermittelt eine Liste der möglichen Methoden (und muß nur diese akzeptieren), der Client kann eine beliebige davon auswählen. Ist eine Authentifizierung fehlgeschlagen, so darf der Server irreführende Daten in der Liste authentications continue angeben, und trotzdem nie einen weiteren Versuch akzeptieren. Die Authentifizierung ist abgeschlossen, sobald der Server SSH MSG - USERAUTH SUCCESS meldet. Solange die Authentifizierung noch nicht abgeschlossen ist kann der Server Nachrichten an den Client senden. Der Client sollte diese anzeigen (vergleichbar mit /etc/issue bei guten Betriebssystemen). SSH MSG USERAUTH BANNER string message Eine Nachricht string language language tags nach [RFC1766] 3.2.1 Authentifizierungsmethoden Das Protokoll ist auch hier erweiterbar, drei Methoden sind im Protokoll definiert. Insbesondere sind die Authentifizierungsmethoden unabhängig von den beim Schlüsselaustausch verhandelten Methoden. Beispiel public key ist die einzige Methode die das SSH AUTHENTICA- TION Protokoll vorschreibt. Der Besitz eines privaten Schlüssels authentifiziert den Client. Meist ist dieser Schlüssel verschlüsselt beim User gespeichert und muß erst mit einer passphrase freigeschaltet werden. 1. Schritt Der Client fragt nach dieser Authentifizierungsmethode mit SSH MSG USERAUTH REQUEST string user name Diese Felder wie string service name oben besprochen string public key boolean FALSE siehe unten string public key algorithm name Name des Algos string public keyblob z.b. Zertifikate des Schlüssels 2. Schritt Akzeptiert der Server diese Anfrage... SSH MSG USERAUTH PK OK string public key algorithm name Daten aus der string public keyblob Anfrage 9

3. Schritt...so sendet der Client ein von ihm mit seinem privaten Schlüssel signiertes Paket an den Server, um sich zu authentifizieren: SSH MSG USERAUTH REQUEST string user name Diese Felder wie string service name oben besprochen string public key boolean TRUE siehe unten string public key algorithm name wie oben string public key der öffentliche Schlüssel string signature Signatur über das ganze Paket Der Client darf auch gleich zu Beginn dieses Paket senden. Es es kann anhand des boolean Feldes identifiziert werden. 4. Schritt Der Server kann anhand des öffentlichen Schlüssels des Benutzers die Echtheit des Paketes überprüfen. Damit ist der Client authentifiziert. Der öffentliche Schlüssel wurde zuvor an den Server übermittelt. Hinweis Hier ist die Protokolldefinition nicht ganz eindeutig. Dort heißt es: Der Server muß prüfen, ob der mit dem public key Paket übergebene öffentliche Schlüssel zur Authentifizierung akzeptiert wird. In [OpenSSH] heißt es jedoch: Der öffentliche Schlüssel des Clients/Users muß dem Server in $SERVERHOST:$HOME/.ssh/authorized keys bekannt sein. So verhält sich auch die Implementation. Das Protokoll läßt hingegen offen, wie der Schlüssel auf Akzeptanz geprüft werden soll, theoretisch könnte er auch erst in dem Anfrage-Paket übermittelt werden. Das SSH AUTHENTICATION AGENT Protokoll [sshagent] erleichtert dem User die Verwendung öffentlicher/privater Schlüssel zur Authentifizierung. Auf dem Client-Host kann außer dem SSH Client noch ein SSH Agent aktiv sein. In diesem Fall können Client und Agent über einen vertrauenswürdigen, plattform-abhängigen Kanal kommunizieren. Der Agent verwaltet die privaten Schlüssel des Users, und kann Operationen mit ihnen durchführen. Der Agent gibt den privaten Schlüssel nicht nach Außen weiter. Mögliche Operationen sind Signieren übergebener Daten. Entschlüsseln übergebener Daten. Challenge-Response Authentication, dabei werden übergebene Daten entschlüsselt, mit der session id konkateniert und der MD5-Hash davon zurückgegeben. 10

Die durchzuführende Operation wird durch einen string identifiziert. Diese Liste kann mit dem für SSH üblichen Mechanismus erweitert werden. Um dem Agenten einen privaten Schlüssel zur Verwaltung zu übergeben, muß der User ggf. die entsprechende passphrase eingeben. Der User kann private Schlüssel wieder vom Agent entfernen, die Anzahl ihrer Nutzungen und ihre Lebensdauer beschränken. Weitere Authentifizierungsmethoden 1. Die Methode password übermittelt den Benutzernamen und das passende Passwort an den Server. Obwohl das Passwort hier im Klartext erscheint, wird es vom darunter liegenden SSH TRANSPORT LAYER Protokoll verschlüsselt. 2. Die Methode host based identifiziert den User über einen hostspezifischen privaten Schlüssel und den Namen des Users auf diesem System. Bei dieser Methode sollte man darauf achten, daß keine unautorisierten Benutzer auf dem Client-Host Zugang zum privaten Schlüssel haben. 3.3 Das SSH CONNECTION Protokoll Das SSH CONNECTION Protokoll ist in [sshconn] definiert. Setzt auf dem SSH AUTHENTICATION Protokoll auf. In diesem Fall ist der service name beim SSH AUTHENTICATION Protokoll auf ssh- -connection zu setzen. Bietet interaktive login sessions (login shell auf dem Server-Host) und remote execution (Programm auf dem Server-Host ausführen) ermöglicht X11-forwarding (Ein X11-Client auf dem Server-Host leitet seine Ausgabe auf den X11-Server des Client-Hosts um) ermöglicht TCP/IP port-forwarding (Verbindungen z.b. zu einem Port des Server-Hosts werden an den Client-Host weitergeleitet) Durch Multiplexing werden mehrere logische Verbindungen (Kanäle) in einer SSH CONNECTION Verbindung untergebracht. Um diese Protokoll zu starten setzt der Client in seinem SSH MSG USER- AUTH REQUEST das Feld service name = ssh-connection. Obwohl dies aus dem Protokoll nicht ausdrücklich hervorgeht, ist zu vermuten daß ein Server das SSH CONNECTION Protokoll auch starten kann wenn sich der User/Client zuvor nicht identifiziert hat, ohne gegen das Protokoll zu verstoßen. Der Client muß dazu in seinem SSH MSG SERVICE REQUEST das Feld service name = ssh-connection setzen, der Server muß konfiguriert sein unauthentifizierte connections zu akzeptieren. 11

3.3.1 Das Konzept der Kanäle Terminals (login session, pseudo terminal), port forwarding etc. laufen über je einen Kanal. Kanäle sind bidirektional Jede Seite kann einen Kanal öffnen Alle Kanäle laufen über eine Verbindung mit dem SSH CONNECTION Protokoll Kanäle werden auf beiden Seiten durch nicht notwendig identische Nummern repräsentiert. 1. Schritt Ein Kanal wird durch Senden einer SSH MSG CHANNEL OPEN Nachricht geöffnet: SSH MSG CHANNEL OPEN string channel type sender channel initial window size maximum packet size max. Größe des Datenpakets...... abhängig vom Typ des Kanals channel type gibt an für welchen Zweck der Kanal geöffnet werden soll. Mögliche Werte sind im Protokoll definiert, können aber wie üblich erweitert werden. sender channel ist die Nummer mit der der Absender den Kanal identifiziert. Nachrichten auf diesem Kanal an den Absender dieser Nachricht tragen im Feld recipient channel diesen Wert. Der Absender gibt mit initial window size an, wieviele Datens er bereit ist zu empfangen. Beim Empfang von Daten dekrementiert er intern diesen Wert. Ist 0 erreicht so muß er alle weiteren Datennachrichten auf diesem Kanal ignorieren. 2. Schritt Der Empfänger dieser Nachricht bestätigt mit SSH MSG CHANNEL OPEN CONFIRMATION recipient channel sender channel initial window size maximum packet size...... abhängig vom Typ des Kanals oder lehnt ab, mit SSH MSG CHANNEL OPEN FAILURE recipient channel Kanal beim Empfänger reason code string textual information beschreibt den Fehler string language tag language tags nach [RFC1766] 12

recipient channel ist hier der Wert sender channel aus dem Paket von oben. Unter sender channel gibt der Absender dieser Nachricht an, mit welcher Nummer er seinerseits den Kanal identifiziert. Alles Andere wie oben 3. Schritt Für die Datenübertragung stehen drei Nachrichten zur Verfügung 1. Um mehr Daten empfangen zu können als bei der Öffnung des Kanals angegeben, sendet eine Seite SSH MSG CHANNEL WINDOW ADJUST recipient channel s to add Dabei gibt s to add an, wieviele Bytes mehr auf dem Kanal recipient channel empfangen werden. 2. Daten werden als string SSH MSG CHANNEL DATA recipient channel data oder string SSH MSG CHANNEL EXTENDED DATA recipient channel data type code data übertragen. Die zweite Form wird verwendet, um Ausgaben von stderr als solche markieren zu können. Der einzige im Protokoll definierte data - type code ist SSH EXTENDED DATA STDERR. Daten die mit diesen beiden Nachrichten versendet werden, müssen vom verfügbaren window - space abgezogen werden. 4. Schritt Will eine Seite keine Daten mehr senden, so kann Sie dies durch SSH MSG CHANNEL EOF recipient channel anzeigen. Sie kann dann weiterhin Daten über den betreffenden Kanal empfangen. Mit SSH MSG CHANNEL CLOSE recipient channel wird ein Kanal in beide Richtungen geschlossen. 13

3.3.2 Kanäle steuern Für die unterschiedlichen Kanaltypen gibt es spezielle administrative Nachrichten, die keinen window space verbrauchen. Allgemein haben sie die Form SSH MSG CHANNEL REQUEST recipient channel string request type boolean want reply...... spezifische Daten Worauf die Gegenseite falls want reply = TRUE ist mit SSH MSG CHANNEL SUCCESS recipient channel oder SSH MSG CHANNEL FAILURE recipient channel oder für diesen Request spezifischen Nachrichten antworten kann. Ist want reply = FALSE, so wird keine Antwort gesendet. Jede Seite kann weitere Pakete senden, ohne auf Antwort zu warten. 3.3.3 Beispiel Ein Beispiel ist das Aufbauen einer interaktiven login session: 1. Schritt Der Client öffnet einen Kanal für die Session: string SSH MSG CHANNEL OPEN session sender channel initial window size maximum packet size Eine session ist nicht unbedingt an eine Shell gebunden. Statt dessen kann jedes beliebige Programm auf dem Server ausgeführt werden, sofern der Server dies erlaubt. 2. Schritt (optional) Der Client fordert ein pseudo terminal an: SSH MSG CHANNEL REQUEST recipient channel Dieser Teil wie string pty-req oben besprochen boolean want reply string TERM Umgebungsvariable, z.b. vt100 columns Größe des Terminals rows in Zeilen und Spalten width oder in Pixeln height string encoded terminal modes beschreibt das Terminal 14

Es stehen Nachrichten zur Verfügung, die dem Server Änderungen der Fenstergröße mitteilen. Es ist nicht unbedingt notwendig ein Pseudoterminal anzufordern. Statt dessen (oder zusätzlich) könnte z.b. auch X11-forwarding aktiviert werden. Erfordert das auf dem Server gestartete Programm keine Interaktion so ist natürlich auch kein Fenster nötig. Die Beschreibung des Terminals in encoded terminal modes ist im Protokoll festgelegt, und folgt weitgehend den POSIX Vorgaben. 3. Schritt (optional) Umgebungsvariablen können übergeben werden: SSH MSG CHANNEL REQUEST recipient channel Dieser Teil wie string env oben besprochen boolean want reply string variable name Name und Wert der string variable value übergebenen Variablen 4. Schritt Die Shell wird gestartet: SSH MSG CHANNEL REQUEST recipient channel Dieser Teil wie string shell oben besprochen boolean want reply Dabei wird die Shell des Benutzers gestartet, die bei guten Betriebssystemen in /etc/passwd festgelegt ist. Statt request type = shell ist z.b. auch request type = exec möglich, um ein Programm auf dem Server zu starten. Es stehen Nachrichten zur Verfügung, die flow control, Änderungen des Pseudoterminals, oder Signale übermitteln. 4 Anhang 4.1 Standards US-ASCII [RFC20] 7-Bit ASCII in 8-Bit Bytes, bei denen das MSB gleich 0 ist. Alle Bezeichner, wie sie z.b. bei der Verhandlung von Algorithmen verwendet werden, müssen US-ASCII Strings sein. ISO-10646 UTF-8 [RFC2279] Diese Darstellung von Bytes verhält sich bei US- ASCII Daten transparent und kompatibel zu Software, die US-ASCII erwartet, ist jedoch auch fähig, UCS-2 und UCS-4 Zeichen darzustellen. Strings in UTF-8 werden innerhalb des SSH Protokolls meist für Fehlermeldungen verwendet. 15

language tags [RFC1766] Beschreiben die verwendete oder die zu verwendende Sprache. Wird bei SSH in Verbindung mit z.b. Fehlerbeschreibungen in UTF-8 gegeben. 4.2 Datentypen Die im Protokoll verwendeten Datentypen sind Ein octet, d.h. 8 Bit lang (das Protokoll auf dem SSH aufsetzt muß acht Bit Bytes übertragen) boolean Ein, 1 (true) oder 0 (false). Von 0 verschiedene Werte werden als 1 interpretiert. Ein 32 Bit langer vorzeichenloser Integer in network order (MSB zuerst). uint64 Ein 64 Bit langer vorzeichenloser Integer in network order (MSB zuerst). string Ein beliebig langer String, der beliebige 8-Bit Zeichen (auch die 0) enthalten kann. Gespeichert als ein der die Länge angibt, gefolgt von entsprechend vielen s. mpint Ein langer Integer mit Vorzeichen, gespeichert als string. Die 0 ist der leere String. Sonst enthält der Datenbereich des Strings die Binärdarstellung der Zahl, MSB zuerst, das erste Bit gibt das Vorzeichen an. Literatur [dh-c] [IANA] unbekannt, Diffie-Hellman Key Exchange 10 line C program http://www.cypherspace.org/ adam/rsa/dh-in-c.html http://www.iana.org/assignments/port-numbers [OpenSSH] Die Dokumentation zu OpenSSH 3.6.1 http://www.openssh.org/manual.html [rfc] [RFC20] http://www.rfc.net/ Vint Cerf, ASCII format for Network Interchange, RFC20, Oktober 1969 [rfc] [RFC1766] H. Alvestrand, Tags for the Identification of Languages, RFC1766, March 1995 [rfc] [RFC2279] F. Yergeau, UTF-8, a transformation format of ISO 10646, RFC2279, January 1998 [rfc] [rsa] [secsh] RSA Laboratories, What is Diffie-Hellman? http://www.rsasecurity.com/rsalabs/faq/3-6-1.html http://www.ietf.org/ids.by.wg/secsh.html 16

[sshagent] Ylonen, T., Secure Shell Authentication Agent Protocol, draft-ietfsecsh-agent-01.txt, November, 2002 [secsh] [ssharch] [sshauth] [sshconn] Ylonen, T., SSH Protocol Architecture, draft-ietf-secsh-architecture- 13.txt, September 2002 [secsh] Ylonen, T., SSH Authentication Protocol, draft-ietf-secsh-userauth- 16.txt, September 2002 [secsh] Ylonen, T., SSH Connection Protocol, draft-ietf-secsh-connect-16.txt, September 2002 [secsh] [sshtrans] Ylonen, T., SSH Transport Layer Protocol, draft-ietf-secsh-transport- 15.txt, September 2002 [secsh] 17