diff options
Diffstat (limited to 'doc/draft-ietf-secsh-connect-17.txt')
| -rw-r--r-- | doc/draft-ietf-secsh-connect-17.txt | 1232 |
1 files changed, 1232 insertions, 0 deletions
diff --git a/doc/draft-ietf-secsh-connect-17.txt b/doc/draft-ietf-secsh-connect-17.txt new file mode 100644 index 00000000..5a8a43e0 --- /dev/null +++ b/doc/draft-ietf-secsh-connect-17.txt @@ -0,0 +1,1232 @@ + + +Network Working Group T. Ylonen +Internet-Draft T. Kivinen +Expires: January 12, 2004 SSH Communications Security Corp + M. Saarinen + University of Jyvaskyla + T. Rinne + S. Lehtinen + SSH Communications Security Corp + July 14, 2003 + + + SSH Connection Protocol + draft-ietf-secsh-connect-17.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 January 12, 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, + + + +Ylonen, et. al. Expires January 12, 2004 [Page 1] + +Internet-Draft SSH Connection Protocol July 2003 + + + 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Global Requests . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . 3 + 3.1 Opening a Channel . . . . . . . . . . . . . . . . . . . . . 4 + 3.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.3 Closing a Channel . . . . . . . . . . . . . . . . . . . . . 6 + 3.4 Channel-Specific Requests . . . . . . . . . . . . . . . . . 7 + 4. Interactive Sessions . . . . . . . . . . . . . . . . . . . . 8 + 4.1 Opening a Session . . . . . . . . . . . . . . . . . . . . . 8 + 4.2 Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . . 8 + 4.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.3.1 Requesting X11 Forwarding . . . . . . . . . . . . . . . . . 9 + 4.3.2 X11 Channels . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.4 Environment Variable Passing . . . . . . . . . . . . . . . . 10 + 4.5 Starting a Shell or a Command . . . . . . . . . . . . . . . 10 + 4.6 Session Data Transfer . . . . . . . . . . . . . . . . . . . 11 + 4.7 Window Dimension Change Message . . . . . . . . . . . . . . 11 + 4.8 Local Flow Control . . . . . . . . . . . . . . . . . . . . . 12 + 4.9 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.10 Returning Exit Status . . . . . . . . . . . . . . . . . . . 12 + 5. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . 14 + 5.1 Requesting Port Forwarding . . . . . . . . . . . . . . . . . 14 + 5.2 TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . . 15 + 6. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . 16 + 7. Summary of Message Numbers . . . . . . . . . . . . . . . . . 18 + 8. Security Considerations . . . . . . . . . . . . . . . . . . 18 + 9. Intellectual Property . . . . . . . . . . . . . . . . . . . 18 + 10. Additional Information . . . . . . . . . . . . . . . . . . . 19 + References . . . . . . . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 22 + + + + + + + + + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 2] + +Internet-Draft SSH Connection Protocol July 2003 + + + 1. 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 (after user authentication) 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. + + 2. 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 + + 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 + + + 3. Channel Mechanism + + All terminal sessions, forwarded connections, etc. are channels. + Either side may open a channel. Multiple channels are multiplexed + + + +Ylonen, et. al. Expires January 12, 2004 [Page 3] + +Internet-Draft SSH Connection Protocol July 2003 + + + 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. + + 3.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 + 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 + + + +Ylonen, et. al. Expires January 12, 2004 [Page 4] + +Internet-Draft SSH Connection Protocol July 2003 + + + 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 [RFC1766]) + + 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 + + + 3.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. + + 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. + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 5] + +Internet-Draft SSH Connection Protocol July 2003 + + + 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 + + + 3.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 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 + + + +Ylonen, et. al. Expires January 12, 2004 [Page 6] + +Internet-Draft SSH Connection Protocol July 2003 + + + no window space is available. + + It is recommended that any data sent before this message is + delivered to the actual destination, if possible. + + 3.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. + + 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. + + + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 7] + +Internet-Draft SSH Connection Protocol July 2003 + + + 4. 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. + + 4.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. + + 4.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) + string encoded terminal modes + + The encoding of terminal modes is described in Section Encoding of + Terminal Modes (Section 6). 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. + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 8] + +Internet-Draft SSH Connection Protocol July 2003 + + + 4.3 X11 Forwarding + + 4.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]. + + 4.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 + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 9] + +Internet-Draft SSH Connection Protocol July 2003 + + + 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. + + 4.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 + + + 4.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 + + 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 + + + +Ylonen, et. al. Expires January 12, 2004 [Page 10] + +Internet-Draft SSH Connection Protocol July 2003 + + + 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]. + + 4.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. + + 4.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 + + + +Ylonen, et. al. Expires January 12, 2004 [Page 11] + +Internet-Draft SSH Connection Protocol July 2003 + + + uint32 terminal width, pixels + uint32 terminal height, pixels + + No response SHOULD be sent to this message. + + 4.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. + + 4.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" + boolean FALSE + string signal name without the "SIG" prefix. + + Signal names will be encoded as discussed in the "exit-signal" + SSH_MSG_CHANNEL_REQUEST. + + 4.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 + + + +Ylonen, et. al. Expires January 12, 2004 [Page 12] + +Internet-Draft SSH Connection Protocol July 2003 + + + 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 [RFC1766]) + + The signal name is one of the following (these are from [POSIX]) + + ABRT + ALRM + FPE + HUP + ILL + INT + KILL + PIPE + QUIT + SEGV + TERM + 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 "SIG@xyz.config.guess", where `SIG' + is the signal name without the "SIG" prefix, and `xyz' be the host + + + +Ylonen, et. al. Expires January 12, 2004 [Page 13] + +Internet-Draft SSH Connection Protocol July 2003 + + + 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]. + + 5. TCP/IP Port Forwarding + + 5.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 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 + + + +Ylonen, et. al. Expires January 12, 2004 [Page 14] + +Internet-Draft SSH Connection Protocol July 2003 + + + 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. + + 5.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 + 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 + + + +Ylonen, et. al. Expires January 12, 2004 [Page 15] + +Internet-Draft SSH Connection Protocol July 2003 + + + 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. + + 6. 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 + 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. + + + +Ylonen, et. al. Expires January 12, 2004 [Page 16] + +Internet-Draft SSH Connection Protocol July 2003 + + + 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. + 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 + + + +Ylonen, et. al. Expires January 12, 2004 [Page 17] + +Internet-Draft SSH Connection Protocol July 2003 + + + (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. + + + 7. 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 + + + 8. 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] + + 9. 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 + + + +Ylonen, et. al. Expires January 12, 2004 [Page 18] + +Internet-Draft SSH Connection Protocol July 2003 + + + 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. + + 10. Additional Information + + The current document editor is: Darren.Moffat@Sun.COM. Comments + on this internet draft should be sent to the IETF SECSH working + group, details at: http://ietf.org/html.charters/secsh- + charter.html + +References + + [RFC1766] Alvestrand, H., "Tags for the Identification of + Languages", RFC 1766, March 1995. + + [RFC1884] Hinden, R., Deering, S. and Editors, "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. + + [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D + draft-ietf-architecture-14.txt, July 2003. + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 19] + +Internet-Draft SSH Connection Protocol July 2003 + + + [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D + draft-ietf-transport-16.txt, July 2003. + + [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D + draft-ietf-userauth-17.txt, July 2003. + + [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- + ietf-connect-17.txt, July 2003. + + [SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH Protocol Assigned + Numbers", I-D draft-ietf-secsh-assignednumbers- + 03.txt, July 2003. + + +Authors' Addresses + + Tatu Ylonen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: ylo@ssh.com + + + Tero Kivinen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: kivinen@ssh.com + + + Markku-Juhani O. Saarinen + University of Jyvaskyla + + + Timo J. Rinne + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: tri@ssh.com + + + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 20] + +Internet-Draft SSH Connection Protocol July 2003 + + + Sami Lehtinen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: sjl@ssh.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 21] + +Internet-Draft SSH Connection Protocol July 2003 + + +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 assigns. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 22] + |