draft-ietf-secsh-connect-18.txt

来自「OTP是开放电信平台的简称」· 文本 代码 · 共 1,232 行 · 第 1/3 页

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: [e-mail].  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