6. Interactive Sessions (対話セッション)

セッション (session) はプログラムのリモート実行である. プログラムはシェル, アプリケーション, システムコマンド, または組み込みサブシステムでもよい. tty の有無, X11 転送の有無は問わない. 複数のセッションを同時に有効にできる.

6.1. Opening a Session (セッションのオープン)

次のメッセージを送ってセッションを開始する.

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

クライアント実装はセッションチャネルのオープン要求をすべて拒否すべきであり, 悪意のあるサーバによる攻撃を困難にする.

6.2. Requesting a Pseudo-Terminal (擬似端末の要求)

次のメッセージによりセッションに擬似端末 (pseudo-terminal) を割り当てられる.

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

encoded terminal modes は第 8 節で述べる. 寸法パラメータがゼロのものは無視しなければならない. 文字/行の寸法は (非ゼロのとき) ピクセル寸法に優先する. ピクセル寸法はウィンドウの描画可能領域を指す.

寸法パラメータは情報提供のみである.

クライアントは pty 要求を無視すべきである.

6.3. X11 Forwarding (X11 転送)

6.3.1. Requesting X11 Forwarding

SSH_MSG_CHANNEL_REQUEST を送ることでセッションに X11 転送を要求できる.

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

送る x11 authentication cookie は偽のランダム cookie とし, 接続要求を受けたときに検証して本物に置き換えることが推奨される.

X11 接続転送はセッションチャネルが閉じたときに止めるべきである. ただし, すでに開いた転送をセッションチャネル閉鎖で自動的に閉じるべきではない.

single connection が TRUE の場合, 単一接続のみ転送すべきである. 最初の接続の後, またはセッションチャネル閉鎖後は, それ以上接続を転送しない.

x11 authentication protocol は用いる X11 認証方式の名前である (例: "MIT-MAGIC-COOKIE-1").

x11 authentication cookie は十六進で符号化しなければならない.

X プロトコルは [SCHEIFLER] を参照.

6.3.2. X11 Channels

X11 チャネルはチャネルオープン要求で開く. 得られたチャネルはセッションから独立しており, セッションチャネルを閉じても転送済み X11 チャネルは閉じない.

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

受信者は SSH_MSG_CHANNEL_OPEN_CONFIRMATION または SSH_MSG_CHANNEL_OPEN_FAILURE で応答すべきである.

X11 転送を要求していない実装は, X11 チャネルのオープン要求をすべて拒否しなければならない.

6.4. Environment Variable Passing (環境変数の受け渡し)

環境変数は後から起動するシェル/コマンドに渡してよい. 特権プロセスで環境変数を無制御に設定することはセキュリティ上危険であり, 実装は許可する変数名の一覧を維持するか, サーバプロセスが十分に特権を落とした後にのみ環境変数を設定することが推奨される.

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 (シェルまたはコマンドの開始)

セッションが確立されると, 遠隔側でプログラムが起動される. シェル, アプリ, ホスト非依存名のサブシステムのいずれかである. チャネルごとにこれらの要求のうち成功できるのは一つのみである.

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

このメッセージは, 他端でユーザのデフォルトシェル (UNIX では通常 /etc/passwd で定義) を起動することを要求する.

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

このメッセージはサーバに指定コマンドの実行開始を要求する. command 文字列にパスを含めてよい. 不正なコマンドの実行を防ぐため, 通常の注意が必要である.

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

最後の形式は定義済みサブシステムを実行する. 一般的なファイル転送機構などが想定される. 実装はこれに加える機構を設定で許可してもよい. ユーザのシェルでサブシステムを実行することが多いため, シェル初期化スクリプトなどの任意出力と区別するためにプロトコル冒頭に "magic cookie" を置くことが望ましい. シェルからの余分な出力はサーバまたはクライアントでフィルタしてよい.

シェルまたはプログラム起動時にサーバはプロトコルスタックの実行を止めてはならない. 入出力はチャネルまたは暗号化トンネルへリダイレクトすべきである.

これらのメッセージには応答を要求し検査することが推奨される. クライアントは (受信側として) これらのメッセージを無視すべきである.

サブシステム名は [SSH-NUMBERS] の DNS 拡張命名規則に従う.

6.6. Session Data Transfer (セッションデータ転送)

セッションのデータ転送は SSH_MSG_CHANNEL_DATA と SSH_MSG_CHANNEL_EXTENDED_DATA パケットおよびウィンドウ機構で行う. stderr には拡張データ型 SSH_EXTENDED_DATA_STDERR が定義されている.

6.7. Window Dimension Change Message (ウィンドウ寸法変更メッセージ)

クライアント側のウィンドウ (端末) サイズが変わったとき, 新しい寸法を知らせるメッセージを送ってよい.

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

このメッセージに応答を送るべきではない.

6.8. Local Flow Control (ローカルフロー制御)

多くのシステムでは擬似端末が control-S/control-Q フロー制御を使うか判定できる. フロー制御が許される場合, ユーザ要求への応答を速めるためにクライアント側でフロー制御することが望ましいことが多い. 次の通知がそれを可能にする. 最初はサーバがフロー制御を担当する (ここでクライアントはセッションを始めた側, サーバはもう一方).

次のメッセージはサーバがクライアントに, フロー制御 (control-S/control-Q 処理) を実行できるか否かを知らせるために用いる. client can do が TRUE なら, クライアントは control-S と control-Q でフロー制御してよい. クライアントはこのメッセージを無視してよい.

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

このメッセージには応答を送らない.

6.9. Signals (シグナル)

次のメッセージで遠隔プロセス/サービスにシグナルを届けられる. シグナルを実装しないシステムではこのメッセージを無視すべきである.

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

signal name の符号化は, 本節後半の exit-signal を用いる SSH_MSG_CHANNEL_REQUEST の説明に従う.

6.10. Returning Exit Status (終了ステータスの返却)

他端のコマンドが終了すると, 次のメッセージで終了ステータスを返してよい. ステータスを返すことが推奨される. このメッセージに確認はない. このメッセージの後は SSH_MSG_CHANNEL_CLOSE でチャネルを閉じる必要がある.

クライアントはこれらのメッセージを無視してよい.

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

コマンドはシグナルで異常終了することもある. 次のメッセージで示せる. exit_status がゼロは通常成功終了を意味する.

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]

signal name は次のいずれかである ([POSIX] より):

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

追加の signal name は "sig-name@xyz" 形式で送ってよい ("sig-name" と "xyz" は実装者の任意, "@" を除く). ただし configure スクリプトを使う場合, 非標準名は "[email protected]" と符号化することが提案される. "SIG" は "SIG" 接頭辞なしのシグナル名, "xyz" は "config.guess" で決まるホスト種別である.

error message はエラーの追加説明である. CRLF (キャリッジリターンとラインフィード) で区切られた複数行でもよい. クライアントはユーザーに表示してよい. その場合 [SSH-ARCH] の注意に従うこと.