Network Working Group T. Ylonen Request for Comments: 4254 SSH Communications Security Corp Category: Standards Track C. Lonvick, Ed. Cisco Systems, Inc. January 2006 セキュアシェル（SSH）接続プロトコル このメモの位置づけ この文書は, インターネットコミュニティに対するインターネットの標準トラックプロトコルを定義している. また, 改善のための議論と示唆を求めている. このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards" (STD 1) の現在の版を参照してほしい. このメモの配布は制限しない. 著作権情報 Copyright (C) The Internet Society (2006). 訳者: 春山 征吾 . 概要 セキュアシェル (SSH) は, 安全ではないネットワーク上での安全なリモートログインや他の安全なネットワークサービスのためのプロトコルだ. この文書は, SSH コネクションプロトコルについて記述する. このプロトコルは, インタラクティブなログインセッション, コマンドのリモート実行, TCP/IP接続の転送, X11接続の転送を提供する. これらのチャンネルすべては, 単一の暗号化されたトンネルに多重化される. SSH コネクションプロトコルは, SSH トランスポート層・ユーザ認証プロトコル上で動作するように設計されている. Ylonen & Lonvick Standards Track [Page 1] RFC 4254 SSH Connection Protocol January 2006 目次 1イントロダクション ..........................................2 2. Contributors ....................................................3 3. Conventions Used in This Document ...............................3 4. Global Requests .................................................4 5. Channel Mechanism ...............................................5 5.1. Opening a Channel ..........................................5 5.2. Data Transfer ..............................................7 5.3. Closing a Channel ..........................................9 5.4. Channel-Specific Requests ..................................9 6. Interactive Sessions ...........................................10 6.1. Opening a Session .........................................10 6.2. Requesting a Pseudo-Terminal ..............................11 6.3. X11 Forwarding ............................................11 6.3.1. Requesting X11 Forwarding ..........................11 6.3.2. X11 Channels .......................................12 6.4. Environment Variable Passing ..............................12 6.5. Starting a Shell or a Command .............................13 6.6. Session Data Transfer .....................................14 6.7. Window Dimension Change Message ...........................14 6.8. Local Flow Control ........................................14 6.9. Signals ...................................................15 6.10. Returning Exit Status ....................................15 7. TCP/IP Port Forwarding .........................................16 7.1. Requesting Port Forwarding ................................16 7.2. TCP/IP Forwarding Channels ................................18 8. Encoding of Terminal Modes .....................................19 9. Summary of Message Numbers .....................................21 10. IANA Considerations ...........................................21 11. Security Considerations .......................................21 12. References ....................................................22 12.1. Normative References .....................................22 12.2. Informative References ...................................22 Authors' Addresses ................................................23 Trademark Notice ..................................................23 1イントロダクション SSH コネクションプロトコルは, SSH トランスポート層・ユーザ認証プロトコル上で動作するように設計されている([SSH-TRANS] と [SSH-USERAUTH]). このプロトコルは, インタラクティブなログインセッション, コマンドのリモート実行, TCP/IP接続の転送, X11接続の転送を提供する. このプロトコルの 'service name' は, "ssh-connection" だ. Ylonen & Lonvick Standards Track [Page 2] RFC 4254 SSH Connection Protocol January 2006 この文書は, SSHアーキテクチャ文書 [SSH-ARCH]を読んだあとに読むべきだ. この文書は, 参照や説明なしにアーキテクチャ文書から用語や表記法を自由に利用する. 2. Contributors The major original contributors of this set of documents have been: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications Security Corp), and Markku-Juhani O. Saarinen (University of Jyvaskyla). Darren Moffat was the original editor of this set of documents and also made very substantial contributions. Many people contributed to the development of this document over the years. People who should be acknowledged include Mats Andersson, Ben Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller, Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and Tadayoshi Kohno. Listing their names here does not mean that they endorse this document, but that they have contributed to it. 3. この文書で用いる表記 All documents related to the SSH protocols shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe requirements. These keywords are to be interpreted as described in [RFC2119]. The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC2434]. プロトコルのフィールドとフィールドで取り得る値は , この文書群で定義される. メッセージの定義で, プロトコルのフィールドは定義される. 例として, SSH_MSG_CHANNEL_DATA を次で定義する byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data Ylonen & Lonvick Standards Track [Page 3] RFC 4254 SSH Connection Protocol January 2006 この文書群では, フィールドが参照される場合には, シングルクォートで囲まれて表記される. フィールドに入る値が参照される場合は, ダブルクォートで囲まれて表記される. 上の例を用いると, 'data' の取り得る値には, "foo" や "bar" がある. 4. 全体的な要求 リモートの状態に全体的に(チャンネルとは独立に)影響する要求がいくつかある. 例を挙げると, 特定のポートに対するTCP/IP転送の開始の要求だ. クライアントもサーバもいつでも全体的な要求を送ってよく受け取り手は適切に返答しなければならないことに注意. それらの要求はすべて次のフォーマットに従う. byte SSH_MSG_GLOBAL_REQUEST string request name in US-ASCII only boolean want reply .... 要求特有のデータが続く. 'request name' の値は, [SSH-ARCH] で説明されているDNS 拡張命名規則に従う. 受け取り手はこのメッセージに対して, SSH_MSG_REQUEST_SUCCESS か, 'want_reply' が TRUE の SSH_MSG_REQUEST_FAILURE で返答する. byte SSH_MSG_REQUEST_SUCCESS .... response specific data 通常, 'response specific data' は存在しない. 受け取り手が要求を理解しなかったりサポートしない場合は, 単にSSH_MSG_REQUEST_FAILURE を返す. byte SSH_MSG_REQUEST_FAILURE 一般に, この返答メッセージは要求の種類の識別子を含まない. 要求を開始した側がどの要求を参照してるかを識別するのを可能にするために,SSH_MSG_GLOBAL_REQUESTS の返答は, 関連する要求のメッセージと同じ順番で送られなければならないことが要求されている. チャンネルの要求でも, 同じチャンネルに関係する応答は正しい順番でなされなければならない. しかし, 別のチャンネルに対する要求には, 順番が入れ変って返答されてもよい. Ylonen & Lonvick Standards Track [Page 4] RFC 4254 SSH Connection Protocol January 2006 5. チャンネルのメカニズム すべてのターミナルのセッション, 転送された接続などは, チャンネルだ. どちらの側からもチャンネルを開ける. 複数のチャンネルは, 単一の接続に多重化される. チャンネルは両方の側で番号によって識別される. チャンネルを示す番号は, それぞれの側で異なることがある. チャンネルを開始する要求は, 送り手のチャンネル番号を含む. それ以外のチャンネルに関するメッセージは, そのチャンネルの受け取り手のチャンネル番号を含む. チャンネルはフロー制御される. window のスペースがあることを示すメッセージが受けとられるまで, チャンネルにはデータは送られない. 5.1. チャンネルの開始 一方の側がチャンネルを開始したい時, チャンネルに対してローカルな番号を割り当てる. 次のメッセージを相手側に送る. メッセージにはローカルなチャンネル番号と初期 window サイズ が含まれる. byte SSH_MSG_CHANNEL_OPEN string channel type in US-ASCII only uint32 sender channel uint32 initial window size uint32 maximum packet size .... channel type が後に続くデータを指定する. 'channel type' は名前で, [SSH-ARCH] と [SSH-NUMBERS] に記述されたような拡張のメカニズムを持つ. 'sender channel' は, このメッセージの送り手が使うチャンネルのローカルな識別子だ. 'initial window size'は, チャンネルのデータをこのメッセージの送り手にwindow の調整なしで送れる byte 数を指定する. 'maximum packet size' は, 送り手に送ることができる1つのデータパケットの最大サイズを指定する. たとえば, 遅い回線でよりよいインタラクティブな返答を得るために, インタラクティブな接続で一方の側がより小さいパケットを用いるように求める場合がある. リモート側はチャンネルを開始するかどうかを決定する. そして SSH_MSG_CHANNEL_OPEN_CONFIRMATION か SSH_MSG_CHANNEL_OPEN_FAILURE で返答する. Ylonen & Lonvick Standards Track [Page 5] RFC 4254 SSH Connection Protocol January 2006 byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION uint32 recipient channel uint32 sender channel uint32 initial window size uint32 maximum packet size .... channel type が後に続くデータを指定する. 'recipient channel' は, 元の開始要求で与えられたチャンネル番号だ. 'sender channel' は相手側で割り当てられたチャンネル番号だ. byte SSH_MSG_CHANNEL_OPEN_FAILURE uint32 recipient channel uint32 reason code string description in ISO-10646 UTF-8 encoding [RFC3629] string language tag [RFC3066] SSH_MSG_CHANNEL_OPEN メッセージの受け取り手が 指定された 'channel type' をサポートしていないなら, SSH_MSG_CHANNEL_OPEN_FAILURE で単純に返答する. クライアントは, 'description' 文字列をユーザに表示してもよい. もし表示するなら, クライアントソフトウェアは, [SSH-ARCH]で議論した予防措置を取らなければならない. SSH_MSG_CHANNEL_OPEN_FAILURE の 'reason code' の値は, 次の表で定義される. 'reason code' は読み易いように10進のフォーマットで書かれているが, 実際にはuint32の値であることに注意. Symbolic name reason code ------------- ----------- SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1 SSH_OPEN_CONNECT_FAILED 2 SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3 SSH_OPEN_RESOURCE_SHORTAGE 4 新しいSSH_MSG_CHANNEL_OPENの 'reason code' の値(と関連する 'description' テキスト) を割り当てる要求は, 0x00000005 から 0xFDFFFFFF の範囲については [RFC2434] に記述されている IETF CONSENSUS におってされなければならない. IANAは, 0xFE000000 から 0xFFFFFFFF の範囲のチャンネル接続失敗の'reason code' の値は割り当てない. この範囲のチャンネル接続失敗の 'reason code'の値は, [RFC2434]に記述されている プライベートな利用 (PRIVATE USE) に予約されている. 0xFE000000 to 0xFFFFFFFF の範囲についてはIANAはなんの制御もしないが, この範囲は次の規約に従って2つの部分に分割されて管理される. Ylonen & Lonvick Standards Track [Page 6] RFC 4254 SSH Connection Protocol January 2006 o 0xFE000000 から 0xFEFFFFFF の範囲は, ローカルに割り当てられたチャンネルと共に利用されるためにある. たとえば,"example_session@example.com" という 'channel type' のチャンネルが提案されたが失敗したとき, レスポンスには, (前述ないし0x00000001 から 0xFDFFFFFFの範囲の) IANA で割り当てられた 'reason code'が含まれるか, 0xFE000000 から 0xFEFFFFFF の埴のローカルに割り当てられた値を'reason code' が含まれる. もちろん, サーバが提案された 'channel type' を理解できない場合は, それがローカルに定義された 'channel type' であっても, 'reason code' は 前述した0x00000003 でなければならない. サーバが 'channel type' を理解するがチャンネルの開始に失敗するなら, サーバは提案されたローカルな 'channel type' に対応するローカルに割り当てられた値を返す必要がある. 実行する者が, まずIANAで割り当てられた 'reason code' を利用しようとし, その次にローカルに割り当てられた 'reason code' を利用しようとすることを前提としている. o 0xFFで始まる範囲については, 制限や示唆はない. この範囲を利用する際は, 相互運用性は期待されない. 基本的に, この範囲は実験のためにある. 5.2. データ転送 window size は, windowが調整されるまでに相手側が送ることのできるバイト数を指定する. どちらの側も次のメッセージで window を調整できる. byte SSH_MSG_CHANNEL_WINDOW_ADJUST uint32 recipient channel uint32 bytes to add このメッセージを受け取ったら, 受け取り手は以前送ることを許可されていたものよりも指定されただけ大きいbyte数を送ってもよい; window size が増加する. 実装は, 2^32 -1 byteまでのwindow size を正しく扱えなければならない. 2＾32 - 1 byte を越えて window が拡大されることはない. データの転送は次の種類のメッセージで行なわれる. byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data 許されるデータの最大量は, チャンネルの最大 packet size と現在の window size の小さいほうで決定される. window size は, 転送されたデータ量だけ減少する. 許される window が空になったあとで転送されたすべての余分なデータは, どちらの側も無視してもよい. Ylonen & Lonvick Standards Track [Page 7] RFC 4254 SSH Connection Protocol January 2006 実装には, SSH トランスポート層の packet size に制限があることを期待される (packet の受信のためのどのような制限も, [SSH-TRANS]に記述されているように, 32768 byte 以上でなければならない.). SSH コネクション層の実装は o トランスポート層が受信できるよりも大きなトランスポート packet になる最大 packet size を告知してはならない. o トランスポート層が送れるものよりも大きな data packet を生成してはならない. たとえ, リモート側が非常に大きな packet を受けとりたい場合でもだ. 加えて, いくつかのデータの種類を転送するチャンネルがある. この例として, インタラクティブなセッションからの stderr データがある. このようなデータは, SSH_MSG_CHANNEL_EXTENDED_DATA メッセージによって転送される. ここで異なる integer によってデータの種類を指定する. 利用できる種類とその解釈は, チャンネルの種類に依存する. byte SSH_MSG_CHANNEL_EXTENDED_DATA uint32 recipient channel uint32 data_type_code string data このメッセージで送られたデータは, 通常のデータと同じ window を消費する. 現在, 次の種類だけが定義されている. 'data_type_code' は読み易いように10進のフォーマットで書かれているが, 実際にはuint32の値であることに注意. Symbolic name data_type_code ------------- -------------- SSH_EXTENDED_DATA_STDERR 1 拡張チャンネルデータ転送の 'data_type_code' の値は, 連続して割り当てられなければならない. 拡張チャンネルデータ転送の 'data_type_code' の値と関連する拡張チャンネルデータ転送の 'data' を割り当てる要求は, 0x00000002 から 0xFDFFFFFF の範囲については [RFC2434] に記述されている IETF CONSENSUS によってされなければならない. IANAは, 0xFE000000 から 0xFFFFFFFF の範囲の 拡張チャンネルデータ転送の 'data_type_code' の値は割り当てない. この範囲の拡張チャンネルデータ転送の 'data_type_code'の値は, [RFC2434]に記述されている プライベートな利用 (PRIVATE USE) に予約されている. IANA への実際の指示は [SSH-NUMBERS] にあることに注意. Ylonen & Lonvick Standards Track [Page 8] RFC 4254 SSH Connection Protocol January 2006 5.3. チャンネルの終了 チャンネルにもうこれ以上データを送らないなら, SSH_MSG_CHANNEL_EOF を送る必要がある. byte SSH_MSG_CHANNEL_EOF uint32 recipient channel このメッセージに明示的な返答は送られない. しかし, チャンネルの相手側が終了したときに, アプリケーションが EOF を送るかもしれない. このメッセージのあともチャンネルは開かれた状態で残り, 逆の方向でさらなるデータが送られるかもしれないことに注意. このメッセージは, window space を消費しない. window space が残っていない場合にも送ることができる. どちらかの側がチャンネルを終了したいと望むなら, SSH_MSG_CHANNEL_CLOSE を送る. まだこのメッセージを送信していないのにこのメッセージを受信した側は, SSH_MSG_CHANNEL_CLOSE を送り返さなければならない. どちらの側もSSH_MSG_CHANNEL_CLOSE を送受信したらチャンネルは終了したと見なされる. この後でチャンネル番号は再利用されるかもしれない. SSH_MSG_CHANNEL_EOF を送信ないし受信せずに SSH_MSG_CHANNEL_CLOSE を送ってよい. byte SSH_MSG_CHANNEL_CLOSE uint32 recipient channel このメッセージは, window space を消費しない. window space が残っていない場合にも送ることができる. 可能ならば, このメッセージの前に送られたすべてのデータが正しい送り先に伝達されることが推奨される. 5.4. チャンネル特有の要求 多くの 'channel type' の値が, 特定の 'channel type' に特有の拡張を持つ. 例に, インタラクティブなセッションでの pty (擬似ターミナル)の要求がある. すべてのチャンネル特有の要求は次の形式を用いる. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string request type in US-ASCII characters only boolean want reply .... タイプに特有のデータが続く. Ylonen & Lonvick Standards Track [Page 9] RFC 4254 SSH Connection Protocol January 2006 'want reply' が FALSE なら, 要求に対する返答は送られない. そうでなければ, 受け取り手は SSH_MSG_CHANNEL_SUCCESS ないし SSH_MSG_CHANNEL_FAILURE, もしくは 要求特有の継続メッセージを返す. 要求が理解できなかったりチャンネルでサポートされていない場合は, SSH_MSG_CHANNEL_FAILURE を返す. このメッセージは, window space を消費しない. window space が残っていない場合にも送ることができる. 'request type' の値は それぞれの channel type に局所的だ. クライアントは, リクエストに対する返答を待つことなくさらなるメッセージを送ってもよい. 'request type' の値は, [SSH-ARCH] と [SSH-NUMBERS] で説明されている DNS 拡張命名規則に従う. byte SSH_MSG_CHANNEL_SUCCESS uint32 recipient channel byte SSH_MSG_CHANNEL_FAILURE uint32 recipient channel これらメッセージは, window space を消費しない. window space が残っていない場合にも送ることができる. 6. インタラクティブなセッション セッションは, プログラムのリモートな実行だ. このプログラムは, シェルやアプリケーションやシステムのコマンドや組み込まれたサブシステムだ. このプログラムは, ttyを持つかもしれないし持たないかもしれない. また, X11の転送を起動するかもしれないししないかもしれない. 複数のセッションが同時に有効になりうる. 6.1. セッションの開始 セッションは, 次のメッセージを送ることで開始される. byte SSH_MSG_CHANNEL_OPEN string "session" uint32 sender channel uint32 initial window size uint32 maximum packet size クライアントの実装は, どんなセッションチャンネルの開始要求も拒否する必要がある. 邪悪なサーバがクライアントを攻撃するのをより難しくするためだ. Ylonen & Lonvick Standards Track [Page 10] RFC 4254 SSH Connection Protocol January 2006 6.2. 擬似ターミナルの要求 次のメッセージを送ることで, 擬似ターミナルがセッションに割り当てられる. 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節で記述する. 次元パラメータが0の場合は無視されなければならない. 0以外の character/row 次元パラメータは, pixel 次元を上書きする. pixel 次元は, ウィンドウの描画可能領域を参照する. 次元パラメータは, 単に情報を提供するだけだ. クライアントは, pty 要求を無視する必要がある. 6.3. X11 の転送 6.3.1. X11 転送の要求 X11の転送は, セッションに 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 送られる 'x11 authentication cookie' は, にせ物のランダムなクッキーで, 接続要求が受け入れられた際にそのクッキーをチェックし置き換えることが推奨される. X11 接続の転送は, セッションのチャンネルが終了したら停止されるべきだ. しかし, すでに開始されている転送は, セッションが終了されても自動的には終了されないべきだ. Ylonen & Lonvick Standards Track [Page 11] RFC 4254 SSH Connection Protocol January 2006 'single connection' が TRUE なら, 単一の接続のみが転送されるべきだ. 最初のもの以降ないしセッションチャンネルの終了以降に, 接続が転送されることはない. 'x11 authentication protocol' は, 利用するX11の認証法の名前だ. 例, "MIT-MAGIC-COOKIE-1". 'x11 authentication cookie' は 16進にエンコードされなければならない. X のプロトコルは, [SCHEIFLER] に記述されている. 6.3.2. X11 のチャンネル 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. 環境変数の転送 後で開始されるシェルやコマンドに, 環境変数を転送できる. 特権を持つプロセスで環境変数の設定を制御しないと, セキュリティの危険となりうる. 許可する変数名のリストを管理するかサーバプロセスが十分な権限を落したあとで環境変数を設定するかのどちらかにすることが, 実装には推奨される. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "env" boolean want reply string variable name string variable value Ylonen & Lonvick Standards Track [Page 12] RFC 4254 SSH Connection Protocol January 2006 6.5. シェルないしコマンドの起動 セッションが設定されると, プログラムがリモート側で起動される. このプログラムは, シェルでも, アプリケーションでも, ホストに依存しない名前を持つサブシステムでもよい. これらの要求のうち, チャンネルごとに1つだけが成功する. 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"を持つことが望ましい. シェルからの誤った出力は, サーバないしクライアントのどちらかでフィルタされうる. サーバは, シェルやプログラムの起動時にプロトコルスタックの実行を停止しないほうがよい. シェルやプログラムからのすべての入力と出力は, チャンネルか暗号化されたトンネルにリダイレクトされる必要がある. これらのメッセージに対する返答は要求され検査されることが推奨される. クライアントはこれらのメッセージを無視する必要がある. Ylonen & Lonvick Standards Track [Page 13] RFC 4254 SSH Connection Protocol January 2006 サブシステムの名前は, [SSH-NUMBERS] で説明されている DNS 拡張命名規則に従う. 6.6. セッションのデータ転送 セッションのデータ転送は, SSH_MSG_CHANNEL_DATA とSSH_MSG_CHANNEL_EXTENDED_DATA パケットと ウィンドウメカニズムを用いて行なわれる. 拡張データタイプ SSH_EXTENDED_DATA_STDERR が標準エラー出力のために定義されている. 6.7. ウィンドウ容量変更メッセージ ウィンドウ (ターミナル) サイズがクライアント側で変更する場合, 新しい容量を相手側に知らせるために次のメッセージを送ってもよい. 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. ローカルなフロー制御 多くのシステムで, 擬似ターミナルが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 このメッセージには応答は送られない. Ylonen & Lonvick Standards Track [Page 14] RFC 4254 SSH Connection Protocol January 2006 6.9. シグナル 次のメッセージを用いてリモートのプロセス/サービスにシグナルが伝達される. シグナルを実装していないシステムの場合は, このメッセージは無視される必要がある. 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. 終了ステータスの返却 相手側で動作していたコマンドが終了すると, コマンドの終了ステータスを返却するために次のメッセージが送られる. ステータスを返すことは推奨されている. このメッセージには応答は返らない. このメッセージの後の 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] Ylonen & Lonvick Standards Track [Page 15] RFC 4254 SSH Connection Protocol January 2006 'signal name' は次のうちの1つだ (これらは [POSIX] による). ABRT ALRM FPE HUP ILL INT KILL PIPE QUIT SEGV TERM USR1 USR2 追加の 'signal name' の値が, フォーマット "sig-name@xyz" で送られてもよい. ここで "sig-name" と "xyz" は, ("@" を除く)実装者が望むどんな文字列でもよい. しかし, 'configure' スクリプトが使われるなら, どんな非標準の 'signal name' の値も "SIG@xyz.config.guess" という形式でエンコードされることが推奨される. ここで, "SIG" は SIG接頭辞を除いた 'signal name' で "xyz" は "config.guess" で決定されるホストタイプだ. 'error message' は, 追加のエラーメッセージのテキストでの説明が含まれる. このメッセージは, CRLF (キャリッジリターン - ラインフィード) のペアで分割された複数行を含むかもしれない. クライアントソフトウェアは, ユーザにこのメッセージを表示してもよい. もし表示するなら, クライアントソフトウェアは, [SSH-ARCH]で議論した予防措置を取らなければならない. 7. TCP/IP ポート転送 7.1. ポート転送の要求 自身のポートを相手側に転送する場合は要求を明示的にする必要はない. しかし, 相手側のポートへの接続をローカル側に転送したいと望むならば明示的に要求しなければならない. byte SSH_MSG_GLOBAL_REQUEST string "tcpip-forward" boolean want reply string address to bind (e.g., "0.0.0.0") uint32 port number to bind Ylonen & Lonvick Standards Track [Page 16] RFC 4254 SSH Connection Protocol January 2006 'address to bind' と 'port number to bind' は, 転送のための接続が受け入れる IPアドレス(ないしドメイン名) とポートを指定する. 'address to bind' には, 特別な意味を持つ文字列がいくつか使われる. o ""' は, SSHの実装がサポートするすべてのプロトコルファミリで接続を受け入れることを意味する o "0.0.0.0" は, すべてのIPv4アドレスで受け入れることを意味する. o "::" は, すべてのIPv6アドレスで受け入れることを意味する. o "localhost" は, SSHの実装がサポートするすべてのプロトコルファミリでループバックのアドレスでだけ受け入れることを意味する. ([RFC3330] and [RFC3513]). o "127.0.0.1" と "::1" は, それぞれ IPv4とIPv6のループバックインタフェイスで受け入れることを意味する.i クライアントがこのオープンな要求で送られた接続の情報をさらにフィルタすることがあるのに注意. 実装は, ユーザが特権ユーザとして認証されている場合にのみ特権ポートの転送を許すようにする必要がある. クライアントの実装は, これらのメッセージを拒否する必要がある. これらは通常クライアントからのみ送られる. クライアントが port number to bind として 0を 'want reply' として TRUE を指定した場合, サーバは次に利用可能な特権ポートではないポートを割り当て次のメッセージで返信する. 割り当てなければ返信しない. response-specific data. byte SSH_MSG_REQUEST_SUCCESS uint32 port that was bound on the server ポート転送は次のメッセージでキャンセルできる. チャンネルの開始の要求がこのメッセージが受信されるより前に受信されるかもしれないことに注意. byte SSH_MSG_GLOBAL_REQUEST string "cancel-tcpip-forward" boolean want reply string address_to_bind (e.g., "127.0.0.1") uint32 port number to bind クライアントの実装は, これらのメッセージを拒否する必要がある. これらは通常クライアントからのみ送られる. Ylonen & Lonvick Standards Track [Page 17] RFC 4254 SSH Connection Protocol January 2006 7.2. TCP/IP転送チャンネル リモートへの転送が要求されたポートに接続が来ると, 相手側のポートに転送をするチャンネルが開かれる. byte SSH_MSG_CHANNEL_OPEN string "forwarded-tcpip" uint32 sender channel uint32 initial window size uint32 maximum packet size string address that was connected uint32 port that was connected string originator IP address uint32 originator port 実装は, このポート番号でのリモートのTCP/IPポート転送を先に要求していなければ, このメッセージを拒否しなければならない. 接続がローカルに転送されたTCP/IPポートに来ると, 次のパケットが相手側に送られる. このメッセージは, ポートに対する転送が明示的に要求されることなく送られてもよいことに注意. 受信した側は転送を受け入れるか決めなければならない. byte SSH_MSG_CHANNEL_OPEN string "direct-tcpip" uint32 sender channel uint32 initial window size uint32 maximum packet size string host to connect uint32 port to connect string originator IP address uint32 originator port 'host to connect' と 'port to connect' は, 受信側がチャンネルに接続する TCP/IP ホストとポートを指定する. 'host to connect' は ドメイン名か数値のIPアドレスだ. 'originator IP address' は, 接続要求が開始されたマシンの数値のIPアドレスだ. 'originator port' は, 接続が開始されたホストのポートだ. 転送されたTCP/IPチャンネルは他のセッションとは独立だ. またセッションチャンネルが終了しても, 転送された接続が閉じられることを意味しない. Ylonen & Lonvick Standards Track [Page 18] RFC 4254 SSH Connection Protocol January 2006 クライアントの実装は, セキュリティ上の理由により direct TCP/IP の開始要求を拒否する必要がある. 8. ターミナルモードのエンコーディング (ptyの要求で渡される)すべての 'encoded terminal modes' は, バイトストリームへエンコードされている. これは, 異なる環境間でコードをポータブルにするためだ. ストリームは, opcodeがバイトの値である opcode-argumentのペアで構成される. Opcode の 1 から 159 までは単一のuint32の引数を持つOpcode の 160 から 255 までは, まだ定義されていない. これを受けとった側はパースを停止する(これらは他のデータの後でのみ利用される必要がある). ストリームは, opcode TTY_OP_END (0x00) で終わる. クラアイントは, 知っているすべてのモードをストリームに加える必要がある. サーバは, 知らないモードを無視してもよい. 少なくともPOSIX風のttyインタフェイスを利用するシステム間では, マシンに依存する部分があってよい. このプロトコルは, 他のシステムも同様にサポートできる. ただし, サーバのptyが適切なモードを設定できるように, クライアントはいくつかのパラメータを適切に設定する必要があるだろう ( サーバはすべての指定されていないモードのビットをデフォルト値のまま残すので, いくつかの組合せだけが意味を成す) opcode 値の名前は, POSIX 端末モードのフラグにだいたい従っている. 次の opcode 値が定義されている. 以下で示す値は, 読み易いように10進のフォーマットで書かれているが. 実際には byte の値であることに注意. オペコード mnemonic 説明 ------ -------- ----------- 0 TTY_OP_END オプションの終りを示す. 1 VINTR 割り込み文字. もしなければ255. 他の文字についても同様. これらの文字すべてが, すべてのシステムでサポートされているわけではない. 2 VQUIT 終了文字(POSIX シテムでは, SIGQUITを送る). 3 VERASE カーソルの左側の文字を消す. 4 VKILL 現在の入力行を消す. 5 VEOF End-of-file 文字 (ターミナルからEOFを送る). 6 VEOL キャリッジリターンと/もしくはラインフィードに追加される End-of-line 文字 7 VEOL2 追加の end-of-line 文字. 8 VSTART 中断した出力を再開する(通常は control-Q). 9 VSTOP 出力を中断する. (通常は control-S). 10 VSUSP 現在のプログラムを中断する. 11 VDSUSP 別の中断文字. Ylonen & Lonvick Standards Track [Page 19] RFC 4254 SSH Connection Protocol January 2006 12 VREPRINT 現在の入力行を再表示する. 13 VWERASE カーソルの左の word を消す. 14 VLNEXT 次に入力される文字が特別な文字だったとしてもそのとおりに入力する. 15 VFLUSH 出力を flush する文字 16 VSWTCH 別の shell layer に切り替える. 17 VSTATUS システムのステータス行(負荷, コマンド, pidなど)を表示する. 18 VDISCARD 端末の出力をflushするかを切り替える. 30 IGNPAR パリティ無視フラグ. FALSEならパラメータを0に, TRUE なら 1 にする必要がある. 31 PARMRK パリティーとフレームのエラーをマークを追加する. 32 INPCK パリティエラーのチェックを有効にする. 33 ISTRIP 文字の8bit目を落す. 34 INLCR 入力でNLをCRに置き換える. 35 IGNCR 入力でCRを無視する. 36 ICRNL 入力でCRをNLに置き換える. 37 IUCLC 大文字を小文字に変換する. 38 IXON 出力のフロー制御を有効にする. 39 IXANY どの文字でもストップ後の再開を行なう. 40 IXOFF 入力のフロー制御を有効にする. 41 IMAXBEL 入力キューがいっぱいのときにベルを鳴らす. 50 ISIG INTR, QUIT, [D]SUSP シグナルを有効にする. 51 ICANON 入力行を正規化する. 52 XCASE (訳注: 小文字のみ有効な場合に)小文字の前に "\" を付けることで大文字の入出力を有効にする. 53 ECHO エコーを有効にする. 54 ECHOE 視覚的なerase文字 55 ECHOK 現在の行を捨てる Kill 文字 56 ECHONL ECHO が無効でも NL をエコーする. 57 NOFLSH 割り込みの後でflushしない. 58 TOSTOP バックグラウンドのジョブから出力があったらジョブを止める. 59 IEXTEN 拡張を有効にする. 60 ECHOCTL ＾文字付きでコントロール文字をエコーする. 61 ECHOKE 行の削除を視覚的に行なう. 62 PENDIN 中断した入力を再入力する. 70 OPOST 出力処理を有効にする. 71 OLCUC 小文字を大文字に変換する. 72 ONLCR NLをCR-NLに置き換える. 73 OCRNL 出力で, CRをNLに置き換える. 74 ONOCR 出力で, NLをCR-NLに置き換える. 75 ONLRET 出力で, NLがCRを実行する. Ylonen & Lonvick Standards Track [Page 20] RFC 4254 SSH Connection Protocol January 2006 90 CS7 7 bit モード. 91 CS8 8 bit モード. 92 PARENB パリティ有効 93 PARODD 設定されると奇数パリティ. そうでなければ偶数パリティ 128 TTY_OP_ISPEED bit/秒単位で入力バンドレートを指定する. 129 TTY_OP_OSPEED bit/秒単位で出力バンドレートを指定する. 9. メッセージ番号のまとめ メッセージのまとめと関連するメッセージ番号を次に示す. SSH_MSG_GLOBAL_REQUEST 80 SSH_MSG_REQUEST_SUCCESS 81 SSH_MSG_REQUEST_FAILURE 82 SSH_MSG_CHANNEL_OPEN 90 SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 SSH_MSG_CHANNEL_OPEN_FAILURE 92 SSH_MSG_CHANNEL_WINDOW_ADJUST 93 SSH_MSG_CHANNEL_DATA 94 SSH_MSG_CHANNEL_EXTENDED_DATA 95 SSH_MSG_CHANNEL_EOF 96 SSH_MSG_CHANNEL_CLOSE 97 SSH_MSG_CHANNEL_REQUEST 98 SSH_MSG_CHANNEL_SUCCESS 99 SSH_MSG_CHANNEL_FAILURE 100 10. IANA の考慮 この文書は, (訳注: プロトコルを定義する文書の)集合の一部分だ. [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH] とこの文書で定義される SSH プロトコルに対する IANA の考慮は, [SSH-NUMBERS] で詳述されている. 11. セキュリティの考察 このプロトコルは, 安全で認証済みのトランスポート上で動くことを仮定している. ユーザ認証とネットワークレベルでの攻撃に対する対処は, 基底のプロトコルで提供されていることを仮定している. このプロトコルのセキュリティについての考慮のすべては, [SSH-ARCH]で提供されている. この文書に特有のこととして, ホスト鍵が注意や説明なしに変更された場合には, すべての潜在的に危険な特徴(たとえば, エージェントの転送, X11の転送, TCP/IPの転送)を実装が無効にすることを推奨する. Ylonen & Lonvick Standards Track [Page 21] RFC 4254 SSH Connection Protocol January 2006 12. References 12.1. Normative References [SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. 12.2. Informative References [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [SCHEIFLER] Scheifler, R., "X Window System : The Complete Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital Press ISBN 1555580882, February 1992. Ylonen & Lonvick Standards Track [Page 22] RFC 4254 SSH Connection Protocol January 2006 [POSIX] ISO/IEC, 9945-1., "Information technology -- Portable Operating System Interface (POSIX)-Part 1: System Application Program Interface (API) C Language", ANSI/ IEE Std 1003.1, July 1996. Authors' Addresses Tatu Ylonen SSH Communications Security Corp Valimotie 17 00380 Helsinki Finland EMail: ylo@ssh.com Chris Lonvick (editor) Cisco Systems, Inc. 12515 Research Blvd. Austin 78759 USA EMail: clonvick@cisco.com Trademark Notice "ssh" is a registered trademark in the United States and/or other countries. Ylonen & Lonvick Standards Track [Page 23] RFC 4254 SSH Connection Protocol January 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 訳者: 春山 征吾 . This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Ylonen & Lonvick Standards Track [Page 24]