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, 0 insertions, 1232 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 deleted file mode 100644 index 1cb8ad6409..0000000000 --- a/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt +++ /dev/null @@ -1,1232 +0,0 @@ - - - -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 |