Aller au contenu principal

6. Interactive Sessions (Sessions interactives)

6. Interactive Sessions (Sessions interactives)​

Une session est une exécution distante d'un programme. Le programme peut être un shell, une application, une commande système ou un sous-système intégré. Elle peut avoir ou non un tty, et peut impliquer ou non un transfert X11. Plusieurs sessions peuvent être actives simultanément.

6.1. Opening a Session (Ouverture d'une session)​

Une session est démarrée en envoyant le message suivant.

byte      SSH_MSG_CHANNEL_OPEN
string    "session"
uint32    sender channel
uint32    initial window size
uint32    maximum packet size

Les implémentations client DEVRAIENT rejeter toutes les requêtes d'ouverture de canal de session, afin de rendre plus difficile pour un serveur corrompu l'attaque du client.

6.2. Requesting a Pseudo-Terminal (Demande de pseudo-terminal)​

Un pseudo-terminal peut être alloué pour la session en envoyant le message suivant.

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

Les encoded terminal modes sont décrits dans la section 8. Les paramètres de dimension nuls DOIVENT être ignorés. Les dimensions en caractères/lignes priment sur les dimensions en pixels (lorsqu'elles sont non nulles). Les dimensions en pixels font référence à la zone dessinable de la fenêtre.

Les paramètres de dimension sont uniquement informatifs.

Le client DEVRAIT ignorer les requêtes pty.

6.3. X11 Forwarding (Transfert X11)​

6.3.1. Requesting X11 Forwarding​

Le transfert X11 peut être demandé pour une session en envoyant un message SSH_MSG_CHANNEL_REQUEST.

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

Il est RECOMMANDÉ que le x11 authentication cookie envoyé soit un faux cookie aléatoire, et que le cookie soit vérifié et remplacé par le vrai cookie lors de la réception d'une requête de connexion.

Le transfert de connexion X11 devrait s'arrêter lorsque le canal de session est fermé. Cependant, les transferts déjà ouverts ne devraient pas être fermés automatiquement lors de la fermeture du canal de session.

Si single connection est VRAI, une seule connexion devrait être transférée. Aucune connexion supplémentaire ne sera transférée après la première, ou après la fermeture du canal de session.

Le x11 authentication protocol est le nom de la méthode d'authentification X11 utilisée, par exemple "MIT-MAGIC-COOKIE-1".

Le x11 authentication cookie DOIT être encodé en hexadécimal.

Le protocole X est documenté dans [SCHEIFLER].

6.3.2. X11 Channels​

Les canaux X11 sont ouverts avec une requête d'ouverture de canal. Les canaux résultants sont indépendants de la session, et la fermeture du canal de session ne ferme pas les canaux X11 transférés.

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

Le destinataire devrait répondre par SSH_MSG_CHANNEL_OPEN_CONFIRMATION ou SSH_MSG_CHANNEL_OPEN_FAILURE.

Les implémentations DOIVENT rejeter toute requête d'ouverture de canal X11 si elles n'ont pas demandé de transfert X11.

6.4. Environment Variable Passing (Passage de variables d'environnement)​

Des variables d'environnement peuvent être passées au shell/commande à démarrer ultérieurement. La définition incontrôlée de variables d'environnement dans un processus privilégié peut être un risque de sécurité. Il est recommandé que les implémentations maintiennent soit une liste de noms de variables autorisées, soit ne définissent les variables d'environnement qu'après que le processus serveur a abandonné suffisamment de privilèges.

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 (Démarrage d'un shell ou d'une commande)​

Une fois la session configurée, un programme est démarré à l'extrémité distante. Le programme peut être un shell, un programme d'application ou un sous-système avec un nom indépendant de l'hôte. Une seule de ces requêtes peut réussir par canal.

byte      SSH_MSG_CHANNEL_REQUEST
uint32    recipient channel
string    "shell"
boolean   want reply

Ce message demandera le démarrage du shell par défaut de l'utilisateur (généralement défini dans /etc/passwd sur les systèmes UNIX) à l'autre extrémité.

byte      SSH_MSG_CHANNEL_REQUEST
uint32    recipient channel
string    "exec"
boolean   want reply
string    command

Ce message demandera au serveur de démarrer l'exécution de la commande donnée. La chaîne command peut contenir un chemin. Les précautions habituelles DOIVENT être prises pour empêcher l'exécution de commandes non autorisées.

byte      SSH_MSG_CHANNEL_REQUEST
uint32    recipient channel
string    "subsystem"
boolean   want reply
string    subsystem name

Cette dernière forme exécute un sous-système prédéfini. Il est prévu que ceux-ci incluent un mécanisme de transfert de fichiers général, et éventuellement d'autres fonctionnalités. Les implémentations peuvent également permettre de configurer davantage de tels mécanismes. Comme le shell de l'utilisateur est généralement utilisé pour exécuter le sous-système, il est conseillé que le protocole de sous-système comporte un "magic cookie" au début de la transaction de protocole pour le distinguer de toute sortie arbitraire générée par les scripts d'initialisation du shell, etc. Cette sortie parasite du shell peut être filtrée soit au niveau du serveur, soit au niveau du client.

Le serveur NE DEVRAIT PAS interrompre l'exécution de la pile de protocoles lors du démarrage d'un shell ou d'un programme. Toutes les entrées et sorties de ceux-ci DEVRAIENT être redirigées vers le canal ou vers le tunnel chiffré.

Il est RECOMMANDÉ que la réponse à ces messages soit demandée et vérifiée. Le client DEVRAIT ignorer ces messages.

Les noms de sous-systèmes suivent la convention d'extensibilité DNS décrite dans [SSH-NUMBERS].

6.6. Session Data Transfer (Transfert de données de session)​

Le transfert de données pour une session est effectué à l'aide des paquets SSH_MSG_CHANNEL_DATA et SSH_MSG_CHANNEL_EXTENDED_DATA et du mécanisme de fenêtre. Le type de données étendues SSH_EXTENDED_DATA_STDERR a été défini pour les données stderr.

6.7. Window Dimension Change Message (Message de changement de dimension de fenêtre)​

Lorsque la taille de la fenêtre (terminal) change côté client, il PEUT envoyer un message à l'autre extrémité pour l'informer des nouvelles dimensions.

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

Aucune réponse ne devrait être envoyée à ce message.

6.8. Local Flow Control (Contrôle de flux local)​

Sur de nombreux systèmes, il est possible de déterminer si un pseudo-terminal utilise le contrôle de flux control-S/control-Q. Lorsque le contrôle de flux est autorisé, il est souvent souhaitable d'effectuer le contrôle de flux côté client pour accélérer les réponses aux requêtes utilisateur. Cela est facilité par la notification suivante. Initialement, le serveur est responsable du contrôle de flux. (Ici encore, client désigne l'extrémité à l'origine de la session, et serveur l'autre extrémité.)

Le message ci-dessous est utilisé par le serveur pour informer le client lorsqu'il peut ou ne peut pas effectuer le contrôle de flux (traitement control-S/control-Q). Si client can do est VRAI, le client est autorisé à effectuer le contrôle de flux en utilisant control-S et control-Q. Le client PEUT ignorer ce message.

byte      SSH_MSG_CHANNEL_REQUEST
uint32    recipient channel
string    "xon-xoff"
boolean   FALSE
boolean   client can do

Aucune réponse n'est envoyée à ce message.

6.9. Signals (Signaux)​

Un signal peut être délivré au processus/service distant en utilisant le message suivant. Certains systèmes peuvent ne pas implémenter les signaux, auquel cas ils DEVRAIENT ignorer ce message.

byte      SSH_MSG_CHANNEL_REQUEST
uint32    recipient channel
string    "signal"
boolean   FALSE
string    signal name (without the "SIG" prefix)

Les valeurs signal name seront encodées comme indiqué dans le passage décrivant les messages SSH_MSG_CHANNEL_REQUEST utilisant "exit-signal" dans cette section.

6.10. Returning Exit Status (Renvoi du statut de sortie)​

Lorsque la commande en cours d'exécution à l'autre extrémité se termine, le message suivant peut être envoyé pour renvoyer le statut de sortie de la commande. Renvoyer le statut est RECOMMANDÉ. Aucun accusé de réception n'est envoyé pour ce message. Le canal doit être fermé avec SSH_MSG_CHANNEL_CLOSE après ce message.

Le client PEUT ignorer ces messages.

byte      SSH_MSG_CHANNEL_REQUEST
uint32    recipient channel
string    "exit-status"
boolean   FALSE
uint32    exit_status

La commande distante peut également se terminer brutalement en raison d'un signal. Une telle condition peut être indiquée par le message suivant. Un exit_status nul signifie généralement que la commande s'est terminée avec succès.

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]

Le signal name est l'un des suivants (ceux-ci proviennent de [POSIX]).

ABRT
ALRM
FPE
HUP
ILL
INT
KILL
PIPE
QUIT
SEGV
TERM
USR1
USR2

Des valeurs signal name supplémentaires PEUVENT être envoyées au format "sig-name@xyz", où "sig-name" et "xyz" peuvent être tout ce qu'un implémenteur particulier souhaite (à l'exception du signe "@"). Cependant, il est suggéré que si un script configure est utilisé, toutes les valeurs signal name non standard qu'il trouve soient encodées sous la forme "[email protected]", où "SIG" est le signal name sans le préfixe "SIG", et "xyz" est le type d'hôte, tel que déterminé par "config.guess".

Le error message contient une explication textuelle supplémentaire du message d'erreur. Le message peut être constitué de plusieurs lignes séparées par des paires CRLF (retour chariot - saut de ligne). Le logiciel client PEUT afficher ce message à l'utilisateur. Si cela est fait, le logiciel client devrait prendre les précautions décrites dans [SSH-ARCH].