6. Interactive Sessions (Interaktive Sitzungen)
6. Interactive Sessions (Interaktive Sitzungen)
Eine Sitzung ist eine Remote-Ausführung eines Programms. Das Programm kann eine Shell, eine Anwendung, ein Systembefehl oder ein integriertes Subsystem sein. Es kann ein tty haben oder nicht und X11-Weiterleitung beinhalten oder nicht. Mehrere Sitzungen können gleichzeitig aktiv sein.
6.1. Opening a Session
Eine Sitzung wird durch Senden der folgenden Nachricht gestartet.
byte SSH_MSG_CHANNEL_OPEN
string "session"
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
Client-Implementierungen SOLLTEN alle Anfragen zum Öffnen von Sitzungskanälen ablehnen, um es einem beschädigten Server zu erschweren, den Client anzugreifen.
6.2. Requesting a Pseudo-Terminal
Ein Pseudo-Terminal kann für die Sitzung durch Senden der folgenden Nachricht zugewiesen werden.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "pty-req"
boolean want_reply
string TERM environment variable value (e.g., vt100)
uint32 terminal width, characters (e.g., 80)
uint32 terminal height, rows (e.g., 24)
uint32 terminal width, pixels (e.g., 640)
uint32 terminal height, pixels (e.g., 480)
string encoded terminal modes
Die encoded terminal modes werden in Abschnitt 8 beschrieben. Null-Dimensionsparameter MÜSSEN ignoriert werden. Die Zeichen-/Zeilen-Dimensionen überschreiben die Pixel-Dimensionen (wenn nicht null). Pixel-Dimensionen beziehen sich auf den zeichenbaren Bereich des Fensters.
Die Dimensionsparameter dienen nur zur Information.
Der Client SOLLTE pty-Anfragen ignorieren.
6.3. X11 Forwarding
6.3.1. Requesting X11 Forwarding
X11-Weiterleitung kann für eine Sitzung durch Senden einer SSH_MSG_CHANNEL_REQUEST-Nachricht angefordert werden.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "x11-req"
boolean want reply
boolean single connection
string x11 authentication protocol
string x11 authentication cookie
uint32 x11 screen number
Es wird EMPFOHLEN, dass das gesendete x11 authentication cookie ein gefälschtes, zufälliges Cookie ist und dass das Cookie überprüft und durch das echte Cookie ersetzt wird, wenn eine Verbindungsanfrage empfangen wird.
Die X11-Verbindungsweiterleitung sollte gestoppt werden, wenn der Sitzungskanal geschlossen wird. Bereits geöffnete Weiterleitungen sollten jedoch nicht automatisch geschlossen werden, wenn der Sitzungskanal geschlossen wird.
Wenn single connection TRUE ist, sollte nur eine einzige Verbindung weitergeleitet werden. Es werden keine weiteren Verbindungen nach der ersten oder nach dem Schließen des Sitzungskanals weitergeleitet.
Das x11 authentication protocol ist der Name der verwendeten X11-Authentifizierungsmethode, z.B. "MIT-MAGIC-COOKIE-1".
Das x11 authentication cookie MUSS hexadezimal kodiert sein.
Das X-Protokoll ist in [SCHEIFLER] dokumentiert.
6.3.2. X11 Channels
X11-Kanäle werden mit einer Kanal-Öffnungsanfrage geöffnet. Die resultierenden Kanäle sind unabhängig von der Sitzung, und das Schließen des Sitzungskanals schließt nicht die weitergeleiteten X11-Kanäle.
byte SSH_MSG_CHANNEL_OPEN
string "x11"
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
string originator address (e.g., "192.168.7.38")
uint32 originator port
Der Empfänger sollte mit SSH_MSG_CHANNEL_OPEN_CONFIRMATION oder SSH_MSG_CHANNEL_OPEN_FAILURE antworten.
Implementierungen MÜSSEN alle X11-Kanal-Öffnungsanfragen ablehnen, wenn sie keine X11-Weiterleitung angefordert haben.
6.4. Environment Variable Passing
Umgebungsvariablen können an die Shell/den Befehl übergeben werden, die/der später gestartet werden soll. Das unkontrollierte Setzen von Umgebungsvariablen in einem privilegierten Prozess kann ein Sicherheitsrisiko darstellen. Es wird empfohlen, dass Implementierungen entweder eine Liste zulässiger Variablennamen führen oder Umgebungsvariablen erst setzen, nachdem der Serverprozess ausreichende Privilegien aufgegeben hat.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "env"
boolean want reply
string variable name
string variable value
6.5. Starting a Shell or a Command
Sobald die Sitzung eingerichtet ist, wird am entfernten Ende ein Programm gestartet. Das Programm kann eine Shell, ein Anwendungsprogramm oder ein Subsystem mit einem hostunabhängigen Namen sein. Pro Kanal kann nur eine dieser Anfragen erfolgreich sein.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "shell"
boolean want reply
Diese Nachricht fordert an, dass die Standard-Shell des Benutzers (typischerweise in /etc/passwd in UNIX-Systemen definiert) am anderen Ende gestartet wird.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "exec"
boolean want reply
string command
Diese Nachricht fordert an, dass der Server die Ausführung des angegebenen Befehls startet. Die command-Zeichenkette kann einen Pfad enthalten. Es MÜSSEN normale Vorsichtsmaßnahmen getroffen werden, um die Ausführung nicht autorisierter Befehle zu verhindern.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "subsystem"
boolean want reply
string subsystem name
Diese letzte Form führt ein vordefiniertes Subsystem aus. Es wird erwartet, dass diese einen allgemeinen Dateiübertragungsmechanismus und möglicherweise andere Funktionen umfassen. Implementierungen können auch die Konfiguration weiterer solcher Mechanismen ermöglichen. Da die Shell des Benutzers normalerweise zur Ausführung des Subsystems verwendet wird, ist es ratsam, dass das Subsystem-Protokoll einen "magic cookie" am Anfang der Protokolltransaktion hat, um es von willkürlicher Ausgabe zu unterscheiden, die von Shell-Initialisierungsskripten usw. erzeugt wird. Diese störende Ausgabe der Shell kann entweder auf dem Server oder auf dem Client herausgefiltert werden.
Der Server SOLLTE die Ausführung des Protokollstapels beim Starten einer Shell oder eines Programms NICHT anhalten. Alle Ein- und Ausgaben von diesen SOLLTEN zum Kanal oder zum verschlüsselten Tunnel umgeleitet werden.
Es wird EMPFOHLEN, dass die Antwort auf diese Nachrichten angefordert und überprüft wird. Der Client SOLLTE diese Nachrichten ignorieren.
Subsystemnamen folgen der DNS-Erweiterbarkeits-Namenskonvention, die in [SSH-NUMBERS] beschrieben ist.
6.6. Session Data Transfer
Die Datenübertragung für eine Sitzung erfolgt unter Verwendung von SSH_MSG_CHANNEL_DATA- und SSH_MSG_CHANNEL_EXTENDED_DATA-Paketen und dem Fenstermechanismus. Der erweiterte Datentyp SSH_EXTENDED_DATA_STDERR wurde für stderr-Daten definiert.
6.7. Window Dimension Change Message
Wenn sich die Fenstergröße (Terminal) auf der Client-Seite ändert, DARF sie eine Nachricht an die andere Seite senden, um sie über die neuen Dimensionen zu informieren.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "window-change"
boolean FALSE
uint32 terminal width, columns
uint32 terminal height, rows
uint32 terminal width, pixels
uint32 terminal height, pixels
Eine Antwort SOLLTE NICHT auf diese Nachricht gesendet werden.
6.8. Local Flow Control
Auf vielen Systemen ist es möglich zu bestimmen, ob ein Pseudo-Terminal Control-S/Control-Q-Flusskontrolle verwendet. Wenn Flusskontrolle erlaubt ist, ist es oft wünschenswert, die Flusskontrolle am Client-Ende durchzuführen, um Antworten auf Benutzeranfragen zu beschleunigen. Dies wird durch die folgende Benachrichtigung erleichtert. Anfänglich ist der Server für die Flusskontrolle verantwortlich. (Auch hier bedeutet Client die Seite, die die Sitzung initiiert, und Server die andere Seite.)
Die unten stehende Nachricht wird vom Server verwendet, um dem Client mitzuteilen, wann er Flusskontrolle durchführen kann oder nicht (Control-S/Control-Q-Verarbeitung). Wenn client can do TRUE ist, darf der Client Flusskontrolle mit Control-S und Control-Q durchführen. Der Client DARF diese Nachricht ignorieren.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "xon-xoff"
boolean FALSE
boolean client can do
Auf diese Nachricht wird keine Antwort gesendet.
6.9. Signals
Ein Signal kann mit der folgenden Nachricht an den Remote-Prozess/Service übermittelt werden. Einige Systeme implementieren möglicherweise keine Signale, in diesem Fall SOLLTEN sie diese Nachricht ignorieren.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "signal"
boolean FALSE
string signal name (without the "SIG" prefix)
signal name-Werte werden wie in der Passage beschrieben kodiert, die SSH_MSG_CHANNEL_REQUEST-Nachrichten mit "exit-signal" in diesem Abschnitt beschreibt.
6.10. Returning Exit Status
Wenn der am anderen Ende laufende Befehl beendet wird, kann die folgende Nachricht gesendet werden, um den Exit-Status des Befehls zurückzugeben. Die Rückgabe des Status wird EMPFOHLEN. Für diese Nachricht wird keine Bestätigung gesendet. Der Kanal muss nach dieser Nachricht mit SSH_MSG_CHANNEL_CLOSE geschlossen werden.
Der Client DARF diese Nachrichten ignorieren.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "exit-status"
boolean FALSE
uint32 exit_status
Der Remote-Befehl kann auch gewaltsam aufgrund eines Signals beendet werden. Ein solcher Zustand kann durch die folgende Nachricht angezeigt werden. Ein exit_status von Null bedeutet normalerweise, dass der Befehl erfolgreich beendet wurde.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "exit-signal"
boolean FALSE
string signal name (without the "SIG" prefix)
boolean core dumped
string error message in ISO-10646 UTF-8 encoding
string language tag [RFC3066]
Der signal name ist einer der folgenden (diese stammen aus [POSIX]).
ABRT
ALRM
FPE
HUP
ILL
INT
KILL
PIPE
QUIT
SEGV
TERM
USR1
USR2
Zusätzliche signal name-Werte DÜRFEN im Format "sig-name@xyz" gesendet werden, wobei "sig-name" und "xyz" alles sein können, was ein bestimmter Implementierer möchte (außer dem "@"-Zeichen). Es wird jedoch vorgeschlagen, dass bei Verwendung eines configure-Skripts alle nicht standardmäßigen signal name-Werte, die es findet, als "[email protected]" kodiert werden, wobei "SIG" der signal name ohne das "SIG"-Präfix ist und "xyz" der Hosttyp ist, wie von "config.guess" bestimmt.
Die error message enthält eine zusätzliche textuelle Erklärung der Fehlermeldung. Die Nachricht kann aus mehreren durch CRLF (Carriage Return - Line Feed) getrennten Zeilen bestehen. Die Client-Software DARF diese Nachricht dem Benutzer anzeigen. Wenn dies geschieht, sollte die Client-Software die in [SSH-ARCH] besprochenen Vorsichtsmaßnahmen treffen.