draft-ietf-secsh-filexfer-02.txt

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

Network Working Group                                          T. Ylonen
Internet-Draft                                               S. Lehtinen
Expires: April 1, 2002                  SSH Communications Security Corp
                                                            October 2001


                       SSH File Transfer Protocol
                    draft-ietf-secsh-filexfer-02.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 April 1, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   The SSH File Transfer Protocol provides secure file transfer
   functionality over any reliable data stream.  It is the standard file
   transfer protocol for use with the SSH2 protocol.  This document
   describes the file transfer protocol and its interface to the SSH2
   protocol suite.









Ylonen & Lehtinen         Expires April 1, 2002                 [Page 1]

Internet-Draft         SSH File Transfer Protocol           October 2001


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Use with the SSH Connection Protocol . . . . . . . . . . . .   4
   3.   General Packet Format  . . . . . . . . . . . . . . . . . . .   5
   4.   Protocol Initialization  . . . . . . . . . . . . . . . . . .   7
   5.   File Attributes  . . . . . . . . . . . . . . . . . . . . . .   8
   6.   Requests From the Client to the Server . . . . . . . . . . .  10
   6.1  Request Synchronization and Reordering . . . . . . . . . . .  10
   6.2  File Names . . . . . . . . . . . . . . . . . . . . . . . . .  11
   6.3  Opening, Creating, and Closing Files . . . . . . . . . . . .  11
   6.4  Reading and Writing  . . . . . . . . . . . . . . . . . . . .  13
   6.5  Removing and Renaming Files  . . . . . . . . . . . . . . . .  14
   6.6  Creating and Deleting Directories  . . . . . . . . . . . . .  15
   6.7  Scanning Directories . . . . . . . . . . . . . . . . . . . .  15
   6.8  Retrieving File Attributes . . . . . . . . . . . . . . . . .  16
   6.9  Setting File Attributes  . . . . . . . . . . . . . . . . . .  17
   6.10 Dealing with Symbolic links  . . . . . . . . . . . . . . . .  18
   6.11 Canonicalizing the Server-Side Path Name . . . . . . . . . .  18
   7.   Responses from the Server to the Client  . . . . . . . . . .  20
   8.   Vendor-Specific Extensions . . . . . . . . . . . . . . . . .  24
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  25
   10.  Changes from previous protocol versions  . . . . . . . . . .  26
   10.1 Changes between versions 3 and 2 . . . . . . . . . . . . . .  26
   10.2 Changes between versions 2 and 1 . . . . . . . . . . . . . .  26
   10.3 Changes between versions 1 and 0 . . . . . . . . . . . . . .  26
   11.  Trademark Issues . . . . . . . . . . . . . . . . . . . . . .  27
        References . . . . . . . . . . . . . . . . . . . . . . . . .  28
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  28
        Full Copyright Statement . . . . . . . . . . . . . . . . . .  29





















Ylonen & Lehtinen         Expires April 1, 2002                 [Page 2]

Internet-Draft         SSH File Transfer Protocol           October 2001


1. Introduction

   This protocol provides secure file transfer (and more generally file
   system access) functionality over a reliable data stream, such as a
   channel in the SSH2 protocol [3].

   This protocol is designed so that it could be used to implement a
   secure remote file system service, as well as a secure file transfer
   service.

   This protocol assumes that it runs over a secure channel, and that
   the server has already authenticated the user at the client end, and
   that the identity of the client user is externally available to the
   server implementation.

   In general, this protocol follows a simple request-response model.
   Each request and response contains a sequence number and multiple
   requests may be pending simultaneously.  There are a relatively large
   number of different request messages, but a small number of possible
   response messages.  Each request has one or more response messages
   that may be returned in result (e.g., a read either returns data or
   reports error status).

   The packet format descriptions in this specification follow the
   notation presented in the secsh architecture draft.[3].

   Even though this protocol is described in the context of the SSH2
   protocol, this protocol is general and independent of the rest of the
   SSH2 protocol suite.  It could be used in a number of different
   applications, such as secure file transfer over TLS RFC 2246 [1] and
   transfer of management information in VPN applications.




















Ylonen & Lehtinen         Expires April 1, 2002                 [Page 3]

Internet-Draft         SSH File Transfer Protocol           October 2001


2. Use with the SSH Connection Protocol

   When used with the SSH2 Protocol suite, this protocol is intended to
   be used from the SSH Connection Protocol [5] as a subsystem, as
   described in section ``Starting a Shell or a Command''.  The
   subsystem name used with this protocol is "sftp".













































Ylonen & Lehtinen         Expires April 1, 2002                 [Page 4]

Internet-Draft         SSH File Transfer Protocol           October 2001


3. General Packet Format

    All packets transmitted over the secure connection are of the
   following format:

   	uint32             length
   	byte               type
   	byte[length - 1]   data payload

   That is, they are just data preceded by 32-bit length and 8-bit type
   fields.  The `length' is the length of the data area, and does not
   include the `length' field itself.  The format and interpretation of
   the data area depends on the packet type.

   All packet descriptions below only specify the packet type and the
   data that goes into the data field.  Thus, they should be prefixed by
   the `length' and `type' fields.

   The maximum size of a packet is in practice determined by the client
   (the maximum size of read or write requests that it sends, plus a few
   bytes of packet overhead).  All servers SHOULD support packets of at
   least 34000 bytes (where the packet size refers to the full length,
   including the header above).  This should allow for reads and writes
   of at most 32768 bytes.

   There is no limit on the number of outstanding (non-acknowledged)
   requests that the client may send to the server.  In practice this is
   limited by the buffering available on the data stream and the queuing
   performed by the server.  If the server's queues are full, it should
   not read any more data from the stream, and flow control will prevent
   the client from sending more requests.  Note, however, that while
   there is no restriction on the protocol level, the client's API may
   provide a limit in order to prevent infinite queuing of outgoing
   requests at the client.

















Ylonen & Lehtinen         Expires April 1, 2002                 [Page 5]

Internet-Draft         SSH File Transfer Protocol           October 2001


   The following values are defined for packet types.

   	#define SSH_FXP_INIT                1
   	#define SSH_FXP_VERSION             2
   	#define SSH_FXP_OPEN                3
   	#define SSH_FXP_CLOSE               4
   	#define SSH_FXP_READ                5
   	#define SSH_FXP_WRITE               6
   	#define SSH_FXP_LSTAT               7
   	#define SSH_FXP_FSTAT               8
   	#define SSH_FXP_SETSTAT             9
   	#define SSH_FXP_FSETSTAT           10
   	#define SSH_FXP_OPENDIR            11
   	#define SSH_FXP_READDIR            12
   	#define SSH_FXP_REMOVE             13
   	#define SSH_FXP_MKDIR              14
   	#define SSH_FXP_RMDIR              15
   	#define SSH_FXP_REALPATH           16
   	#define SSH_FXP_STAT               17
   	#define SSH_FXP_RENAME             18
   	#define SSH_FXP_READLINK           19
   	#define SSH_FXP_SYMLINK            20
   	#define SSH_FXP_STATUS            101
   	#define SSH_FXP_HANDLE            102
   	#define SSH_FXP_DATA              103
   	#define SSH_FXP_NAME              104
   	#define SSH_FXP_ATTRS             105
   	#define SSH_FXP_EXTENDED          200
   	#define SSH_FXP_EXTENDED_REPLY    201

   Additional packet types should only be defined if the protocol
   version number (see Section ``Protocol Initialization'') is
   incremented, and their use MUST be negotiated using the version
   number.  However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY
   packets can be used to implement vendor-specific extensions.  See
   Section ``Vendor-Specific-Extensions'' for more details.















Ylonen & Lehtinen         Expires April 1, 2002                 [Page 6]

Internet-Draft         SSH File Transfer Protocol           October 2001


4. Protocol Initialization

   When the file transfer protocol starts, it first sends a SSH_FXP_INIT
   (including its version number) packet to the server.  The server
   responds with a SSH_FXP_VERSION packet, supplying the lowest of its
   own and the client's version number.  Both parties should from then
   on adhere to particular version of the protocol.

   The SSH_FXP_INIT packet (from client to server) has the following
   data:

   	uint32 version
   	<extension data>

    The SSH_FXP_VERSION packet (from server to client) has the following
   data:

   	uint32 version
   	<extension data>

   The version number of the protocol specified in this document is 3.
   The version number should be incremented for each incompatible
   revision of this protocol.

    The extension data in the above packets may be empty, or may be a
   sequence of

   	string extension_name
   	string extension_data

   pairs (both strings MUST always be present if one is, but the
   `extension_data' string may be of zero length).  If present, these
   strings indicate extensions to the baseline protocol.  The
   `extension_name' field(s) identify the name of the extension.  The
   name should be of the form "name@domain", where the domain is the DNS
   domain name of the organization defining the extension.  Additional
   names that are not of this format may be defined later by the IETF.
   Implementations MUST silently ignore any extensions whose name they
   do not recognize.












Ylonen & Lehtinen         Expires April 1, 2002                 [Page 7]

Internet-Draft         SSH File Transfer Protocol           October 2001


5. File Attributes

   A new compound data type is defined for encoding file attributes.  It
   is basically just a combination of elementary types, but is defined
   once because of the non-trivial description of the fields and to
   ensure maintainability.

   The same encoding is used both when returning file attributes from
   the server and when sending file attributes to the server.  When
   sending it to the server, the flags field specifies which attributes
   are included, and the server will use default values for the