diff options
Diffstat (limited to 'lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt')
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt | 1232 |
1 files changed, 1232 insertions, 0 deletions
diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt b/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt new file mode 100644 index 0000000000..1cb8ad6409 --- /dev/null +++ b/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt @@ -0,0 +1,1232 @@ + + + +Network Working Group T. Ylonen +Internet-Draft SSH Communications Security Corp +Expires: March 31, 2004 D. Moffat, Editor, Ed. + Sun Microsystems, Inc + Oct 2003 + + + SSH Connection Protocol + draft-ietf-secsh-connect-18.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on March 31, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + SSH is a protocol for secure remote login and other secure network + services over an insecure network. + + 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. + + The SSH Connection Protocol has been designed to run on top of the + SSH transport layer and user authentication protocols. + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 1] + +Internet-Draft SSH Connection Protocol Oct 2003 + + +Table of Contents + + 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Conventions Used in This Document . . . . . . . . . . . . . 3 + 4. Global Requests . . . . . . . . . . . . . . . . . . . . . . 3 + 5. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . 4 + 5.1 Opening a Channel . . . . . . . . . . . . . . . . . . . . . 4 + 5.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 5 + 5.3 Closing a Channel . . . . . . . . . . . . . . . . . . . . . 6 + 5.4 Channel-Specific Requests . . . . . . . . . . . . . . . . . 7 + 6. Interactive Sessions . . . . . . . . . . . . . . . . . . . . 8 + 6.1 Opening a Session . . . . . . . . . . . . . . . . . . . . . 8 + 6.2 Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . . 8 + 6.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 9 + 6.3.1 Requesting X11 Forwarding . . . . . . . . . . . . . . . . . 9 + 6.3.2 X11 Channels . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.4 Environment Variable Passing . . . . . . . . . . . . . . . . 10 + 6.5 Starting a Shell or a Command . . . . . . . . . . . . . . . 10 + 6.6 Session Data Transfer . . . . . . . . . . . . . . . . . . . 11 + 6.7 Window Dimension Change Message . . . . . . . . . . . . . . 12 + 6.8 Local Flow Control . . . . . . . . . . . . . . . . . . . . . 12 + 6.9 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.10 Returning Exit Status . . . . . . . . . . . . . . . . . . . 13 + 7. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . 14 + 7.1 Requesting Port Forwarding . . . . . . . . . . . . . . . . . 14 + 7.2 TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . . 15 + 8. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . 16 + 9. Summary of Message Numbers . . . . . . . . . . . . . . . . . 18 + 10. Security Considerations . . . . . . . . . . . . . . . . . . 18 + 11. iana cONSiderations . . . . . . . . . . . . . . . . . . . . 19 + 12. Intellectual Property . . . . . . . . . . . . . . . . . . . 19 + Normative References . . . . . . . . . . . . . . . . . . . . 19 + Informative References . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 + Intellectual Property and Copyright Statements . . . . . . . 21 + + + + + + + + + + + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 2] + +Internet-Draft SSH Connection Protocol Oct 2003 + + +1. Contributors + + The major original contributors of this document were: Tatu Ylonen, + Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications + Security Corp), and Markku-Juhani O. Saarinen (University of + Jyvaskyla) + + The document editor is: [email protected]. Comments on this + internet draft should be sent to the IETF SECSH working group, + details at: http://ietf.org/html.charters/secsh-charter.html + +2. Introduction + + The SSH Connection Protocol has been designed to run on top of the + SSH transport layer and user authentication protocols. It provides + interactive login sessions, remote execution of commands, forwarded + TCP/IP connections, and forwarded X11 connections. The service name + for this protocol is "ssh-connection". + + 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. + +3. Conventions Used in This Document + + The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", + and "MAY" that appear in this document are to be interpreted as + described in [RFC2119]. + + The used data types and terminology are specified in the architecture + document [SSH-ARCH]. + + The architecture document also discusses the algorithm naming + conventions that MUST be used with the SSH protocols. + +4. Global Requests + + 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. All such + requests use the following format. + + byte SSH_MSG_GLOBAL_REQUEST + string request name (restricted to US-ASCII) + boolean want reply + ... request-specific data follows + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 3] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + Request names follow the DNS extensibility naming convention outlined + in [SSH-ARCH]. + + The recipient will respond to this message with + SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if `want reply' is + TRUE. + + byte SSH_MSG_REQUEST_SUCCESS + ..... response specific data + + 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. + + byte SSH_MSG_REQUEST_FAILURE + + +5. Channel Mechanism + + 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 + + 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 (restricted to US-ASCII) + uint32 sender channel + uint32 initial window size + uint32 maximum packet size + ... channel type specific data follows + + The channel type is a name as described in the SSH architecture + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 4] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + document, with similar extension mechanisms. `sender channel' is a + local identifier for the channel used by the sender of this message. + `initial window size' specifies how many bytes of channel data can be + sent to the sender of this message without adjusting the window. + `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). + + The remote side then decides whether it can open the channel, and + responds with either + + 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 + + where `recipient channel' is the channel number given in the original + open request, and `sender channel' is the channel number allocated by + the other side, or + + byte SSH_MSG_CHANNEL_OPEN_FAILURE + uint32 recipient channel + uint32 reason code + string additional textual information (ISO-10646 UTF-8 [RFC2279]) + string language tag (as defined in [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 additional + information to the user. If this is done, the client software should + take the precautions discussed in [SSH-ARCH]. + + The following reason codes are defined: + + #define SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1 + #define SSH_OPEN_CONNECT_FAILED 2 + #define SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3 + #define SSH_OPEN_RESOURCE_SHORTAGE 4 + + +5.2 Data Transfer + + 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. + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 5] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + byte SSH_MSG_CHANNEL_WINDOW_ADJUST + uint32 recipient channel + uint32 bytes to add + + 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. + + Data transfer is done with messages of the following type. + + byte SSH_MSG_CHANNEL_DATA + uint32 recipient channel + string data + + The maximum amount of data allowed is the current window size. 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. + + 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 the data. The available types + and their interpretation depend on the type of the channel. + + byte SSH_MSG_CHANNEL_EXTENDED_DATA + uint32 recipient_channel + uint32 data_type_code + string data + + Data sent with these messages consumes the same window as ordinary + data. + + Currently, only the following type is defined. + + #define SSH_EXTENDED_DATA_STDERR 1 + + +5.3 Closing a Channel + + When a party will no longer send more data to a channel, it SHOULD + send SSH_MSG_CHANNEL_EOF. + + byte SSH_MSG_CHANNEL_EOF + uint32 recipient_channel + + 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 + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 6] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + 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. + + When either party wishes to terminate the channel, it sends + SSH_MSG_CHANNEL_CLOSE. Upon receiving this message, a party MUST + send back a 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. + + byte SSH_MSG_CHANNEL_CLOSE + uint32 recipient_channel + + This message does not consume window space and can be sent even if no + window space is available. + + It is recommended that any data sent before this message is delivered + to the actual destination, if possible. + +5.4 Channel-Specific Requests + + Many channel types have extensions that are specific to that + particular channel type. An example is requesting a pty (pseudo + terminal) for an interactive session. + + All channel-specific requests use the following format. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient channel + string request type (restricted to US-ASCII) + boolean want reply + ... type-specific data + + If want reply is FALSE, no response will be sent to the request. + Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS + or 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. + + This message does not consume window space and can be sent even if no + window space is available. Request types are local to each channel + type. + + The client is allowed to send further messages without waiting for + the response to the request. + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 7] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + request type names follow the DNS extensibility naming convention + outlined in [SSH-ARCH] + + byte SSH_MSG_CHANNEL_SUCCESS + uint32 recipient_channel + + + byte SSH_MSG_CHANNEL_FAILURE + uint32 recipient_channel + + These messages do not consume window space and can be sent even if no + window space is available. + +6. Interactive Sessions + + 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. + +6.1 Opening a Session + + 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 + + Client implementations SHOULD reject any session channel open + requests to make it more difficult for a corrupt server to attack the + client. + +6.2 Requesting a Pseudo-Terminal + + 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) + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 8] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + string encoded terminal modes + + The encoding of terminal modes is described in Section Encoding of + Terminal Modes (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. + + The dimension parameters are only informational. + + The client SHOULD ignore pty requests. + +6.3 X11 Forwarding + +6.3.1 Requesting X11 Forwarding + + X11 forwarding may be requested for a session by sending + + 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 + + It is recommended that the authentication cookie that is sent be a + fake, random cookie, and that the cookie is checked and replaced by + the real cookie when a connection request is received. + + 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. + + 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. + + The "x11 authentication protocol" is the name of the X11 + authentication method used, e.g. "MIT-MAGIC-COOKIE-1". + + The x11 authentication cookie MUST be hexadecimal encoded. + + X Protocol is documented in [SCHEIFLER]. + + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 9] + +Internet-Draft SSH Connection Protocol Oct 2003 + + +6.3.2 X11 Channels + + 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. + + 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 + + The recipient should respond with SSH_MSG_CHANNEL_OPEN_CONFIRMATION + or SSH_MSG_CHANNEL_OPEN_FAILURE. + + Implementations MUST reject any X11 channel open requests if they + have not requested X11 forwarding. + +6.4 Environment Variable Passing + + 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 + + +6.5 Starting a Shell or a Command + + 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. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient channel + string "shell" + boolean want reply + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 10] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + This message will request the user's default shell (typically defined + in /etc/passwd in UNIX systems) to be started at the other end. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient channel + string "exec" + boolean want reply + string command + + This message will request the server to 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 + + 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. + + It is RECOMMENDED to request and check the reply for these messages. + The client SHOULD ignore these messages. + + Subsystem names follow the DNS extensibility naming convention + outlined in [SSH-ARCH]. + +6.6 Session Data Transfer + + 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. + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 11] + +Internet-Draft SSH Connection Protocol Oct 2003 + + +6.7 Window Dimension Change Message + + 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 + + No response SHOULD be sent to this message. + +6.8 Local Flow Control + + 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.) + + 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. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient channel + string "xon-xoff" + boolean FALSE + boolean client can do + + No response is sent to this message. + +6.9 Signals + + 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. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient channel + string "signal" + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 12] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + boolean FALSE + string signal name without the "SIG" prefix. + + Signal names will be encoded as discussed in the "exit-signal" + SSH_MSG_CHANNEL_REQUEST. + +6.10 Returning Exit Status + + 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 acknowledgment is sent for + this message. The channel needs to be closed with + SSH_MSG_CHANNEL_CLOSE after this message. + + The client MAY ignore these messages. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient_channel + string "exit-status" + boolean FALSE + uint32 exit_status + + 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 (ISO-10646 UTF-8) + string language tag (as defined in [RFC3066]) + + The signal name is one of the following (these are from [POSIX]) + + ABRT + ALRM + FPE + HUP + ILL + INT + KILL + PIPE + QUIT + SEGV + TERM + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 13] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + USR1 + USR2 + + Additional signal names MAY be sent in the format "sig-name@xyz", + where `sig-name' and `xyz' may be anything a particular implementor + wants (except the `@' sign). However, it is suggested that if a + `configure' script is used, the non-standard signal names it finds be + encoded as "[email protected]", where `SIG' is the signal name + without the "SIG" prefix, and `xyz' be the host type, as determined + by `config.guess'. + + The `error message' contains an additional explanation of the error + message. The message may consist of multiple lines. 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]. + +7. TCP/IP Port Forwarding + +7.1 Requesting Port Forwarding + + 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 + + `Address to bind' and `port number to bind' specify the IP address + and port to which the socket to be listened is bound. The address + should be "0.0.0.0" if connections are allowed from anywhere. (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. + + + If a client passes 0 as port number to bind and has want reply TRUE + then the server allocates the next available unprivileged port number + and replies with the following message, otherwise there is no + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 14] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + response specific data. + + + byte SSH_MSG_GLOBAL_REQUEST_SUCCESS + uint32 port that was bound on the server + + A port forwarding can be cancelled 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 + + Client implementations SHOULD reject these messages; they are + normally only sent by the client. + +7.2 TCP/IP Forwarding Channels + + 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 + + Implementations MUST reject these messages unless they have + previously requested a remote TCP/IP port forwarding with the given + port number. + + 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 be sent also for ports for which no forwarding has been + explicitly requested. The receiving side must decide whether to + allow the forwarding. + + byte SSH_MSG_CHANNEL_OPEN + string "direct-tcpip" + uint32 sender channel + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 15] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + 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' and `port to connect' specify the TCP/IP host and + port where the recipient should connect the channel. `Host to + connect' may be either a domain name or a numeric IP address. + + `Originator IP address' is the numeric IP address of the machine + where the connection request comes from, and `originator port' is the + port on the originator host from where the connection came from. + + 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. + + Client implementations SHOULD reject direct TCP/IP open requests for + security reasons. + +8. Encoding of Terminal Modes + + 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 tty mode description is a stream of bytes. The stream consists + of opcode-argument pairs. It is terminated by opcode TTY_OP_END (0). + 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 client SHOULD put in the stream any modes it knows about, 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). + + The following opcodes have been defined. The naming of opcodes + mostly follows the POSIX terminal mode flags. + + 0 TTY_OP_END Indicates end of options. + 1 VINTR Interrupt character; 255 if none. Similarly for the + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 16] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + 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. + 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 set, 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. + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 17] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + 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). + 90 CS7 7 bit mode. + 91 CS8 8 bit mode. + 92 PARENB Parity enable. + 93 PARODD Odd parity, else even. + + 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. + + +9. Summary of Message Numbers + + #define SSH_MSG_GLOBAL_REQUEST 80 + #define SSH_MSG_REQUEST_SUCCESS 81 + #define SSH_MSG_REQUEST_FAILURE 82 + #define SSH_MSG_CHANNEL_OPEN 90 + #define SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 + #define SSH_MSG_CHANNEL_OPEN_FAILURE 92 + #define SSH_MSG_CHANNEL_WINDOW_ADJUST 93 + #define SSH_MSG_CHANNEL_DATA 94 + #define SSH_MSG_CHANNEL_EXTENDED_DATA 95 + #define SSH_MSG_CHANNEL_EOF 96 + #define SSH_MSG_CHANNEL_CLOSE 97 + #define SSH_MSG_CHANNEL_REQUEST 98 + #define SSH_MSG_CHANNEL_SUCCESS 99 + #define SSH_MSG_CHANNEL_FAILURE 100 + + +10. Security Considerations + + 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. + + 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. + + Full security considerations for this protocol are provided in + Section 8 of [SSH-ARCH] + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 18] + +Internet-Draft SSH Connection Protocol Oct 2003 + + +11. iana cONSiderations + + This document is part of a set, the IANA considerations for the SSH + protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], + [SSH-CONNECT] are detailed in [SSH-NUMBERS]. + +12. Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 Secretariat. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + +Normative References + + [SSH-ARCH] + Ylonen, T., "SSH Protocol Architecture", I-D + draft-ietf-architecture-15.txt, Oct 2003. + + [SSH-TRANS] + Ylonen, T., "SSH Transport Layer Protocol", I-D + draft-ietf-transport-17.txt, Oct 2003. + + [SSH-USERAUTH] + Ylonen, T., "SSH Authentication Protocol", I-D + draft-ietf-userauth-18.txt, Oct 2003. + + [SSH-CONNECT] + Ylonen, T., "SSH Connection Protocol", I-D + draft-ietf-connect-18.txt, Oct 2003. + + [SSH-NUMBERS] + Lehtinen, S. and D. Moffat, "SSH Protocol Assigned + Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 19] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + 2003. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +Informative References + + [RFC3066] Alvestrand, H., "Tags for the Identification of + Languages", BCP 47, RFC 3066, January 2001. + + [RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 1884, December 1995. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + [SCHEIFLER] + Scheifler, R., "X Window System : The Complete Reference + to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital + Press ISBN 1555580882, Feburary 1992. + + [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 + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: [email protected] + + + Darren J. Moffat (editor) + Sun Microsystems, Inc + 17 Network Circle + Menlo Park CA 94025 + USA + + EMail: [email protected] + + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 20] + +Internet-Draft SSH Connection Protocol Oct 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 21] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 22]
\ No newline at end of file |