Das Secure Shell Protokoll - Fachbereich Informatik und

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 betrof”
fenen 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.
[email protected]
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 lokalen1 Erweiterung wird durch Anhängen
des DNS Namens gewährleistet (z.B. [email protected]). 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 bil”
”
den 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 Protokol”
le vertreten.
1. Das SSH T RANSPORT L AYER Protokoll [sshTrans]
2. Das SSH A UTHENTICATION Protokoll [sshAuth], hier in Verbindung mit
dem SSH A UTHENTICATION A GENT Protokoll [sshAgent]
3. Das SSH C ONNECTION 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 C ONNEC TION Protokoll meist vom SSH A UTHENTICATION 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 A UTHEN TICATION A GENT 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
C l i e n t
SSH Client
SSH Server
Connection
Multiplexing
Startet Services
Connection
Multiplexing
Startet Services
Authentication
Authentifiziert
Client / User
Authentication
Authentifiziert
Client / User
Transport Layer
?
ver− & entschlüsselt
Authentifiziert Server
Server
Hostkey
TCP/IP
Transport Layer
ver− & entschlüsselt
Authentifiziert Server
Port 22
3.1 Das SSH T RANSPORT L AYER Protokoll
Das SSH T RANSPORT L AYER 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
S e r v e r
startet
Kommunikation
für Nutzdaten...
...und für die
Authentifizierung
Authentication Agent
Verwaltet private
Schlüssel
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:
uint32
byte
byte[ ]
byte[ ]
byte[m]
packet length padding length payload
random padding
mac
Diese Daten
werden alle
verschlüsselt
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
byte
byte[16]
string
string
string
string
string
string
string
string
string
string
boolean
uint32
SSH MSG KEXINIT
random cookie
kex algorithms
server host key algorithms
encryption algorithms c2s
encryption algorithms s2c
mac algorithms c2s
mac algorithms s2c
compression algorithms c2s
compression algorithms s2c
languages c2s
languages s2c
first kex packet follows
0
Jede Seite zählt die Algorithmen auf,
die sie unterstützt
Die Strings enthalten, durch Komma
getrennt, standardisierte Bezeichner
c2s: Client to Server
s2c: Server to Client
language tags nach [RFC1766]
Versuche Schlüsselaustausch
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 D IFFIE -H ELLMAN 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 byte 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 T RANS PORT L AYER 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.
byte
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:
byte
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 T RANSPORT L AYER Protokoll steuern:
Die Verbindung wird durch eine SSH MSG DISCONNECT Nachricht getrennt.
byte
uint32
string
string
SSH MSG DISCONNECT
reason code
description
language tag
ist im Protokoll definiert
Beschreibung in Worten
language tags nach [RFC1766]
Versteht eine Seite den angegebenen Nachrichtentyp nicht, so antwortet
sie mit
byte
uint32
SSH MSG UNIMPLEMENTED
sequence number
7
der betreffenden Nachricht
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 A UTHENTICATION Protokoll
Das SSH A UTHENTICATION Protokoll ist in [sshAuth] definiert.
Setzt auf dem SSH T RANSPORT L AYER Protokoll auf.
Es bietet den Aufsatzpunkt für eine Verbindung mit dem SSH C ONNEC TION Protokoll, bei der der User/Client authentifiziert ist.
um dieses Protokoll zu starten setzt der Client in seinem SSH MSG SERVICE REQUEST das Feld service name = ‘ssh-userauth’ .
1. Schritt Um sich zu authentifizieren sendet der Client eine SSH MSG USERAUTH REQUEST Nachricht an den Server
byte
string
string
string
...
SSH MSG USERAUTH REQUEST
user name
service name
method name
...
Name des Users
starte Service nach Authentifizierung
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
byte
SSH MSG USERAUTH SUCCESS
falls er die Authentifizierung akzeptiert, oder mit
byte
string
boolean
SSH MSG USERAUTH FAILURE
authentications continue
partial success
Liste möglicher Methoden
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).
byte
string
string
SSH MSG USERAUTH BANNER
message
language
Eine Nachricht
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 A UTHENTICA 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
byte
string
string
string
boolean
string
string
SSH MSG USERAUTH REQUEST
user name
service name
‘public key’
FALSE
public key algorithm name
public keyblob
Diese Felder wie
oben besprochen
siehe unten
Name des Algos
z.B. Zertifikate des Schlüssels
2. Schritt Akzeptiert der Server diese Anfrage...
byte
string
string
SSH MSG USERAUTH PK OK
public key algorithm name
public keyblob
9
Daten aus der
Anfrage
3. Schritt ...so sendet der Client ein von ihm mit seinem privaten Schlüssel
signiertes Paket an den Server, um sich zu authentifizieren:
byte
string
string
string
boolean
string
string
string
SSH MSG USERAUTH REQUEST
user name
service name
‘public key’
TRUE
public key algorithm name
public key
signature
Diese Felder wie
oben besprochen
siehe unten
wie oben
der öffentliche Schlüssel
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 A UTHENTICATION A GENT 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 T RANSPORT L AYER 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 C ONNECTION Protokoll
Das SSH C ONNECTION Protokoll ist in [sshConn] definiert.
Setzt auf dem SSH A UTHENTICATION Protokoll auf. In diesem Fall ist
der service name beim SSH A UTHENTICATION 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 C ONNECTION Verbindung untergebracht.
Um diese Protokoll zu starten setzt der Client in seinem SSH MSG USERAUTH REQUEST das Feld service name = ‘ssh-connection’ .
Obwohl dies aus dem Protokoll nicht ausdrücklich hervorgeht, ist zu vermuten daß ein Server das SSH C ONNECTION 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 C ONNECTION
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:
byte
string
uint32
uint32
uint32
...
SSH MSG CHANNEL OPEN
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 Datenbytes
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
byte
uint32
uint32
uint32
uint32
...
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
byte
uint32
uint32
string
string
SSH MSG CHANNEL OPEN FAILURE
recipient channel
reason code
textual information
language tag
12
Kanal beim Empfänger
beschreibt den Fehler
language tags nach [RFC1766]
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
byte
uint32
uint32
SSH MSG CHANNEL WINDOW ADJUST
recipient channel
bytes to add
Dabei gibt bytes to add an, wieviele Bytes mehr auf dem Kanal recipient channel empfangen werden.
2. Daten werden als
byte
uint32
string
SSH MSG CHANNEL DATA
recipient channel
data
oder
byte
uint32
uint32
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
byte
uint32
SSH MSG CHANNEL EOF
recipient channel
anzeigen. Sie kann dann weiterhin Daten über den betreffenden Kanal empfangen. Mit
byte
uint32
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
byte
uint32
string
boolean
...
SSH MSG CHANNEL REQUEST
recipient channel
request type
want reply
...
spezifische Daten
Worauf die Gegenseite – falls want reply = TRUE ist – mit
byte
uint32
SSH MSG CHANNEL SUCCESS
recipient channel
byte
uint32
SSH MSG CHANNEL FAILURE
recipient channel
oder
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:
byte
string
uint32
uint32
uint32
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:
byte
uint32
string
boolean
string
uint32
uint32
uint32
uint32
string
SSH MSG CHANNEL REQUEST
recipient channel
‘pty-req’
want reply
TERM
columns
rows
width
height
encoded terminal modes
14
Dieser Teil wie
oben besprochen
Umgebungsvariable, z.B. vt100
Größe des Terminals
in Zeilen und Spalten
oder in Pixeln
beschreibt das Terminal
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:
byte
uint32
string
boolean
string
string
SSH MSG CHANNEL REQUEST
recipient channel
‘env’
want reply
variable name
variable value
Dieser Teil wie
oben besprochen
Name und Wert der
übergebenen Variablen
4. Schritt Die Shell wird gestartet:
byte
uint32
string
boolean
SSH MSG CHANNEL REQUEST
recipient channel
‘shell’
want reply
Dieser Teil wie
oben besprochen
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 USASCII 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
byte Ein octet, d.h. 8 Bit lang (das Protokoll auf dem SSH aufsetzt muß acht Bit
Bytes übertragen)
boolean Ein byte, 1 (true) oder 0 (false). Von 0 verschiedene Werte werden als
1 interpretiert.
uint32 Ein 32 Bit langer vorzeichenloser Integer in network byte order (MSB zuerst).
uint64 Ein 64 Bit langer vorzeichenloser Integer in network byte order (MSB zuerst).
string Ein beliebig langer String, der beliebige 8-Bit Zeichen (auch die 0) enthalten kann. Gespeichert als ein uint32 der die Länge angibt, gefolgt von
entsprechend vielen bytes.
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]
unbekannt, Diffie-Hellman Key Exchange 10 line C program
http://www.cypherspace.org/˜adam/rsa/dh-in-C.html
[IANA]
http://www.iana.org/assignments/port-numbers
[OpenSSH] Die Dokumentation zu OpenSSH 3.6.1
http://www.openssh.org/manual.html
[rfc]
http://www.rfc.net/
[RFC20]
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]
RSA Laboratories, What is Diffie-Hellman?
http://www.rsasecurity.com/rsalabs/faq/3-6-1.html
[secsh]
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] Ylonen, T., SSH Protocol Architecture, draft-ietf-secsh-architecture13.txt, September 2002 [secsh]
[sshAuth] Ylonen, T., SSH Authentication Protocol, draft-ietf-secsh-userauth16.txt, September 2002 [secsh]
[sshConn] Ylonen, T., SSH Connection Protocol, draft-ietf-secsh-connect-16.txt,
September 2002 [secsh]
[sshTrans] Ylonen, T., SSH Transport Layer Protocol, draft-ietf-secsh-transport15.txt, September 2002 [secsh]
17