6. Interactive Sessions (Sessioni interattive)
6. Interactive Sessions (Sessioni interattive)
Una sessione è un'esecuzione remota di un programma. Il programma può essere una shell, un'applicazione, un comando di sistema o un sottosistema integrato. Può avere o meno un tty e può comportare o meno un inoltro X11. Possono essere attive più sessioni contemporaneamente.
6.1. Opening a Session (Apertura di una sessione)
Una sessione viene avviata inviando il messaggio seguente.
byte SSH_MSG_CHANNEL_OPEN
string "session"
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
Le implementazioni client DOVREBBERO rifiutare tutte le richieste di apertura di canale di sessione, per rendere più difficile per un server compromesso attaccare il client.
6.2. Requesting a Pseudo-Terminal (Richiesta di un pseudo-terminale)
Per una sessione può essere allocato un pseudo-terminale inviando il messaggio seguente.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "pty-req"
boolean want_reply
string TERM environment variable value (es., vt100)
uint32 terminal width, characters (es., 80)
uint32 terminal height, rows (es., 24)
uint32 terminal width, pixels (es., 640)
uint32 terminal height, pixels (es., 480)
string encoded terminal modes
Gli encoded terminal modes sono descritti nella sezione 8. I parametri di dimensione nulli DOVREBBERO essere ignorati. Le dimensioni in caratteri/righe hanno la precedenza sulle dimensioni in pixel (quando non nulle). Le dimensioni in pixel si riferiscono all'area disegnabile della finestra.
I parametri di dimensione sono puramente informativi.
Il client DOVREBBE ignorare le richieste pty.
6.3. X11 Forwarding (Inoltro X11)
6.3.1. Requesting X11 Forwarding
L'inoltro X11 può essere richiesto per una sessione inviando un messaggio 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
È RACCOMANDATO che il x11 authentication cookie inviato sia un cookie falso casuale e che il cookie venga verificato e sostituito con il cookie reale al ricevimento di una richiesta di connessione.
L'inoltro delle connessioni X11 dovrebbe interrompersi quando il canale di sessione viene chiuso. Tuttavia, le connessioni già aperte non dovrebbero essere chiuse automaticamente alla chiusura del canale di sessione.
Se single connection è TRUE, dovrebbe essere inoltrata una sola connessione. Non verrà inoltrata alcuna connessione aggiuntiva dopo la prima o dopo la chiusura del canale di sessione.
Il x11 authentication protocol è il nome del metodo di autenticazione X11 utilizzato, ad esempio "MIT-MAGIC-COOKIE-1".
Il x11 authentication cookie DEVE essere codificato in esadecimale.
Il protocollo X è documentato in [SCHEIFLER].
6.3.2. X11 Channels
I canali X11 vengono aperti con una richiesta di apertura di canale. I canali risultanti sono indipendenti dalla sessione e la chiusura del canale di sessione non chiude i canali X11 inoltrati.
byte SSH_MSG_CHANNEL_OPEN
string "x11"
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
string originator address (es., "192.168.7.38")
uint32 originator port
Il destinatario dovrebbe rispondere con SSH_MSG_CHANNEL_OPEN_CONFIRMATION o SSH_MSG_CHANNEL_OPEN_FAILURE.
Le implementazioni DEVONO rifiutare qualsiasi richiesta di apertura di canale X11 se non hanno richiesto un inoltro X11.
6.4. Environment Variable Passing (Passaggio di variabili d'ambiente)
Variabili d'ambiente possono essere passate alla shell/comando da avviare successivamente. L'impostazione non controllata di variabili d'ambiente in un processo privilegiato può essere un rischio per la sicurezza. Si raccomanda che le implementazioni mantengano un elenco di nomi di variabili consentiti o che impostino le variabili d'ambiente solo dopo che il processo server ha rinunciato a privilegi sufficienti.
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 (Avvio di una shell o di un comando)
Una volta configurata la sessione, un programma viene avviato all'estremità remota. Il programma può essere una shell, un programma applicativo o un sottosistema con un nome indipendente dall'host. Una sola di queste richieste può avere successo per canale.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "shell"
boolean want reply
Questo messaggio richiederà l'avvio della shell predefinita dell'utente (in genere definita in /etc/passwd sui sistemi UNIX) all'altra estremità.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "exec"
boolean want reply
string command
Questo messaggio richiederà al server di avviare l'esecuzione del comando indicato. La stringa command può contenere un percorso. Devono essere adottate le consuete precauzioni per impedire l'esecuzione di comandi non autorizzati.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "subsystem"
boolean want reply
string subsystem name
Quest'ultima forma esegue un sottosistema predefinito. È previsto che essi includano un meccanismo generale di trasferimento file e, eventualmente, altre funzionalità. Le implementazioni possono anche consentire la configurazione di ulteriori meccanismi di questo tipo. Poiché la shell dell'utente viene generalmente utilizzata per eseguire il sottosistema, si consiglia che il protocollo del sottosistema includa un "magic cookie" all'inizio della transazione di protocollo per distinguerlo da qualsiasi output arbitrario generato dagli script di inizializzazione della shell, ecc. Questo output spazzo della shell può essere filtrato sia a livello di server che a livello di client.
Il server NON DOVREBBE interrompere l'esecuzione dello stack di protocolli all'avvio di una shell o di un programma. Tutti gli input e gli output di questi DOVREBBERO essere reindirizzati al canale o al tunnel crittografato.
È RACCOMANDATO che la risposta a questi messaggi venga richiesta e verificata. Il client DOVREBBE ignorare questi messaggi.
I nomi dei sottosistemi seguono la convenzione di estensibilità DNS descritta in [SSH-NUMBERS].
6.6. Session Data Transfer (Trasferimento dati di sessione)
Il trasferimento dati per una sessione viene effettuato utilizzando i pacchetti SSH_MSG_CHANNEL_DATA e SSH_MSG_CHANNEL_EXTENDED_DATA e il meccanismo della finestra. Il tipo di dati estesi SSH_EXTENDED_DATA_STDERR è stato definito per i dati stderr.
6.7. Window Dimension Change Message (Messaggio di modifica delle dimensioni della finestra)
Quando la dimensione della finestra (terminale) cambia lato client, QUESTO PUÒ inviare un messaggio all'altra estremità per informarla delle nuove dimensioni.
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
Non dovrebbe essere inviata alcuna risposta a questo messaggio.
6.8. Local Flow Control (Controllo di flusso locale)
Su molti sistemi è possibile determinare se un pseudo-terminale utilizza il controllo di flusso control-S/control-Q. Quando il controllo di flusso è consentito, è spesso opportuno effettuare il controllo di flusso lato client per accelerare le risposte alle richieste dell'utente. Ciò è agevolato dalla notifica seguente. Inizialmente, il server è responsabile del controllo di flusso. (Anche qui, client indica l'estremità che ha originato la sessione e server l'altra estremità.)
Il messaggio seguente viene utilizzato dal server per informare il client quando può o non può effettuare il controllo di flusso (gestione control-S/control-Q). Se client can do è TRUE, al client è consentito effettuare il controllo di flusso utilizzando control-S e control-Q. Il client PUÒ ignorare questo messaggio.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "xon-xoff"
boolean FALSE
boolean client can do
A questo messaggio non viene inviata alcuna risposta.
6.9. Signals (Segnali)
Un segnale può essere recapitato al processo/servizio remoto utilizzando il messaggio seguente. Alcuni sistemi potrebbero non implementare i segnali, nel qual caso DOVREBBERO ignorare questo messaggio.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "signal"
boolean FALSE
string signal name (senza il prefisso "SIG")
I valori signal name verranno codificati come indicato nel passaggio che descrive i messaggi SSH_MSG_CHANNEL_REQUEST che utilizzano "exit-signal" in questa sezione.
6.10. Returning Exit Status (Restituzione dello stato di uscita)
Quando il comando in esecuzione all'altra estremità termina, può essere inviato il messaggio seguente per restituire lo stato di uscita del comando. Si raccomanda di restituire lo stato. Non viene inviato alcun acknowledgment per questo messaggio. Il canale deve essere chiuso con SSH_MSG_CHANNEL_CLOSE dopo questo messaggio.
Il client PUÒ ignorare questi messaggi.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "exit-status"
boolean FALSE
uint32 exit_status
Il comando remoto può anche terminare bruscamente a causa di un segnale. Una tale condizione può essere indicata dal messaggio seguente. Uno exit_status nullo significa generalmente che il comando è terminato con successo.
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "exit-signal"
boolean FALSE
string signal name (senza il prefisso "SIG")
boolean core dumped
string error message in ISO-10646 UTF-8 encoding
string language tag [RFC3066]
Il signal name è uno dei seguenti (provengono da [POSIX]).
ABRT
ALRM
FPE
HUP
ILL
INT
KILL
PIPE
QUIT
SEGV
TERM
USR1
USR2
Possono essere inviati valori signal name aggiuntivi nel formato "sig-name@xyz", dove "sig-name" e "xyz" possono essere ciò che un implementatore particolare desidera (ad eccezione del segno "@"). Tuttavia, si suggerisce che, se viene utilizzato uno script configure, tutti i valori signal name non standard che esso trova vengano codificati nella forma "[email protected]", dove "SIG" è il signal name senza il prefisso "SIG" e "xyz" è il tipo di host, così come determinato da "config.guess".
Il error message contiene una spiegazione testuale aggiuntiva del messaggio di errore. Il messaggio può essere costituito da più righe separate da coppie CRLF (ritorno a capo - avanzamento di riga). Il software client PUÒ visualizzare questo messaggio all'utente. Se lo fa, il software client dovrebbe adottare le precauzioni descritte in [SSH-ARCH].