aboutsummaryrefslogtreecommitdiffstats
path: root/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt
diff options
context:
space:
mode:
authorErlang/OTP <[email protected]>2009-11-20 14:54:40 +0000
committerErlang/OTP <[email protected]>2009-11-20 14:54:40 +0000
commit84adefa331c4159d432d22840663c38f155cd4c1 (patch)
treebff9a9c66adda4df2106dfd0e5c053ab182a12bd /lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt
downloadotp-84adefa331c4159d432d22840663c38f155cd4c1.tar.gz
otp-84adefa331c4159d432d22840663c38f155cd4c1.tar.bz2
otp-84adefa331c4159d432d22840663c38f155cd4c1.zip
The R13B03 release.OTP_R13B03
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.txt1232
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
+
+
+
+ Darren J. Moffat (editor)
+ Sun Microsystems, Inc
+ 17 Network Circle
+ Menlo Park CA 94025
+ USA
+
+
+
+
+
+
+
+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