RFC4254 日本語訳
4254 The Secure Shell (SSH) Connection Protocol. T. Ylonen, C.Lonvick, Ed.. January 2006. (Format: TXT=50338 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Ylonen
Request for Comments: 4254 SSH Communications Security Corp
Category: Standards Track C. Lonvick, Ed.
Cisco Systems, Inc.
January 2006
Ylonenがコメントのために要求するワーキンググループT.をネットワークでつないでください: 4254年のセキュアシェル (SSH)通信秘密保全Corpカテゴリ: エド標準化過程C.Lonvick、シスコシステムズInc.2006年1月
The Secure Shell (SSH) Connection Protocol
セキュア・シェル(セキュアシェル (SSH))接続プロトコル
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.
安全なシェル(SSH)は不安定なネットワークの上の安全なリモート・ログインと他の安全なネットワーク・サービスのためのプロトコルです。
This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel.
このドキュメントはSSH Connectionプロトコルについて説明します。 それは対話的なログインセッション、コマンドのリモート実行、進められたTCP/IP接続、および進められたX11接続を提供します。 これらのチャンネルのすべてを単一の暗号化されたトンネルに多重送信します。
The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols.
SSH Connectionプロトコルは、SSHトランスポート層とユーザー認証プロトコルの上で稼働するように設計されています。
Ylonen & Lonvick Standards Track [Page 1] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................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. 序論…2 2. 貢献者…3 3. このドキュメントで中古のコンベンション…3 4. グローバルな要求…4 5. チャンネルメカニズム…5 5.1. チャンネルを開けます…5 5.2. データ転送…7 5.3. チャンネルを閉じます…9 5.4. チャンネル特有の要求…9 6. 対話的なセッション…10 6.1. 開会します…10 6.2. 疑似端末を要求します…11 6.3. X11推進…11 6.3.1. X11推進を要求します…11 6.3.2. X11は精神を集中します…12 6.4. 環境変数通過…12 6.5. シェルかコマンドを始動します…13 6.6. セッションデータ転送…14 6.7. 窓の寸法変化メッセージ…14 6.8. 局所流コントロール…14 6.9. 信号…15 6.10. 戻っているイグジットステータス…15 7. TCP/IPポートフォワーディング…16 7.1. ポートフォワーディングを要求します…16 7.2. TCP/IP推進は向けられます…18 8. ターミナルモードのコード化…19 9. メッセージ番号の概要…21 10. IANA問題…21 11. セキュリティ問題…21 12. 参照…22 12.1. 標準の参照…22 12.2. 有益な参照…22人の作者のアドレス…23 通知を商標登録してください…23
1. Introduction
1. 序論
The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols ([SSH-TRANS] and [SSH-USERAUTH]). It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections.
SSH Connectionプロトコルは、SSHトランスポート層とユーザー認証プロトコル([SSH-TRANS]と[SSH-USERAUTH])の上で稼働するように設計されています。 それは対話的なログインセッション、コマンドのリモート実行、進められたTCP/IP接続、および進められたX11接続を提供します。
The 'service name' for this protocol is "ssh-connection".
このプロトコルのための'サービス名'は「セキュアシェル (SSH)接続」です。
Ylonen & Lonvick Standards Track [Page 2] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[2ページ]。
This document should be read only after reading the SSH architecture document [SSH-ARCH]. This document freely uses terminology and notation from the architecture document without reference or further explanation.
このドキュメントはSSHアーキテクチャドキュメント[SSH-ARCH]を読んだ後の書き込み禁止であるべきです。 このドキュメントはアーキテクチャドキュメントから参照も詳細な説明なしで用語と記法を自由に使用します。
2. Contributors
2. 貢献者
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.
このセットのドキュメントの一流の元の貢献者は以下の通りです。 Tatu Ylonen、Tero Kivinen、ティモ・J.リンネ、サミ・レーティネン(セキュアシェル (SSH)通信秘密保全Corpのすべて)、およびマルック-Juhani O.サーリネン(ユベスキュレ大学)。 ダーレン・モファットは、このセットのドキュメントの元のエディタであり、また、非常にかなりの貢献をしました。
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.
多くの人々が数年間このドキュメントの開発に貢献しました。 承認されるべきである人々はマッツ・アンデション、ベン・ハリス、ビル・ゾンマーフェルト、ブレント・マクルーア、ニールズ・モーラー、ダミアン・ミラー、デリックFawcus、フランク・キューザック、Heikki Nousiainen、ジェイコブSchlyter、ジェフ・ヴァンダイク、ジェフリー・アルトマン、ジェフリーHutzelman、ジョンBright、ジョゼフ・ガルブレイス、ケン・ホーンスタイン、マーカス・フリードル、マーチンForssen、ニコラス・ウィリアムズ、ニールズProvos、ペリーメッツガー、ピーター・ガットマン、サイモンJosefsson、サイモンTatham、ウェイDai、デニスBider、der Mouse、および河野忠義を入れます。 ここにそれらの名前を記載するのは、彼らがこのドキュメントに裏書きしますが、それに貢献したことを意味しません。
3. Conventions Used in This Document
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].
SSHプロトコルに関連するすべてのドキュメントが“MUST"、「必須NOT」が「必要である」というキーワードを使用するものとします、“SHALL"、「」、“SHOULD"、「「推薦され」て、要件について説明するために「5月」の、そして、「任意」のNOTはそうするべきです。 これらのキーワードは[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].
名前空間配分について説明するのに本書では使用されると現れる「私用」、「階層的な配分」、「先着順」、「専門のレビュー」、「仕様が必要である」、「IESG承認」、「IETFコンセンサス」、および「規格動作」というキーワードは[RFC2434]で説明されるように解釈されることです。
Protocol fields and possible values to fill them are defined in this set of documents. Protocol fields will be defined in the message definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as follows.
それらをいっぱいにするプロトコル分野と可能な値はこのセットのドキュメントで定義されます。 プロトコル分野はメッセージ定義で定義されるでしょう。 例と、SSH_エムエスジー_CHANNEL_DATAは以下の通り定義されます。
byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel
string data
バイトSSH_エムエスジー_CHANNEL_DATA uint32受取人チャンネル列データ
Ylonen & Lonvick Standards Track [Page 3] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[3ページ]。
Throughout these documents, when the fields are referenced, they will appear within single quotes. When values to fill those fields are referenced, they will appear within double quotes. Using the above example, possible values for 'data' are "foo" and "bar".
分野が参照をつけられるとき、これらのドキュメント中では、それらはシングル・クォーテション・マークの中に現れるでしょう。 それらの分野をいっぱいにする値が参照をつけられるとき、それらは二重引用符の中に現れるでしょう。 上記の例を使用して、'データ'のための可能な値は、"foo"と「バー」です。
4. Global Requests
4. グローバルな要求
There are several kinds of requests that affect the state of the remote end globally, independent of any channels. An example is a request to start TCP/IP forwarding for a specific port. Note that both the client and server MAY send global requests at any time, and the receiver MUST respond appropriately. All such requests use the following format.
どんなチャンネルの如何にかかわらずリモートエンドの状態にグローバルに影響する数種類の要求があります。 例はTCP/IP推進を特定のポートに始めるという要求です。 クライアントとサーバの両方がいつでも、グローバルな要求を送るかもしれなくて、受信機が適切に応じなければならないことに注意してください。 そのようなすべての要求が以下の形式を使用します。
byte SSH_MSG_GLOBAL_REQUEST
string request name in US-ASCII only
boolean want reply
.... request-specific data follows
米国-ASCIIだけ論理演算子におけるSSH_エムエスジー_GLOBAL_REQUESTストリング要求名が必要とするバイトは返答します… 要求特有のデータは従います。
The value of 'request name' follows the DNS extensibility naming convention outlined in [SSH-ARCH].
'要求名'の値は[SSH-ARCH]に概説されたDNS伸展性命名規則に続きます。
The recipient will respond to this message with SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if 'want reply' is TRUE.
受取人が_SSH_エムエスジーREQUEST_SUCCESSか_SSH_エムエスジーREQUEST_FAILUREと共にこのメッセージに応じる、'、回答が欲しい、'TRUEはそうです。
byte SSH_MSG_REQUEST_SUCCESS
.... response specific data
_バイトSSH_エムエスジーREQUEST_SUCCESS…、応答の特定のデータ
Usually, the 'response specific data' is non-existent.
通常、'応答の特定のデータ'は実在しません。
If the recipient does not recognize or support the request, it simply responds with SSH_MSG_REQUEST_FAILURE.
受取人が要求を認めもしませんし、サポートもしないなら、それは_SSH_エムエスジーREQUEST_FAILUREと共に単に応じます。
byte SSH_MSG_REQUEST_FAILURE
バイトセキュアシェル (SSH)_エムエスジー_は_失敗を要求します。
In general, the reply messages do not include request type identifiers. To make it possible for the originator of a request to identify to which request each reply refers, it is REQUIRED that replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the same order as the corresponding request messages. For channel requests, replies that relate to the same channel MUST also be replied to in the right order. However, channel requests for distinct channels MAY be replied to out-of-order.
一般に、応答メッセージは要求タイプ識別子を含んでいません。 要求が、各回答がどの要求を参照されるかを特定するのを創始者にとって可能にするように、対応する要求メッセージとして同次で_SSH_エムエスジーGLOBAL_REQUESTS MUSTへの回答を送るのは、REQUIREDです。 また、チャンネル要求において、正しい注文で同じチャンネルに関連する回答について答えなければなりません。 しかしながら、異なったチャンネルを求めるチャンネル要求は故障していた状態で答えられるかもしれません。
Ylonen & Lonvick Standards Track [Page 4] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[4ページ]。
5. Channel Mechanism
5. チャンネルメカニズム
All terminal sessions, forwarded connections, etc., are channels. Either side may open a channel. Multiple channels are multiplexed into a single connection.
すべてのターミナルセション、進められた接続などはチャンネルです。 どちらの側もチャンネルを開けるかもしれません。 複数のチャンネルを単独結合に多重送信します。
Channels are identified by numbers at each end. The number referring to a channel may be different on each side. Requests to open a channel contain the sender's channel number. Any other channel- related messages contain the recipient's channel number for the channel.
チャンネルは各端のときに数によって特定されます。 チャンネルについて言及する数はそれぞれの側で異なっているかもしれません。 チャンネルを開けるという要求は送付者の論理機番を含んでいます。 いかなる他のチャンネルの関連するメッセージもチャンネルのための受取人の論理機番を含んでいます。
Channels are flow-controlled. No data may be sent to a channel until a message is received to indicate that window space is available.
チャンネルは流れによって制御されています。 窓のスペースが利用可能であることを示すためにメッセージを受け取るまでデータを全くチャンネルに送らないかもしれません。
5.1. Opening a Channel
5.1. チャンネルを開けます。
When either side wishes to open a new channel, it allocates a local number for the channel. It then sends the following message to the other side, and includes the local channel number and initial window size in the message.
どちらの側も新しいチャンネルを開けたがっているとき、それはチャンネルの市内番号を割り当てます。 それは、次に、以下のメッセージを反対側に送って、メッセージで地方の論理機番の、そして、初期のウィンドウサイズを含めます。
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 specific data follows
CHANNEL_オープンストリングチャンネルが米国-ASCII uint32送付者だけチャンネルuint32でウィンドウサイズのuint32の最大のパケットサイズに頭文字をつけるのをタイプするバイトSSH_エムエスジー_… 特定のデータが従うチャンネルタイプ
The 'channel type' is a name, as described in [SSH-ARCH] and [SSH-NUMBERS], with similar extension mechanisms. The 'sender channel' is a local identifier for the channel used by the sender of this message. The 'initial window size' specifies how many bytes of channel data can be sent to the sender of this message without adjusting the window. The 'maximum packet size' specifies the maximum size of an individual data packet that can be sent to the sender. For example, one might want to use smaller packets for interactive connections to get better interactive response on slow links.
'チャンネルタイプ'は名前です、[SSH-ARCH]と[SSH-民数記]で説明されるように、同様の拡張機能で。'送付者チャンネル'はこのメッセージの送付者によって使用されたチャンネルへのローカルの識別子です。 '初期のウィンドウサイズ'は、窓を調整しないでいくつのバイトのチャンネルデータをこのメッセージの送付者に送ることができるかを指定します。 '最大のパケットサイズ'は送付者に送ることができる個々のデータ・パケットの最大サイズを指定します。 例えば、対話的な接続が遅いリンクの上により良い対話的な応答を得るのに人は、より小さいパケットを使用したがっているかもしれません。
The remote side then decides whether it can open the channel, and responds with either SSH_MSG_CHANNEL_OPEN_CONFIRMATION or SSH_MSG_CHANNEL_OPEN_FAILURE.
遠隔地側は、次に、それがチャンネルを開けることができるかどうか決めて、_SSH_エムエスジー_CHANNEL_オープンCONFIRMATIONか_SSH_エムエスジー_CHANNEL_オープンFAILUREのどちらかと共にこたえます。
Ylonen & Lonvick Standards Track [Page 5] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[5ページ]。
byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION
uint32 recipient channel
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
.... channel type specific data follows
バイトの受取人チャンネルuint32送付者チャンネルuint32初期のウィンドウサイズuint32最大のパケットSSH_エムエスジー_CHANNEL_オープン_CONFIRMATION uint32サイズ… 特定のデータが従うチャンネルタイプ
The 'recipient channel' is the channel number given in the original open request, and 'sender channel' is the channel number allocated by the other side.
'受取人チャンネル'はオリジナルの開いている要求で与えられた論理機番です、そして、'送付者チャンネル'は反対側によって割り当てられた論理機番です。
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]
[RFC3629]ストリング言語タグをコード化するISO-10646 UTF-8のバイトSSH_エムエスジー_CHANNEL_オープン_FAILURE uint32受取人チャンネルuint32理由コード列記述[RFC3066]
If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support the specified 'channel type', it simply responds with SSH_MSG_CHANNEL_OPEN_FAILURE. The client MAY show the 'description' string to the user. If this is done, the client software should take the precautions discussed in [SSH-ARCH].
SSH_エムエスジー_CHANNEL_オープンメッセージの受取人が指定された'チャンネルタイプ'をサポートしないなら、それは_SSH_エムエスジー_CHANNEL_オープンFAILUREと共に単に応じます。 クライアントは'記述'ストリングをユーザに見せているかもしれません。 これが完了しているなら、クライアントソフトウェアは[SSH-ARCH]で議論した注意を払うはずです。
The SSH_MSG_CHANNEL_OPEN_FAILURE 'reason code' values are defined in the following table. Note that the values for the 'reason code' are given in decimal format for readability, but they are actually uint32 values.
SSH_エムエスジー_CHANNEL_オープン_FAILURE'理由コード'値は以下のテーブルで定義されます。 読み易さのための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
英字名理由コード------------- ----------- _の行政上禁止された_の1つのセキュアシェル (SSH)の_開いているセキュアシェル (SSH)_戸外の_は_失敗した2のオープンな_未知の_セキュアシェル (SSH)_チャンネル_タイプ3のセキュアシェル (SSH)の_の開いている_リソース_不足4を接続します。
Requests for assignments of new SSH_MSG_CHANNEL_OPEN 'reason code' values (and associated 'description' text) in the range of 0x00000005 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. The IANA will not assign Channel Connection Failure 'reason code' values in the range of 0xFE000000 to 0xFFFFFFFF. Channel Connection Failure 'reason code' values in that range are left for PRIVATE USE, as described in [RFC2434].
0xFDFFFFFFへの0×00000005の範囲の新しいSSH_エムエスジー_CHANNEL_オープン'理由コード'値(そして、関連'記述'テキスト)の課題を求めてIETF CONSENSUSメソッドで要求しなければなりません、[RFC2434]で説明されるように。 IANAは0xFFFFFFFFへの0xFE000000の範囲でChannel Connection Failure'理由コード'に値を割り当てないでしょう。 その範囲のチャンネルConnection Failure'理由コード'値は[RFC2434]で説明されるようにPRIVATE USEに残されます。
While it is understood that the IANA will have no control over the range of 0xFE000000 to 0xFFFFFFFF, this range will be split in two parts and administered by the following conventions.
IANAが0xFE000000の範囲を0xFFFFFFFFに管理しないのが理解されている間、この範囲は、2つの部品で分けられて、以下のコンベンションによって管理されるでしょう。
Ylonen & Lonvick Standards Track [Page 6] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[6ページ]。
o The range of 0xFE000000 to 0xFEFFFFFF is to be used in conjunction
with locally assigned channels. For example, if a channel is
proposed with a 'channel type' of "example_session@example.com",
but fails, then the response will contain either a 'reason code'
assigned by the IANA (as listed above and in the range of
0x00000001 to 0xFDFFFFFF) or a locally assigned value in the range
of 0xFE000000 to 0xFEFFFFFF. Naturally, if the server does not
understand the proposed 'channel type', even if it is a locally
defined 'channel type', then the 'reason code' MUST be 0x00000003,
as described above, if the 'reason code' is sent. If the server
does understand the 'channel type', but the channel still fails to
open, then the server SHOULD respond with a locally assigned
'reason code' value consistent with the proposed, local 'channel
type'. It is assumed that practitioners will first attempt to use
the IANA assigned 'reason code' values and then document their
locally assigned 'reason code' values.
o 0xFEFFFFFFへの0xFE000000の範囲は局所的に割り当てられたチャンネルに関連して使用されることです。 例えば、チャンネルが" example_session@example.com "の'チャンネルタイプ'で提案されますが、失敗すると、応答は0xFE000000の範囲にIANA(範囲の上と、そして、0xFDFFFFFFへの0×00000001の範囲に記載されているように)によって割り当てられた'理由コード'か局所的に割り当てられた値のどちらかを0xFEFFFFFFに保管するでしょう。 当然、サーバがそれが局所的に定義された'チャンネルタイプ'であっても提案された'チャンネルタイプ'を理解していないなら、'理由コード'は0×00000003であるに違いありません、上で説明されるように、'理由コード'を送るなら。 サーバが'チャンネルタイプ'を理解していますが、チャンネルがまだ開いていないなら、サーバSHOULDは提案されて、地方の'チャンネルタイプ'と一致した局所的に割り当てられた'理由コード'値で応じます。 開業医が最初に'理由コード'値が割り当てられたIANAを使用して、次に、それらの局所的に割り当てられた'理由コード'値を記録するのを試みると思われます。
o There are no restrictions or suggestions for the range starting
with 0xFF. No interoperability is expected for anything used in
this range. Essentially, it is for experimentation.
o 0xFFから始まる範囲のためのどんな制限も提案もありません。 相互運用性は全くこの範囲で使用される何のためにも予想されません。 本質的には、それは実験のためのものです。
5.2. Data Transfer
5.2. データ転送
The window size specifies how many bytes the other party can send before it must wait for the window to be adjusted. Both parties use the following message to adjust the window.
窓が調整されるのを待たなければならない前にウィンドウサイズは、相手がいくつのバイトを送ることができるかを指定します。 双方は窓を調整する以下のメッセージを使用します。
byte SSH_MSG_CHANNEL_WINDOW_ADJUST
uint32 recipient channel
uint32 bytes to add
加えるバイトSSH_エムエスジー_CHANNEL_WINDOW_ADJUST uint32受取人チャンネルuint32バイト
After receiving this message, the recipient MAY send the given number of bytes more than it was previously allowed to send; the window size is incremented. Implementations MUST correctly handle window sizes of up to 2^32 - 1 bytes. The window MUST NOT be increased above 2^32 - 1 bytes.
このメッセージを受け取った後に、受取人はそれが以前に発信できたよりバイトの与えられた数を送るかもしれません。 ウィンドウサイズは増加されています。 実装は正しく最大2^のウィンドウサイズを32--1バイト扱わなければなりません。 窓を2^32--1バイトより上まで増強してはいけません。
Data transfer is done with messages of the following type.
以下のタイプに関するメッセージでデータ転送をします。
byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel
string data
バイトSSH_エムエスジー_CHANNEL_DATA uint32受取人チャンネル列データ
The maximum amount of data allowed is determined by the maximum packet size for the channel, and the current window size, whichever is smaller. The window size is decremented by the amount of data sent. Both parties MAY ignore all extra data sent after the allowed window is empty.
チャンネル、および現在のウィンドウサイズのための最大のパケットサイズに従って、許容された最大のデータ量は決定しています、どれがさらに小さいかなら。 ウィンドウサイズは送られたデータ量で減少します。 双方は許容窓が空になった後に送られたすべての付加的なデータを無視するかもしれません。
Ylonen & Lonvick Standards Track [Page 7] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[7ページ]。
Implementations are expected to have some limit on the SSH transport layer packet size (any limit for received packets MUST be 32768 bytes or larger, as described in [SSH-TRANS]). The implementation of the SSH connection layer
実装がSSHトランスポート層パケットサイズに何らかの限界を持っていると予想されます(容認されたパケットのためのどんな限界も32768バイト以上でなければなりません、[SSH-TRANS]で説明されるように)。 SSH接続層の実装
o MUST NOT advertise a maximum packet size that would result in
transport packets larger than its transport layer is willing to
receive.
o トランスポート層が、受信しても構わないと思っているより大きい輸送パケットをもたらす最大のパケットサイズの広告を出してはいけません。
o MUST NOT generate data packets larger than its transport layer is
willing to send, even if the remote end would be willing to accept
very large packets.
o リモートエンドが、非常に大きいパケットを受け入れても構わないと思っても、データがトランスポート層が、発信しても構わないと思っているより大きいパケットであると生成してはいけません。
Additionally, some channels can transfer several types of data. An example of this is stderr data from interactive sessions. Such data can be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages, where a separate integer specifies the type of data. The available types and their interpretation depend on the type of channel.
さらに、何人かのチャンネルがいくつかのタイプに関するデータを移すことができます。 この例は対話的なセッションからのstderrデータです。 SSH_エムエスジー_CHANNEL_EXTENDED_DATAメッセージでそのようなデータを通過できます。そこでは、別々の整数がデータのタイプを指定します。 手があいているタイプと彼らの解釈はチャンネルのタイプに頼っています。
byte SSH_MSG_CHANNEL_EXTENDED_DATA
uint32 recipient channel
uint32 data_type_code
string data
バイトSSH_エムエスジー_CHANNEL_EXTENDED_DATA uint32受取人チャンネルuint32データ_は_コード列データをタイプします。
Data sent with these messages consumes the same window as ordinary data.
これらのメッセージと共に送られたデータは普通のデータと同じ窓を消費します。
Currently, only the following type is defined. Note that the value for the 'data_type_code' is given in decimal format for readability, but the values are actually uint32 values.
現在、以下のタイプだけが定義されます。 読み易さのための10進形式で'データ_タイプ_コード'のための値を与えますが、値が実際にuint32値であることに注意してください。
Symbolic name data_type_code
------------- --------------
SSH_EXTENDED_DATA_STDERR 1
英字名データ_は_コードをタイプします。------------- -------------- セキュアシェル (SSH)_は_データ_STDERR1を広げました。
Extended Channel Data Transfer 'data_type_code' values MUST be assigned sequentially. Requests for assignments of new Extended Channel Data Transfer 'data_type_code' values and their associated Extended Channel Data Transfer 'data' strings, in the range of 0x00000002 to 0xFDFFFFFF, MUST be done through the IETF CONSENSUS method as described in [RFC2434]. The IANA will not assign Extended Channel Data Transfer 'data_type_code' values in the range of 0xFE000000 to 0xFFFFFFFF. Extended Channel Data Transfer 'data_type_code' values in that range are left for PRIVATE USE, as described in [RFC2434]. As is noted, the actual instructions to the IANA are in [SSH-NUMBERS].
拡張Channel Data Transfer'データ_タイプ_コード'値を連続して割り当てなければなりません。 [RFC2434]で説明されるIETF CONSENSUSメソッドで新しいExtended Channel Data Transfer'データ_タイプ_コード'値の課題を求める要求と0xFDFFFFFFへの0×00000002の範囲のそれらの関連Extended Channel Data Transfer'データ'ストリングをしなければなりません。 IANAは0xFFFFFFFFへの0xFE000000の範囲でExtended Channel Data Transfer'データ_タイプ_コード'に値を割り当てないでしょう。 その範囲の拡張Channel Data Transfer'データ_タイプ_コード'値は[RFC2434]で説明されるようにPRIVATE USEに残されます。 そのままで、有名であることで、[SSH-民数記]にはIANAへの有効命令があります。
Ylonen & Lonvick Standards Track [Page 8] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[8ページ]。
5.3. Closing a Channel
5.3. チャンネルを閉じます。
When a party will no longer send more data to a channel, it SHOULD send SSH_MSG_CHANNEL_EOF.
パーティーはもうより多くのデータをチャンネルに送らないで、それはSHOULDです。いつ、SSH_エムエスジー_CHANNEL_EOFを送ってくださいか。
byte SSH_MSG_CHANNEL_EOF
uint32 recipient channel
バイトSSH_エムエスジー_CHANNEL_EOF uint32受取人チャンネル
No explicit response is sent to this message. However, the application may send EOF to whatever is at the other end of the channel. Note that the channel remains open after this message, and more data may still be sent in the other direction. This message does not consume window space and can be sent even if no window space is available.
どんな明白な応答もこのメッセージに送りません。 しかしながら、アプリケーションはチャンネルのもう一方の端にあることなら何でもにEOFを送ります。 チャンネルがこのメッセージの後に開いたままで残っていることに注意してください。そうすれば、まだより多くのデータをもう片方の方向に送ってもよいです。 このメッセージを窓のスペースを消費しないで、どんな窓のスペースも利用可能でなくても、送ることができます。
When either party wishes to terminate the channel, it sends SSH_MSG_CHANNEL_CLOSE. Upon receiving this message, a party MUST send back an SSH_MSG_CHANNEL_CLOSE unless it has already sent this message for the channel. The channel is considered closed for a party when it has both sent and received SSH_MSG_CHANNEL_CLOSE, and the party may then reuse the channel number. A party MAY send SSH_MSG_CHANNEL_CLOSE without having sent or received SSH_MSG_CHANNEL_EOF.
何れの当事者がチャンネルを終えたがっているとき、それは_SSH_エムエスジーCHANNEL_CLOSEを送ります。 このメッセージを受け取って、それが既にチャンネルへのこのメッセージを送らない場合、パーティーはSSH_エムエスジー_CHANNEL_CLOSEを後部に送らなければなりません。 ともに_SSH_エムエスジーCHANNEL_CLOSEを送って、受けたとき、チャンネルはパーティーのために閉じられると考えられます、そして、次に、パーティーは論理機番を再利用するかもしれません。 _SSH_エムエスジーCHANNEL_EOFを送るか、または受けていなくて、パーティーは_SSH_エムエスジーCHANNEL_CLOSEを送るかもしれません。
byte SSH_MSG_CHANNEL_CLOSE
uint32 recipient channel
バイトSSH_エムエスジー_CHANNEL_CLOSE uint32受取人チャンネル
This message does not consume window space and can be sent even if no window space is available.
このメッセージを窓のスペースを消費しないで、どんな窓のスペースも利用可能でなくても、送ることができます。
It is RECOMMENDED that all data sent before this message be delivered to the actual destination, if possible.
できれば、このメッセージの前に送られたすべてのデータが実際の送付先に提供されるのは、RECOMMENDEDです。
5.4. Channel-Specific Requests
5.4. チャンネル特有の要求
Many 'channel type' values have extensions that are specific to that particular 'channel type'. An example is requesting a pty (pseudo terminal) for an interactive session.
多くの'チャンネルタイプ'値には、その特定の'チャンネルタイプ'に、特定の拡張子があります。 例は対話的なセッションのために、pty(疑似端末)を要求しています。
All channel-specific requests use the following format.
すべてのチャンネル特有の要求が以下の形式を使用します。
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string request type in US-ASCII characters only
boolean want reply
.... type-specific data follows
米国-ASCII文字だけ論理演算子におけるCHANNEL_REQUEST uint32受取人チャンネルストリング要求タイプが必要とするバイトSSH_エムエスジー_は返答します… タイプ特有のデータは従います。
Ylonen & Lonvick Standards Track [Page 9] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[9ページ]。
If 'want reply' is FALSE, no response will be sent to the request. Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS, SSH_MSG_CHANNEL_FAILURE, or request-specific continuation messages. If the request is not recognized or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned.
'、回答が欲しい、'いいえはFALSE、応答が送られる要求ですか? さもなければ、受取人は_SSH_エムエスジーCHANNEL_SUCCESSと共に応じて、_SSH_エムエスジーCHANNEL_FAILUREの、または、要求特有の継続はメッセージです。 要求を認識しないか、またはチャンネルのためにサポートしないなら、SSH_エムエスジー_CHANNEL_FAILUREを返します。
This message does not consume window space and can be sent even if no window space is available. The values of 'request type' are local to each channel type.
このメッセージを窓のスペースを消費しないで、どんな窓のスペースも利用可能でなくても、送ることができます。 それぞれのチャンネルタイプにおいて、'要求タイプ'の値は地方です。
The client is allowed to send further messages without waiting for the response to the request.
要求への応答を待たないで、クライアントはさらなるメッセージを送ることができます。
'request type' names follow the DNS extensibility naming convention outlined in [SSH-ARCH] and [SSH-NUMBERS].
'要求タイプ'名は[SSH-ARCH]と[SSH-民数記]に概説されたDNS伸展性命名規則に続きます。
byte SSH_MSG_CHANNEL_SUCCESS
uint32 recipient channel
バイトSSH_エムエスジー_CHANNEL_SUCCESS uint32受取人チャンネル
byte SSH_MSG_CHANNEL_FAILURE
uint32 recipient channel
バイトSSH_エムエスジー_CHANNEL_FAILURE uint32受取人チャンネル
These messages do not consume window space and can be sent even if no window space is available.
これらのメッセージを窓のスペースを消費しないで、どんな窓のスペースも利用可能でなくても、送ることができます。
6. Interactive Sessions
6. 対話的なセッション
A session is a remote execution of a program. The program may be a shell, an application, a system command, or some built-in subsystem. It may or may not have a tty, and may or may not involve X11 forwarding. Multiple sessions can be active simultaneously.
セッションはプログラムのリモート実行です。 プログラムは、シェル、アプリケーション、システム・コマンド、または何らかの内蔵のサブシステムであるかもしれません。 それは、ttyを持って、X11推進にかかわるかもしれません。 複数のセッションが同時に、活発である場合があります。
6.1. Opening a Session
6.1. 開会します。
A session is started by sending the following message.
セッションは、以下のメッセージを送ることによって、始められます。
byte SSH_MSG_CHANNEL_OPEN
string "session"
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
バイトSSH_エムエスジー_CHANNEL_オープンストリング「セッション」uint32送付者チャンネルuint32はウィンドウサイズのuint32の最大のパケットサイズに頭文字をつけます。
Client implementations SHOULD reject any session channel open requests to make it more difficult for a corrupt server to attack the client.
SHOULDがどんなセッションのときにも拒絶するクライアント実装は不正なサーバがクライアントを攻撃するのをより難しくするという開いている要求を向けます。
Ylonen & Lonvick Standards Track [Page 10] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[10ページ]。
6.2. Requesting a Pseudo-Terminal
6.2. 疑似端末を要求します。
A pseudo-terminal can be allocated for the session by sending the following message.
セッションのために以下のメッセージを送ることによって、疑似端末を割り当てることができます。
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
バイトSSH_エムエスジー_CHANNEL_REQUEST uint32受取人チャンネルストリング"pty-req"論理演算子は_回答ストリングTERM環境変数値の(例えば、vt100)uint32端末幅を必要とします、キャラクタ(例えば、80)のuint32の端末の高さ、行(例えば、24)のuint32の端末の幅、画素(例えば、640)のuint32の端末の高さ、画素(例えば、480)のストリングのコード化されたターミナルモード
The 'encoded terminal modes' are described in Section 8. Zero dimension parameters MUST be ignored. The character/row dimensions override the pixel dimensions (when nonzero). Pixel dimensions refer to the drawable area of the window.
'コード化されたターミナルモード'はセクション8で説明されます。 寸法パラメタを全く無視してはいけません。 キャラクタ/行の重要性は画素の重要性をくつがえします(非零であるときに)。 画素の重要性は窓の作画可能領域について言及します。
The dimension parameters are only informational.
寸法パラメタは情報であるだけです。
The client SHOULD ignore pty requests.
クライアントSHOULDはpty要求を無視します。
6.3. X11 Forwarding
6.3. X11推進
6.3.1. Requesting X11 Forwarding
6.3.1. X11推進を要求します。
X11 forwarding may be requested for a session by sending a SSH_MSG_CHANNEL_REQUEST message.
X11推進は、セッションのためにSSH_エムエスジー_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
バイトSSH_エムエスジー_CHANNEL_REQUEST uint32受取人チャンネルストリング"x11-req"論理演算子は回答論理演算子単独結合ストリングx11認証プロトコルストリングx11認証クッキーuint32 x11スクリーン番号を必要とします。
It is RECOMMENDED that the 'x11 authentication cookie' that is sent be a fake, random cookie, and that the cookie be checked and replaced by the real cookie when a connection request is received.
接続要求が受信されているとき、クッキーを本当のクッキーに送られる'x11認証クッキー'がにせの、そして、無作為のクッキーであり、チェックして、取り替えるのは、RECOMMENDEDです。
X11 connection forwarding should stop when the session channel is closed. However, already opened forwardings should not be automatically closed when the session channel is closed.
セッションチャンネルが閉じられるとき、X11接続推進は止まるべきです。 しかしながら、セッションチャンネルが閉じるとき、自動的に既に開かれた推進を終えるべきではありません。
Ylonen & Lonvick Standards Track [Page 11] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[11ページ]。
If 'single connection' is TRUE, only a single connection should be forwarded. No more connections will be forwarded after the first, or after the session channel has been closed.
'単独結合'がTRUEであるなら、単独結合だけを進めるべきです。 1番目か、セッションチャンネルを閉店させた後にそれ以上の接続を全く進めないでしょう。
The 'x11 authentication protocol' is the name of the X11 authentication method used, e.g., "MIT-MAGIC-COOKIE-1".
'x11認証プロトコル'は認証方法が使用したX11という名前です、例えば、「MITの魔法のクッキー1インチ。」
The 'x11 authentication cookie' MUST be hexadecimal encoded.
'x11認証クッキー'はコード化された16進であるに違いありません。
The X Protocol is documented in [SCHEIFLER].
Xプロトコルは[SCHEIFLER]に記録されます。
6.3.2. X11 Channels
6.3.2. X11チャンネル
X11 channels are opened with a channel open request. The resulting channels are independent of the session, and closing the session channel does not close the forwarded 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_エムエスジー_CHANNEL_オープンが結ぶバイト、「送付者チャンネルuint32初期のx11" uint32の最大のパケットサイズストリング創始者ウィンドウサイズuint32アドレス、(例えば、「192.168、0.38インチ) uint32創始者が移植する.7、」
The recipient should respond with SSH_MSG_CHANNEL_OPEN_CONFIRMATION or SSH_MSG_CHANNEL_OPEN_FAILURE.
受取人は_SSH_エムエスジー_CHANNEL_オープンCONFIRMATIONか_SSH_エムエスジー_CHANNEL_オープンFAILUREと共に応じるべきです。
Implementations MUST reject any X11 channel open requests if they have not requested X11 forwarding.
X11推進を要求していないなら、実装は戸外が要求するどんなX11チャンネルも拒絶しなければなりません。
6.4. Environment Variable Passing
6.4. 環境変数通過
Environment variables may be passed to the shell/command to be started later. Uncontrolled setting of environment variables in a privileged process can be a security hazard. It is recommended that implementations either maintain a list of allowable variable names or only set environment variables after the server process has dropped sufficient privileges.
環境変数は後で始められるべきシェル/コマンドに通過されるかもしれません。 特権があるプロセスの環境変数の非制御の設定はセキュリティ危険であるかもしれません。 実装が許容できる変数名のリストを維持するか、またはサーバプロセスが十分な特権を下げた後に環境変数を設定するだけであるのが、お勧めです。
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "env"
boolean want reply
string variable name
string variable value
バイトSSH_エムエスジー_CHANNEL_REQUEST uint32受取人チャンネルストリング"env"論理演算子は回答列変数名前列変数価値を必要とします。
Ylonen & Lonvick Standards Track [Page 12] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[12ページ]。
6.5. Starting a Shell or a Command
6.5. シェルかコマンドを始動します。
Once the session has been set up, a program is started at the remote end. The program can be a shell, an application program, or a subsystem with a host-independent name. Only one of these requests can succeed per channel.
セッションがいったんセットアップされると、プログラムはリモートエンドで始動されます。 プログラムは、ホストから独立している名前があるシェル、アプリケーション・プログラム、またはサブシステムであるかもしれません。 チャンネル単位でこれらの要求の1つしか成功できません。
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "shell"
boolean want reply
SSH_エムエスジー_CHANNEL_REQUEST uint32受取人チャンネルストリング「シェル」論理演算子が必要とするバイトは返答します。
This message will request that the user's default shell (typically defined in /etc/passwd in UNIX systems) be started at the other end.
このメッセージは、ユーザのデフォルトシェル(/etc/passwdでUNIXシステムで通常定義される)がもう一方の端のときに始動されるよう要求するでしょう。
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "exec"
boolean want reply
string command
バイトSSH_エムエスジー_CHANNEL_REQUEST uint32受取人チャンネルストリング「幹部」論理演算子は回答ストリング命令を必要とします。
This message will request that the server start the execution of the given command. The 'command' string may contain a path. Normal precautions MUST be taken to prevent the execution of unauthorized commands.
このメッセージは、サーバが与えられたコマンドの実行を始めるよう要求するでしょう。 'コマンド'ストリングは経路を含むかもしれません。 権限のないコマンドの実行を防ぐために通常の注意を払わなければなりません。
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "subsystem"
boolean want reply
string subsystem name
バイトSSH_エムエスジー_CHANNEL_REQUEST uint32受取人チャンネルストリング「サブシステム」論理演算子は回答ストリングサブシステム名を必要とします。
This last form executes a predefined subsystem. It is expected that these will include a general file transfer mechanism, and possibly other features. Implementations may also allow configuring more such mechanisms. As the user's shell is usually used to execute the subsystem, it is advisable for the subsystem protocol to have a "magic cookie" at the beginning of the protocol transaction to distinguish it from arbitrary output generated by shell initialization scripts, etc. This spurious output from the shell may be filtered out either at the server or at the client.
この最後のフォームは事前に定義されたサブシステムを実行します。 これらが一般的なファイル転送メカニズム、およびことによると他の特徴を含むと予想されます。 また、実装で、そのようなより多くのメカニズムを構成するかもしれません。ユーザのシェルがサブシステムを実行するのに通常使用されるので、プロトコルトランザクションの始めに、シェル初期化スクリプトなどによって生成された任意の出力とそれを区別するためにサブシステムプロトコルには「魔法のクッキー」があるのは、賢明です。 シェルからのこのスプリアス出力はサーバにおいて、または、クライアントで無視されるかもしれません。
The server SHOULD NOT halt the execution of the protocol stack when starting a shell or a program. All input and output from these SHOULD be redirected to the channel or to the encrypted tunnel.
シェルかプログラムを始動するとき、サーバSHOULD NOTはプロトコル・スタックの実行を止めます。 これらのSHOULDからのすべての入出力が、チャンネルに向け直されるか、または暗号化にトンネルを堀ります。
It is RECOMMENDED that the reply to these messages be requested and checked. The client SHOULD ignore these messages.
これらのメッセージに関する回答が要求されていて、チェックされるのは、RECOMMENDEDです。 クライアントSHOULDはこれらのメッセージを無視します。
Ylonen & Lonvick Standards Track [Page 13] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[13ページ]。
Subsystem names follow the DNS extensibility naming convention outlined in [SSH-NUMBERS].
サブシステム名は[SSH-民数記]に概説されたDNS伸展性命名規則に続きます。
6.6. Session Data Transfer
6.6. セッションデータ転送
Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and SSH_MSG_CHANNEL_EXTENDED_DATA packets and the window mechanism. The extended data type SSH_EXTENDED_DATA_STDERR has been defined for stderr data.
SSH_エムエスジー_CHANNEL_DATAとSSH_エムエスジー_CHANNEL_EXTENDED_DATAパケットとウィンドウメカニズムを使用することでセッションのためのデータ転送をします。 拡張データ型SSH_EXTENDED_DATA_STDERRはstderrデータのために定義されました。
6.7. Window Dimension Change Message
6.7. 窓の寸法変化メッセージ
When the window (terminal) size changes on the client side, it MAY send a message to the other side to inform it of the new 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
バイトSSH_エムエスジー_CHANNEL_REQUEST uint32受取人チャンネルストリング「ウィンドウ変化」論理演算子のFALSE uint32の端末の幅(コラムuint32端末の高さ)はuint32の端末の幅をこぎます、画素のuint32の端末の高さ、画素
A response SHOULD NOT be sent to this message.
応答SHOULD NOT、このメッセージに送ってください。
6.8. Local Flow Control
6.8. 局所流コントロール
On many systems, it is possible to determine if a pseudo-terminal is using control-S/control-Q flow control. When flow control is allowed, it is often desirable to do the flow control at the client end to speed up responses to user requests. This is facilitated by the following notification. Initially, the server is responsible for flow control. (Here, again, client means the side originating the session, and server means the other side.)
多くのシステムの上では、疑似端末がコントロールコントロールS/Qフロー制御を使用しているかどうか決定するのは可能です。 フロー制御が許容されているとき、ユーザ要求への応答を早くするためにクライアント終わりにフロー制御をするのはしばしば望ましいです。 これは以下の通知で容易にされます。 初めは、サーバはフロー制御に原因となります。 (一方、ここで、クライアントはセッションを溯源する側を言って、サーバは反対側を意味します。)
The message below is used by the server to inform the client when it can or cannot perform flow control (control-S/control-Q processing). If 'client can do' is TRUE, the client is allowed to do flow control using control-S and control-Q. The client MAY ignore this message.
以下のメッセージはサーバによって使用されて、それがいつ実行できるか、またはフロー制御(コントロールコントロールS/Q処理)を実行できないかをクライアントに知らせます。 'クライアントはできます'がTRUEであるなら、クライアントは、コントロールSとコントロールQを使用することでフロー制御ができます。 クライアントはこのメッセージを無視するかもしれません。
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "xon-xoff"
boolean FALSE
boolean client can do
SSH_エムエスジー_CHANNEL_REQUEST uint32受取人チャンネルストリング"xon-xoff"論理演算子FALSE論理演算子クライアントができるバイトが
No response is sent to this message.
応答を全くこのメッセージに送りません。
Ylonen & Lonvick Standards Track [Page 14] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[14ページ]。
6.9. Signals
6.9. 信号
A signal can be delivered to the remote process/service using the following message. Some systems may not implement signals, in which case they SHOULD ignore this message.
以下のメッセージを使用することでリモートプロセス/サービスに信号を提供できます。 その場合、システムが信号を実装しないかもしれないいくつか、それら、SHOULDはこのメッセージを無視します。
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "signal"
boolean FALSE
string signal name (without the "SIG" prefix)
バイトSSH_エムエスジー_CHANNEL_REQUEST uint32受取人チャンネルストリング「信号」論理演算子FALSEストリング信号名(「SIG」接頭語のない)
'signal name' values will be encoded as discussed in the passage describing SSH_MSG_CHANNEL_REQUEST messages using "exit-signal" in this section.
'信号名'値はこのセクションの「出口信号」を使用することでSSH_エムエスジー_CHANNEL_REQUESTメッセージについて説明する通路で議論するようにコード化されるでしょう。
6.10. Returning Exit Status
6.10. 戻っているイグジットステータス
When the command running at the other end terminates, the following message can be sent to return the exit status of the command. Returning the status is RECOMMENDED. No acknowledgement is sent for this message. The channel needs to be closed with SSH_MSG_CHANNEL_CLOSE after this message.
もう一方の端のときに稼働するコマンドが終わるとき、コマンドのイグジットステータスを返すために以下のメッセージを送ることができます。 状態を返すのは、RECOMMENDEDです。 このメッセージのために承認を全く送りません。 チャンネルは、_このメッセージの後のSSH_エムエスジーCHANNEL_CLOSEと共に閉じられる必要があります。
The client MAY ignore these messages.
クライアントはこれらのメッセージを無視するかもしれません。
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "exit-status"
boolean FALSE
uint32 exit_status
バイトSSH_エムエスジー_CHANNEL_REQUEST uint32受取人チャンネルストリング「イグジットステータス」論理演算子FALSE uint32出口_状態
The remote command may also terminate violently due to a signal. Such a condition can be indicated by the following message. A zero 'exit_status' usually means that the command terminated successfully.
また、リモートコマンドは信号のため激しく終わるかもしれません。 以下のメッセージはそのような状態を示すことができます。 通常、ゼロが'_状態を出る'というコマンドが首尾よく終えた手段。
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]
バイトSSH_エムエスジー_CHANNEL_REQUEST uint32受取人チャンネルストリング「出口信号」論理演算子FALSEはストリング言語タグをコード化するISO-10646 UTF-8の信号名(「SIG」接頭語のない)のブールコアどさっと落とされたストリングエラーメッセージを結びます。[RFC3066]
Ylonen & Lonvick Standards Track [Page 15] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[15ページ]。
The 'signal name' is one of the following (these are from [POSIX]).
'信号名'は以下の1つ(これらは[POSIX]から来ている)です。
ABRT
ALRM
FPE
HUP
ILL
INT
KILL
PIPE
QUIT
SEGV
TERM
USR1
USR2
ABRT ALRM FPE HUPの病気のINT獲物パイプはSEGV用語USR1 USR2をやめました。
Additional 'signal name' values MAY be sent in the format "sig-name@xyz", where "sig-name" and "xyz" may be anything a particular implementer wants (except the "@" sign). However, it is suggested that if a 'configure' script is used, any non-standard 'signal name' values it finds be encoded as "SIG@xyz.config.guess", where "SIG" is the 'signal name' without the "SIG" prefix, and "xyz" is the host type, as determined by "config.guess".
形式" sig-name@xyz "で追加'信号名'値を送るかもしれません("@"サインを除いて)。そこでは、「sig-名前」と"xyz"が特定のimplementerが欲しい何かであるかもしれません。 しかしながら、それが見つけるどんな標準的でない'信号名'値も" SIG@xyz.config.guess "としてコード化されて、'構成'スクリプトが使用されているなら、「SIG」がどこの「SIG」接頭語がなければ'信号名'であるか、そして、"xyz"がホストタイプであると示唆されます、"config.guess"によって決定されるように。
The 'error message' contains an additional textual explanation of the error message. The message may consist of multiple lines separated by CRLF (Carriage Return - Line Feed) pairs. The client software MAY display this message to the user. If this is done, the client software should take the precautions discussed in [SSH-ARCH].
'エラーメッセージ'はエラーメッセージの追加原文の説明を含んでいます。 メッセージはCRLF(キャリッジReturn--線Feed)組によって切り離された複数の系列から成るかもしれません。 クライアントソフトウェアはこのメッセージをユーザに表示するかもしれません。 これが完了しているなら、クライアントソフトウェアは[SSH-ARCH]で議論した注意を払うはずです。
7. TCP/IP Port Forwarding
7. TCP/IPポートフォワーディング
7.1. Requesting Port Forwarding
7.1. ポートフォワーディングを要求します。
A party need not explicitly request forwardings from its own end to the other direction. However, if it wishes that connections to a port on the other side be forwarded to the local side, it must explicitly request this.
パーティーは明らかにそれ自身の終わりからのもう片方の方向への推進を要求する必要はありません。 しかしながら、反対側の上のポートとの接続がローカル・サイドを送られることを願うなら、それは明らかにこれを要求しなければなりません。
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
SSH_エムエスジー_GLOBAL_REQUESTストリング「tcpip-フォワード」論理演算子が、回答ストリングアドレスが縛る必要があるバイト、(例えば、「0.0 0インチ) uint32が移植する.0は、付くのに付番します」。
Ylonen & Lonvick Standards Track [Page 16] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[16ページ]。
The 'address to bind' and 'port number to bind' specify the IP address (or domain name) and port on which connections for forwarding are to be accepted. Some strings used for 'address to bind' have special-case semantics.
'縛るアドレス'と'縛るポートナンバー'は推進のための接続が受け入れられることになっているIPアドレス(または、ドメイン名)とポートを指定します。 '縛るアドレス'に使用されるいくつかのストリングが特別なケース意味論を持っています。
o "" means that connections are to be accepted on all protocol
families supported by the SSH implementation.
o 「「接続が受け入れられることになっている手段はすべて、SSH実装によって養われたファミリーについて議定書の中で述べます」。
o "0.0.0.0" means to listen on all IPv4 addresses.
o 「0.0、すべてのIPv4アドレスで聴く0インチの.0の手段、」
o "::" means to listen on all IPv6 addresses.
o "::" すべてのIPv6アドレスで聴くことを意味します。
o "localhost" means to listen on all protocol families supported by
the SSH implementation on loopback addresses only ([RFC3330] and
[RFC3513]).
o "localhost"は、ループバックアドレスだけでSSH実装によって養われたすべてのプロトコルファミリーで聴くことを意味します([RFC3330]と[RFC3513])。
o "127.0.0.1" and "::1" indicate listening on the loopback
interfaces for IPv4 and IPv6, respectively.
o そして、「127.0、.0、0.1インチ、」、:、:1インチは、ループバックで聴くのがIPv4とIPv6のためにそれぞれ連結するのを示します。
Note that the client can still filter connections based on information passed in the open request.
クライアントがまだ開いている要求で通過された情報に基づく接続をフィルターにかけることができることに注意してください。
Implementations should only allow forwarding privileged ports if the user has been authenticated as a privileged user.
実装で、ユーザが特権ユーザとして認証された場合にだけ、特権があるポートを進めるべきです。
Client implementations SHOULD reject these messages; they are normally only sent by the client.
クライアント実装SHOULDはこれらのメッセージを拒絶します。 通常、それらはクライアントによって送られるだけです。
If a client passes 0 as port number to bind and has 'want reply' as TRUE, then the server allocates the next available unprivileged port number and replies with the following message; otherwise, there is no response-specific data.
ポートとしての0がひもに付番して、持っているパスによるTRUEとしての'回答が欲し'、クライアントであるなら次に、サーバは以下のメッセージがある次の有効な「非-特権を与え」させられたポートナンバーと回答を割り当てます。 さもなければ、どんな応答特有のデータもありません。
byte SSH_MSG_REQUEST_SUCCESS
uint32 port that was bound on the server
REQUEST_SUCCESS uint32が移植するサーバで制限されたバイトSSH_エムエスジー_
A port forwarding can be canceled with the following message. Note that channel open requests may be received until a reply to this message is received.
以下のメッセージでポートフォワーディングを中止できます。 このメッセージに関する回答が受け取られているまで戸外が要求するチャンネルが受け取られるかもしれないことに注意してください。
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
バイトSSH_エムエスジー_GLOBAL_REQUESTストリング「キャンセルtcpipフォワード」論理演算子が回答ストリングアドレス_を_ひもに必要とする、(例えば、「127.0 0.1インチ) uint32が移植する.0は、付くのに付番します」。
Client implementations SHOULD reject these messages; they are normally only sent by the client.
クライアント実装SHOULDはこれらのメッセージを拒絶します。 通常、それらはクライアントによって送られるだけです。
Ylonen & Lonvick Standards Track [Page 17] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[17ページ]。
7.2. TCP/IP Forwarding Channels
7.2. TCP/IP推進チャンネル
When a connection comes to a port for which remote forwarding has been requested, a channel is opened to forward the port to the other side.
接続がリモート推進が要求されているポートに来るとき、チャンネルは、ポートを反対側に送るために開けられます。
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
バイトSSH_エムエスジー_CHANNEL_オープンストリング「進められたtcpip」uint32送付者チャンネルuint32は接続ストリングの創始者IPアドレスuint32創始者港であった接続uint32ポートであったウィンドウサイズのuint32の最大のパケットサイズストリングアドレスに頭文字をつけます。
Implementations MUST reject these messages unless they have previously requested a remote TCP/IP port forwarding with the given port number.
以前に与えられたポートナンバーでリモートTCP/IPポートフォワーディングを要求していないなら、実装はこれらのメッセージを拒絶しなければなりません。
When a connection comes to a locally forwarded TCP/IP port, the following packet is sent to the other side. Note that these messages MAY also be sent for ports for which no forwarding has been explicitly requested. The receiving side must decide whether to allow the forwarding.
接続が局所的に進められた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
バイトSSH_エムエスジー_CHANNEL_オープンストリング「ダイレクトtcpip」uint32送付者チャンネルuint32は、ストリング創始者IPアドレスuint32創始者港をつなげるためにuint32ポートをつなげるためにウィンドウサイズのuint32の最大のパケットサイズストリングホストに頭文字をつけます。
The 'host to connect' and 'port to connect' specify the TCP/IP host and port where the recipient should connect the channel. The 'host to connect' may be either a domain name or a numeric IP address.
'接するホスト'と'つなげるポート'は受取人がチャンネルに接するべきであるTCP/IPホストとポートを指定します。 '接するホスト'は、ドメイン名か数値IPアドレスのどちらかであるかもしれません。
The 'originator IP address' is the numeric IP address of the machine from where the connection request originates, and the 'originator port' is the port on the host from where the connection originated.
'創始者IPアドレス'は接続要求が起因するところからのマシンの数値IPアドレスです、そして、'創始者ポート'は接続が起因したところからのホストの上のポートです。
Forwarded TCP/IP channels are independent of any sessions, and closing a session channel does not in any way imply that forwarded connections should be closed.
進められたTCP/IPチャンネルはどんなセッションからも独立しています、そして、セッションチャンネルを閉じるのは接続に送られたそれが閉じられるべきであるのを何らかの方法で含意しません。
Ylonen & Lonvick Standards Track [Page 18] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[18ページ]。
Client implementations SHOULD reject direct TCP/IP open requests for security reasons.
クライアント実装SHOULDは安全保障上の理由でダイレクトTCP/IP開いている要求を拒絶します。
8. Encoding of Terminal Modes
8. ターミナルモードのコード化
All 'encoded terminal modes' (as passed in a pty request) are encoded into a byte stream. It is intended that the coding be portable across different environments. The stream consists of opcode- argument pairs wherein the opcode is a byte value. Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255 are not yet defined, and cause parsing to stop (they should only be used after any other data). The stream is terminated by opcode TTY_OP_END (0x00).
すべての'コード化されたターミナルモード'(pty要求で通過されるように)がバイト・ストリームの中にコード化されます。 コード化が異なった環境の向こう側に携帯用であることを意図します。 ストリームはopcodeがバイト値であるopcode議論組から成ります。 Opcodes1〜159には、ただ一つのuint32議論があります。 Opcodes160〜255はまだ定義されていなくて、構文解析を止まらせます(それらはいかなる他のデータの後にも使用されるだけであるべきです)。 ストリームはopcode TTY_OP_END(0×00)によって終えられます。
The client SHOULD put any modes it knows about in the stream, and the server MAY ignore any modes it does not know about. This allows some degree of machine-independence, at least between systems that use a POSIX-like tty interface. The protocol can support other systems as well, but the client may need to fill reasonable values for a number of parameters so the server pty gets set to a reasonable mode (the server leaves all unspecified mode bits in their default values, and only some combinations make sense).
クライアントSHOULDはそれが知っているどんなモードもおよそストリームに入れます、そして、サーバはそれが知らないどんなモードも無視するかもしれません。 これは少なくともPOSIXのようなttyインタフェースを使用するシステムの間のマシン独立をいくらかの許します。 プロトコルはまた、他のシステムをサポートできますが、クライアントが、多くのパラメタのために適正価値をいっぱいにする必要があるかもしれないので、サーバptyは妥当なモードに用意します(サーバがそれらのデフォルト値ですべての不特定のモードビットを残します、そして、いくつかだけの組み合わせが理解できます)。
The naming of opcode values mostly follows the POSIX terminal mode flags. The following opcode values have been defined. Note that the values given below are in decimal format for readability, but they are actually byte values.
opcode値の命名はPOSIXターミナルモード旗にほとんど従います。 以下のopcode値は定義されました。 読み易さのための10進形式には以下に与えられた値がありますが、それらが実際にバイト値であることに注意してください。
opcode mnemonic description
------ -------- -----------
0 TTY_OP_END Indicates end of options.
1 VINTR Interrupt character; 255 if none. Similarly
for the other characters. Not all of these
characters are supported on all systems.
2 VQUIT The quit character (sends SIGQUIT signal on
POSIX systems).
3 VERASE Erase the character to left of the cursor.
4 VKILL Kill the current input line.
5 VEOF End-of-file character (sends EOF from the
terminal).
6 VEOL End-of-line character in addition to
carriage return and/or linefeed.
7 VEOL2 Additional end-of-line character.
8 VSTART Continues paused output (normally
control-Q).
9 VSTOP Pauses output (normally control-S).
10 VSUSP Suspends the current program.
11 VDSUSP Another suspend character.
opcodeの簡略記憶記述------ -------- ----------- オプションの0TTY_OP_END Indicatesエンド。 1 VINTR Interruptキャラクタ。 255 なにもであるなら。 同様である、他のキャラクタのために。 これらのキャラクタのすべてがシステム2VQUITでサポートされるというわけではない、キャラクタ(SIGQUIT信号をPOSIXシステムに送る)をやめてください。 3 カーソルの左へのキャラクタのVERASE Erase。 4VKILL Kill、電流は系列を入力しました。 5 ファイルのVEOF Endキャラクタ(端末からEOFを送ります)。 6 復帰、そして/または、ラインフィードに加えた系列のVEOL Endキャラクタ。 7 VEOL2 Additional行末文字。 8VSTART Continuesが出力(通常コントロールQ)をポーズしました。 9VSTOP Pauses出力(通常コントロールS)。 電流がプログラムする10VSUSP Suspends。 11 VDSUSP Anotherはキャラクタを停学処分にします。
Ylonen & Lonvick Standards Track [Page 19] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[19ページ]。
12 VREPRINT Reprints the current input line.
13 VWERASE Erases a word left of cursor.
14 VLNEXT Enter the next character typed literally,
even if it is a special character
15 VFLUSH Character to flush output.
16 VSWTCH Switch to a different shell layer.
17 VSTATUS Prints system status line (load, command,
pid, etc).
18 VDISCARD Toggles the flushing of terminal output.
30 IGNPAR The ignore parity flag. The parameter
SHOULD be 0 if this flag is FALSE,
and 1 if it is TRUE.
31 PARMRK Mark parity and framing errors.
32 INPCK Enable checking of parity errors.
33 ISTRIP Strip 8th bit off characters.
34 INLCR Map NL into CR on input.
35 IGNCR Ignore CR on input.
36 ICRNL Map CR to NL on input.
37 IUCLC Translate uppercase characters to
lowercase.
38 IXON Enable output flow control.
39 IXANY Any char will restart after stop.
40 IXOFF Enable input flow control.
41 IMAXBEL Ring bell on input queue full.
50 ISIG Enable signals INTR, QUIT, [D]SUSP.
51 ICANON Canonicalize input lines.
52 XCASE Enable input and output of uppercase
characters by preceding their lowercase
equivalents with "\".
53 ECHO Enable echoing.
54 ECHOE Visually erase chars.
55 ECHOK Kill character discards current line.
56 ECHONL Echo NL even if ECHO is off.
57 NOFLSH Don't flush after interrupt.
58 TOSTOP Stop background jobs from output.
59 IEXTEN Enable extensions.
60 ECHOCTL Echo control characters as ^(Char).
61 ECHOKE Visual erase for line kill.
62 PENDIN Retype pending input.
70 OPOST Enable output processing.
71 OLCUC Convert lowercase to uppercase.
72 ONLCR Map NL to CR-NL.
73 OCRNL Translate carriage return to newline
(output).
74 ONOCR Translate newline to carriage
return-newline (output).
75 ONLRET Newline performs a carriage return
(output).
電流が入力した12VREPRINT Reprintsが立ち並んでいます。 単語が残したカーソルの13VWERASE Erases。 14 次のキャラクタのVLNEXT Enterはそれが特殊文字15VFLUSHキャラクターであっても文字通り豊富な出力にタイプしました。 16 異なったシェルへのVSWTCH Switchは層にします。 17VSTATUS Printsシステム状況表示行(負荷、コマンド、pidなど)。 端末を洗い流すのが出力した18VDISCARD Toggles。 30IGNPAR、パリティ・フラグを無視してください。 パラメタSHOULD、この旗がFALSEであり、それであるなら1がTRUEであるなら、0になってください。 31 PARMRKマークの同等と縁どり誤り。 パリティエラーの32INPCK Enableの照合。 33 ISTRIP Stripは8番目にキャラクタを食いちぎりました。 34 入力でのCRへのINLCR Map NL。 35 入力でのIGNCR Ignore CR。 36 入力でのNLへのICRNL Map CR。 37 IUCLC Translateは、小文字で印刷するためにキャラクタを大文字します。 38 IXON Enableはフロー制御を出力しました。 39 IXANY Any炭は停止の後に再開するでしょう。 40 IXOFF Enableはフロー制御を入力しました。 41 IMAXBEL Ringは入力キューで満に鈴をつけます。 50 ISIG EnableはINTR、QUIT、[D]SUSPに合図します。 51 ICANON Canonicalizeは系列を入力しました。 52 「\」がある彼らの小文字の同等物に先行するのによる大文字しているキャラクタのXCASE Enable入出力。 53 ECHO Enable反響。 54 ECHOE Visually抹消は焦げます。 55 ECHOK Killキャラクタは現在行を捨てます。 56ECHONL Echo NL、ECHOがオフであっても。 57 中断の平らに後でないことのNOFLSHドン。 58 出力からのTOSTOP Stopバックグラウンドジョブ。 59 IEXTEN Enable拡張子。 60 ^(炭)としてのECHOCTL Echo制御文字。 ECHOKE Visualが系列のために消す61人は殺されます。 62 入力までPENDIN Retype。 70OPOST Enable出力処理。 71 OLCUC Convertは、大文字するために小文字で印刷します。 72 ONLCRはNLをCR-NLに写像します。 73 ニューライン(出力)へのOCRNL Translate復帰。 復帰ニューライン(出力)への74ONOCR Translateニューライン。 75 ONLRET Newlineは復帰(出力)を実行します。
Ylonen & Lonvick Standards Track [Page 20] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[20ページ]。
90 CS7 7 bit mode.
91 CS8 8 bit mode.
92 PARENB Parity enable.
93 PARODD Odd parity, else even.
90 CS7 7はモードに噛み付きました。 91 CS8 8はモードに噛み付きました。 PARENB Parityが可能にする92。 ほかに93PARODD Oddの同等である、同等です。
128 TTY_OP_ISPEED Specifies the input baud rate in
bits per second.
129 TTY_OP_OSPEED Specifies the output baud rate in
bits per second.
128TTY_OP_ISPEED Specifies、bpsにおける入力ボーレート。 129TTY_OP_OSPEED Specifies、bpsにおける出力ボーレート。
9. Summary of Message Numbers
9. メッセージ番号の概要
The following is a summary of messages and their associated message number.
↓これは、メッセージの概要とそれらの関連メッセージ番号です。
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
セキュアシェル (SSH)..エムエスジー..グローバル..要求..セキュアシェル (SSH)..エムエスジー..要求..成功..セキュアシェル (SSH)..エムエスジー..要求..失敗..セキュアシェル (SSH)..エムエスジー..チャンネル..開く..セキュアシェル (SSH)..エムエスジー..チャンネル..開く..確認..セキュアシェル (SSH)..エムエスジー..チャンネル..開く..失敗..セキュアシェル (SSH)..エムエスジー..チャンネル..窓..調整..セキュアシェル (SSH)..エムエスジー..チャンネル..データ..セキュアシェル (SSH)..エムエスジー..チャンネル..広げる..データ..セキュアシェル (SSH)..エムエスジー..チャンネル..セキュアシェル (SSH)..エムエスジー..チャンネル..閉鎖..セキュアシェル (SSH)..エムエスジー..チャンネル..要求..セキュアシェル (SSH)..エムエスジー..チャンネル..成功..セキュアシェル (SSH)..エムエスジー..チャネルを開設..失敗
10. IANA Considerations
10. IANA問題
This document is part of a set. The IANA considerations for the SSH protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], and this document, are detailed in [SSH-NUMBERS].
このドキュメントは1セットの一部です。 [SSH-ARCH]で定義されるSSHプロトコルのためのIANA問題([SSH-TRANS]、[SSH-USERAUTH]、およびこのドキュメント)は、[SSH-民数記]で詳細です。
11. Security Considerations
11. セキュリティ問題
This protocol is assumed to run on top of a secure, authenticated transport. User authentication and protection against network-level attacks are assumed to be provided by the underlying protocols.
このプロトコルが安全で、認証された輸送の上で稼働すると思われます。 基本的なプロトコルによってネットワークレベル攻撃に対するユーザー認証と保護が提供されると思われます。
Full security considerations for this protocol are provided in [SSH-ARCH]. Specific to this document, it is RECOMMENDED that implementations disable all the potentially dangerous features (e.g., agent forwarding, X11 forwarding, and TCP/IP forwarding) if the host key has changed without notice or explanation.
このプロトコルのための完全なセキュリティ問題を[SSH-ARCH]に提供します。 このドキュメントに特定です、ホストキーが通知も説明なしで変化したなら実装が、すべての潜在的に危険な特徴が(例えば、エージェント推進、X11推進、およびTCP/IP推進)であると無効にするのは、RECOMMENDEDです。
Ylonen & Lonvick Standards Track [Page 21] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[21ページ]。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Protocol Architecture", RFC 4251, January 2006.
[セキュアシェル (SSH)アーチ] YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))プロトコルアーキテクチャ」、RFC4251、1月2006日
[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Transport Layer Protocol", RFC 4253, January
2006.
[セキュアシェル (SSH)、-、移-、]、YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))トランスポート層プロトコル」、RFC4253、1月2006日
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Authentication Protocol", RFC 4252, January
2006.
[セキュアシェル (SSH)-USERAUTH] YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))認証プロトコル」、RFC4252、1月2006日
[SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell
(SSH) Protocol Assigned Numbers", RFC 4250, January
2006.
[セキュアシェル (SSH)番号] レーティネンとS.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))プロトコル規定番号」、RFC4250、1月2006日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H.、「言語の識別のためのタグ」、BCP47、RFC3066、2001年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
12.2. Informative References
12.2. 有益な参照
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330,
September 2002.
[RFC3330]IANA、「特別な使用IPv4アドレス」、RFC3330、2002年9月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version
6 (IPv6) Addressing Architecture", RFC 3513, April
2003.
[RFC3513]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[SCHEIFLER] Scheifler, R., "X Window System : The Complete
Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd
edition.", Digital Press ISBN 1555580882, February
1992.
[SCHEIFLER]Scheifler、R.、「Xウィンドウシステム:」 「XlibへのComplete Reference、Xプロトコル、Icccm、Xlfd、3番目の版」、Digital Press ISBN1555580882、2月1992日
Ylonen & Lonvick Standards Track [Page 22] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[22ページ]。
[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.
9945-1に[POSIX]ISO/IEC、「情報技術--携帯用のOperating System Interface(POSIX)第1部:、」 「システム適用業務プログラム・インタフェース(API)C言語」、ANSI/ IEE Std1003.1、1996年7月。
Authors' Addresses
作者のアドレス
Tatu Ylonen SSH Communications Security Corp Valimotie 17 00380 Helsinki Finland
Tatu Ylonenセキュアシェル (SSH)通信秘密保全Corp Valimotie17 00380ヘルシンキフィンランド
EMail: ylo@ssh.com
メール: ylo@ssh.com
Chris Lonvick (editor) Cisco Systems, Inc. 12515 Research Blvd. Austin 78759 USA
クリスLonvick(エディタ)シスコシステムズInc.12515研究Blvd. オースチン78759米国
EMail: clonvick@cisco.com
メール: clonvick@cisco.com
Trademark Notice
商標表示
"ssh" is a registered trademark in the United States and/or other countries.
「セキュアシェル (SSH)」は合衆国、そして/または、他国で登録商標です。
Ylonen & Lonvick Standards Track [Page 23] RFC 4254 SSH Connection Protocol January 2006
Ylonen&Lonvick規格はセキュアシェル (SSH)接続プロトコル2006年1月にRFC4254を追跡します[23ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Ylonen & Lonvick Standards Track [Page 24]
Ylonen&Lonvick標準化過程[24ページ]
一覧
スポンサーリンク
