draft-ietf-secsh-filexfer-04.txt

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

Secure Shell Working Group                                  J. Galbraith
Internet-Draft                                          VanDyke Software
Expires: June 18, 2003                                         T. Ylonen
                                                             S. Lehtinen
                                        SSH Communications Security Corp
                                                       December 18, 2002


                       SSH File Transfer Protocol
                    draft-ietf-secsh-filexfer-04.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 June 18, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  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.







Galbraith, et al.        Expires June 18, 2003                  [Page 1]

Internet-Draft         SSH File Transfer Protocol          December 2002


Table of Contents

   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   3
   2.     Use with the SSH Connection Protocol . . . . . . . . . . .   4
   3.     General Packet Format  . . . . . . . . . . . . . . . . . .   5
   3.1    The use of stderr in the server  . . . . . . . . . . . . .   6
   4.     Protocol Initialization  . . . . . . . . . . . . . . . . .   8
   4.1    Client Initialization  . . . . . . . . . . . . . . . . . .   8
   4.2    Server Initialization  . . . . . . . . . . . . . . . . . .   8
   4.3    Determining Server Newline Convention  . . . . . . . . . .   9
   5.     File Attributes  . . . . . . . . . . . . . . . . . . . . .  10
   5.1    Flags  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.2    Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   5.3    Size . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   5.4    Owner and Group  . . . . . . . . . . . . . . . . . . . . .  11
   5.5    Permissions  . . . . . . . . . . . . . . . . . . . . . . .  12
   5.6    Times  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   5.7    ACL  . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   5.8    Extended attributes  . . . . . . . . . . . . . . . . . . .  14
   6.     Requests From the Client to the Server . . . . . . . . . .  15
   6.1    Request Synchronization and Reordering . . . . . . . . . .  15
   6.2    File Names . . . . . . . . . . . . . . . . . . . . . . . .  16
   6.3    Opening, Creating, and Closing Files . . . . . . . . . . .  16
   6.4    Reading and Writing  . . . . . . . . . . . . . . . . . . .  19
   6.5    Removing and Renaming Files  . . . . . . . . . . . . . . .  20
   6.6    Creating and Deleting Directories  . . . . . . . . . . . .  21
   6.7    Scanning Directories . . . . . . . . . . . . . . . . . . .  21
   6.8    Retrieving File Attributes . . . . . . . . . . . . . . . .  22
   6.9    Setting File Attributes  . . . . . . . . . . . . . . . . .  23
   6.10   Dealing with Symbolic links  . . . . . . . . . . . . . . .  24
   6.11   Canonicalizing the Server-Side Path Name . . . . . . . . .  25
   6.11.1 Best practice for dealing with paths . . . . . . . . . . .  25
   7.     Responses from the Server to the Client  . . . . . . . . .  26
   8.     Vendor-Specific Extensions . . . . . . . . . . . . . . . .  30
   9.     Security Considerations  . . . . . . . . . . . . . . . . .  31
   10.    Changes from previous protocol versions  . . . . . . . . .  32
   10.1   Changes between versions 4 and 3 . . . . . . . . . . . . .  32
   10.2   Changes between versions 3 and 2 . . . . . . . . . . . . .  33
   10.3   Changes between versions 2 and 1 . . . . . . . . . . . . .  33
   10.4   Changes between versions 1 and 0 . . . . . . . . . . . . .  33
   11.    Trademark Issues . . . . . . . . . . . . . . . . . . . . .  34
          References . . . . . . . . . . . . . . . . . . . . . . . .  35
          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  35
          Intellectual Property and Copyright Statements . . . . . .  37







Galbraith, et al.        Expires June 18, 2003                  [Page 2]

Internet-Draft         SSH File Transfer Protocol          December 2002


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 [5].

   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. [5]

   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.




















Galbraith, et al.        Expires June 18, 2003                  [Page 3]

Internet-Draft         SSH File Transfer Protocol          December 2002


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 [7] as a subsystem, as
   described in section ``Starting a Shell or a Command''.  The
   subsystem name used with this protocol is "sftp".













































Galbraith, et al.        Expires June 18, 2003                  [Page 4]

Internet-Draft         SSH File Transfer Protocol          December 2002


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.

   The following values are defined for packet types.















Galbraith, et al.        Expires June 18, 2003                  [Page 5]

Internet-Draft         SSH File Transfer Protocol          December 2002


   	#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

   	RESERVED_FOR_EXTENSIONS            210-255

   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.

3.1 The use of stderr in the server

   Packets are sent and received on stdout and stdin.  Data sent on
   stderr by the server SHOULD be considered debug or supplemental error
   information, and MAY be displayed to the user.

   For example, during initialization, there is no client request
   active, so errors or warning information cannot be sent to the client
   as part of the SFTP protocol at this early stage.  However, the



Galbraith, et al.        Expires June 18, 2003                  [Page 6]

Internet-Draft         SSH File Transfer Protocol          December 2002


   errors or warnings MAY be sent as stderr text.


















































Galbraith, et al.        Expires June 18, 2003                  [Page 7]

Internet-Draft         SSH File Transfer Protocol          December 2002


4. Protocol Initialization

   When the file transfer protocol starts, the client 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 version number of the protocol specified in this document is 4.
   The version number should be incremented for each incompatible