Ticket #2902: blargh.diff

File blargh.diff, 52.8 KB (added by Michael Hudson-Doyle, 13 years ago)
  • twisted/conch/test/draft-ietf-secsh-filexfer-02.txt

     
     1
     2
     3Network Working Group                                          T. Ylonen
     4Internet-Draft                                               S. Lehtinen
     5Expires: April 1, 2002                  SSH Communications Security Corp
     6                                                            October 2001
     7
     8
     9                       SSH File Transfer Protocol
     10                    draft-ietf-secsh-filexfer-02.txt
     11
     12Status of this Memo
     13
     14   This document is an Internet-Draft and is in full conformance with
     15   all provisions of Section 10 of RFC2026.
     16
     17   Internet-Drafts are working documents of the Internet Engineering
     18   Task Force (IETF), its areas, and its working groups.  Note that
     19   other groups may also distribute working documents as Internet-
     20   Drafts.
     21
     22   Internet-Drafts are draft documents valid for a maximum of six months
     23   and may be updated, replaced, or obsoleted by other documents at any
     24   time.  It is inappropriate to use Internet-Drafts as reference
     25   material or to cite them other than as "work in progress."
     26
     27   The list of current Internet-Drafts can be accessed at http://
     28   www.ietf.org/ietf/1id-abstracts.txt.
     29
     30   The list of Internet-Draft Shadow Directories can be accessed at
     31   http://www.ietf.org/shadow.html.
     32
     33   This Internet-Draft will expire on April 1, 2002.
     34
     35Copyright Notice
     36
     37   Copyright (C) The Internet Society (2001).  All Rights Reserved.
     38
     39Abstract
     40
     41   The SSH File Transfer Protocol provides secure file transfer
     42   functionality over any reliable data stream.  It is the standard file
     43   transfer protocol for use with the SSH2 protocol.  This document
     44   describes the file transfer protocol and its interface to the SSH2
     45   protocol suite.
     46
     47
     48
     49
     50
     51
     52
     53
     54
     55Ylonen & Lehtinen         Expires April 1, 2002                 [Page 1]
     56
    057
     58Internet-Draft         SSH File Transfer Protocol           October 2001
     59
     60
     61Table of Contents
     62
     63   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
     64   2.   Use with the SSH Connection Protocol . . . . . . . . . . . .   4
     65   3.   General Packet Format  . . . . . . . . . . . . . . . . . . .   5
     66   4.   Protocol Initialization  . . . . . . . . . . . . . . . . . .   7
     67   5.   File Attributes  . . . . . . . . . . . . . . . . . . . . . .   8
     68   6.   Requests From the Client to the Server . . . . . . . . . . .  10
     69   6.1  Request Synchronization and Reordering . . . . . . . . . . .  10
     70   6.2  File Names . . . . . . . . . . . . . . . . . . . . . . . . .  11
     71   6.3  Opening, Creating, and Closing Files . . . . . . . . . . . .  11
     72   6.4  Reading and Writing  . . . . . . . . . . . . . . . . . . . .  13
     73   6.5  Removing and Renaming Files  . . . . . . . . . . . . . . . .  14
     74   6.6  Creating and Deleting Directories  . . . . . . . . . . . . .  15
     75   6.7  Scanning Directories . . . . . . . . . . . . . . . . . . . .  15
     76   6.8  Retrieving File Attributes . . . . . . . . . . . . . . . . .  16
     77   6.9  Setting File Attributes  . . . . . . . . . . . . . . . . . .  17
     78   6.10 Dealing with Symbolic links  . . . . . . . . . . . . . . . .  18
     79   6.11 Canonicalizing the Server-Side Path Name . . . . . . . . . .  18
     80   7.   Responses from the Server to the Client  . . . . . . . . . .  20
     81   8.   Vendor-Specific Extensions . . . . . . . . . . . . . . . . .  24
     82   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  25
     83   10.  Changes from previous protocol versions  . . . . . . . . . .  26
     84   10.1 Changes between versions 3 and 2 . . . . . . . . . . . . . .  26
     85   10.2 Changes between versions 2 and 1 . . . . . . . . . . . . . .  26
     86   10.3 Changes between versions 1 and 0 . . . . . . . . . . . . . .  26
     87   11.  Trademark Issues . . . . . . . . . . . . . . . . . . . . . .  27
     88        References . . . . . . . . . . . . . . . . . . . . . . . . .  28
     89        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  28
     90        Full Copyright Statement . . . . . . . . . . . . . . . . . .  29
     91
     92
     93
     94
     95
     96
     97
     98
     99
     100
     101
     102
     103
     104
     105
     106
     107
     108
     109
     110
     111
     112Ylonen & Lehtinen         Expires April 1, 2002                 [Page 2]
     113
    1114
     115Internet-Draft         SSH File Transfer Protocol           October 2001
     116
     117
     1181. Introduction
     119
     120   This protocol provides secure file transfer (and more generally file
     121   system access) functionality over a reliable data stream, such as a
     122   channel in the SSH2 protocol [3].
     123
     124   This protocol is designed so that it could be used to implement a
     125   secure remote file system service, as well as a secure file transfer
     126   service.
     127
     128   This protocol assumes that it runs over a secure channel, and that
     129   the server has already authenticated the user at the client end, and
     130   that the identity of the client user is externally available to the
     131   server implementation.
     132
     133   In general, this protocol follows a simple request-response model.
     134   Each request and response contains a sequence number and multiple
     135   requests may be pending simultaneously.  There are a relatively large
     136   number of different request messages, but a small number of possible
     137   response messages.  Each request has one or more response messages
     138   that may be returned in result (e.g., a read either returns data or
     139   reports error status).
     140
     141   The packet format descriptions in this specification follow the
     142   notation presented in the secsh architecture draft.[3].
     143
     144   Even though this protocol is described in the context of the SSH2
     145   protocol, this protocol is general and independent of the rest of the
     146   SSH2 protocol suite.  It could be used in a number of different
     147   applications, such as secure file transfer over TLS RFC 2246 [1] and
     148   transfer of management information in VPN applications.
     149
     150
     151
     152
     153
     154
     155
     156
     157
     158
     159
     160
     161
     162
     163
     164
     165
     166
     167
     168
     169Ylonen & Lehtinen         Expires April 1, 2002                 [Page 3]
     170
    2171
     172Internet-Draft         SSH File Transfer Protocol           October 2001
     173
     174
     1752. Use with the SSH Connection Protocol
     176
     177   When used with the SSH2 Protocol suite, this protocol is intended to
     178   be used from the SSH Connection Protocol [5] as a subsystem, as
     179   described in section ``Starting a Shell or a Command''.  The
     180   subsystem name used with this protocol is "sftp".
     181
     182
     183
     184
     185
     186
     187
     188
     189
     190
     191
     192
     193
     194
     195
     196
     197
     198
     199
     200
     201
     202
     203
     204
     205
     206
     207
     208
     209
     210
     211
     212
     213
     214
     215
     216
     217
     218
     219
     220
     221
     222
     223
     224
     225
     226Ylonen & Lehtinen         Expires April 1, 2002                 [Page 4]
     227
    3228
     229Internet-Draft         SSH File Transfer Protocol           October 2001
     230
     231
     2323. General Packet Format
     233
     234    All packets transmitted over the secure connection are of the
     235   following format:
     236
     237        uint32             length
     238        byte               type
     239        byte[length - 1]   data payload
     240
     241   That is, they are just data preceded by 32-bit length and 8-bit type
     242   fields.  The `length' is the length of the data area, and does not
     243   include the `length' field itself.  The format and interpretation of
     244   the data area depends on the packet type.
     245
     246   All packet descriptions below only specify the packet type and the
     247   data that goes into the data field.  Thus, they should be prefixed by
     248   the `length' and `type' fields.
     249
     250   The maximum size of a packet is in practice determined by the client
     251   (the maximum size of read or write requests that it sends, plus a few
     252   bytes of packet overhead).  All servers SHOULD support packets of at
     253   least 34000 bytes (where the packet size refers to the full length,
     254   including the header above).  This should allow for reads and writes
     255   of at most 32768 bytes.
     256
     257   There is no limit on the number of outstanding (non-acknowledged)
     258   requests that the client may send to the server.  In practice this is
     259   limited by the buffering available on the data stream and the queuing
     260   performed by the server.  If the server's queues are full, it should
     261   not read any more data from the stream, and flow control will prevent
     262   the client from sending more requests.  Note, however, that while
     263   there is no restriction on the protocol level, the client's API may
     264   provide a limit in order to prevent infinite queuing of outgoing
     265   requests at the client.
     266
     267
     268
     269
     270
     271
     272
     273
     274
     275
     276
     277
     278
     279
     280
     281
     282
     283Ylonen & Lehtinen         Expires April 1, 2002                 [Page 5]
     284
    4285
     286Internet-Draft         SSH File Transfer Protocol           October 2001
     287
     288
     289   The following values are defined for packet types.
     290
     291        #define SSH_FXP_INIT                1
     292        #define SSH_FXP_VERSION             2
     293        #define SSH_FXP_OPEN                3
     294        #define SSH_FXP_CLOSE               4
     295        #define SSH_FXP_READ                5
     296        #define SSH_FXP_WRITE               6
     297        #define SSH_FXP_LSTAT               7
     298        #define SSH_FXP_FSTAT               8
     299        #define SSH_FXP_SETSTAT             9
     300        #define SSH_FXP_FSETSTAT           10
     301        #define SSH_FXP_OPENDIR            11
     302        #define SSH_FXP_READDIR            12
     303        #define SSH_FXP_REMOVE             13
     304        #define SSH_FXP_MKDIR              14
     305        #define SSH_FXP_RMDIR              15
     306        #define SSH_FXP_REALPATH           16
     307        #define SSH_FXP_STAT               17
     308        #define SSH_FXP_RENAME             18
     309        #define SSH_FXP_READLINK           19
     310        #define SSH_FXP_SYMLINK            20
     311        #define SSH_FXP_STATUS            101
     312        #define SSH_FXP_HANDLE            102
     313        #define SSH_FXP_DATA              103
     314        #define SSH_FXP_NAME              104
     315        #define SSH_FXP_ATTRS             105
     316        #define SSH_FXP_EXTENDED          200
     317        #define SSH_FXP_EXTENDED_REPLY    201
     318
     319   Additional packet types should only be defined if the protocol
     320   version number (see Section ``Protocol Initialization'') is
     321   incremented, and their use MUST be negotiated using the version
     322   number.  However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY
     323   packets can be used to implement vendor-specific extensions.  See
     324   Section ``Vendor-Specific-Extensions'' for more details.
     325
     326
     327
     328
     329
     330
     331
     332
     333
     334
     335
     336
     337
     338
     339
     340Ylonen & Lehtinen         Expires April 1, 2002                 [Page 6]
     341
    5342
     343Internet-Draft         SSH File Transfer Protocol           October 2001
     344
     345
     3464. Protocol Initialization
     347
     348   When the file transfer protocol starts, it first sends a SSH_FXP_INIT
     349   (including its version number) packet to the server.  The server
     350   responds with a SSH_FXP_VERSION packet, supplying the lowest of its
     351   own and the client's version number.  Both parties should from then
     352   on adhere to particular version of the protocol.
     353
     354   The SSH_FXP_INIT packet (from client to server) has the following
     355   data:
     356
     357        uint32 version
     358        <extension data>
     359
     360    The SSH_FXP_VERSION packet (from server to client) has the following
     361   data:
     362
     363        uint32 version
     364        <extension data>
     365
     366   The version number of the protocol specified in this document is 3.
     367   The version number should be incremented for each incompatible
     368   revision of this protocol.
     369
     370    The extension data in the above packets may be empty, or may be a
     371   sequence of
     372
     373        string extension_name
     374        string extension_data
     375
     376   pairs (both strings MUST always be present if one is, but the
     377   `extension_data' string may be of zero length).  If present, these
     378   strings indicate extensions to the baseline protocol.  The
     379   `extension_name' field(s) identify the name of the extension.  The
     380   name should be of the form "name@domain", where the domain is the DNS
     381   domain name of the organization defining the extension.  Additional
     382   names that are not of this format may be defined later by the IETF.
     383   Implementations MUST silently ignore any extensions whose name they
     384   do not recognize.
     385
     386
     387
     388
     389
     390
     391
     392
     393
     394
     395
     396
     397Ylonen & Lehtinen         Expires April 1, 2002                 [Page 7]
     398
    6399
     400Internet-Draft         SSH File Transfer Protocol           October 2001
     401
     402
     4035. File Attributes
     404
     405   A new compound data type is defined for encoding file attributes.  It
     406   is basically just a combination of elementary types, but is defined
     407   once because of the non-trivial description of the fields and to
     408   ensure maintainability.
     409
     410   The same encoding is used both when returning file attributes from
     411   the server and when sending file attributes to the server.  When
     412   sending it to the server, the flags field specifies which attributes
     413   are included, and the server will use default values for the
     414   remaining attributes (or will not modify the values of remaining
     415   attributes).  When receiving attributes from the server, the flags
     416   specify which attributes are included in the returned data.  The
     417   server normally returns all attributes it knows about.
     418
     419        uint32   flags
     420        uint64   size           present only if flag SSH_FILEXFER_ATTR_SIZE
     421        uint32   uid            present only if flag SSH_FILEXFER_ATTR_UIDGID
     422        uint32   gid            present only if flag SSH_FILEXFER_ATTR_UIDGID
     423        uint32   permissions    present only if flag SSH_FILEXFER_ATTR_PERMISSIONS
     424        uint32   atime          present only if flag SSH_FILEXFER_ACMODTIME
     425        uint32   mtime          present only if flag SSH_FILEXFER_ACMODTIME
     426        uint32   extended_count present only if flag SSH_FILEXFER_ATTR_EXTENDED
     427        string   extended_type
     428        string   extended_data
     429        ...      more extended data (extended_type - extended_data pairs),
     430                   so that number of pairs equals extended_count
     431
     432   The `flags' specify which of the fields are present.  Those fields
     433   for which the corresponding flag is not set are not present (not
     434   included in the packet).  New flags can only be added by incrementing
     435   the protocol version number (or by using the extension mechanism
     436   described below).
     437
     438   The `size' field specifies the size of the file in bytes.
     439
     440   The `uid' and `gid' fields contain numeric Unix-like user and group
     441   identifiers, respectively.
     442
     443   The `permissions' field contains a bit mask of file permissions as
     444   defined by posix [1].
     445
     446   The `atime' and `mtime' contain the access and modification times of
     447   the files, respectively.  They are represented as seconds from Jan 1,
     448   1970 in UTC.
     449
     450   The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension
     451
     452
     453
     454Ylonen & Lehtinen         Expires April 1, 2002                 [Page 8]
     455
    7456
     457Internet-Draft         SSH File Transfer Protocol           October 2001
     458
     459
     460   mechanism for vendor-specific extensions.  If the flag is specified,
     461   then the `extended_count' field is present.  It specifies the number
     462   of extended_type-extended_data pairs that follow.  Each of these
     463   pairs specifies an extended attribute.  For each of the attributes,
     464   the extended_type field should be a string of the format
     465   "name@domain", where "domain" is a valid, registered domain name and
     466   "name" identifies the method.  The IETF may later standardize certain
     467   names that deviate from this format (e.g., that do not contain the
     468   "@" sign).  The interpretation of `extended_data' depends on the
     469   type.  Implementations SHOULD ignore extended data fields that they
     470   do not understand.
     471
     472   Additional fields can be added to the attributes by either defining
     473   additional bits to the flags field to indicate their presence, or by
     474   defining extended attributes for them.  The extended attributes
     475   mechanism is recommended for most purposes; additional flags bits
     476   should only be defined by an IETF standards action that also
     477   increments the protocol version number.  The use of such new fields
     478   MUST be negotiated by the version number in the protocol exchange.
     479   It is a protocol error if a packet with unsupported protocol bits is
     480   received.
     481
     482    The flags bits are defined to have the following values:
     483
     484        #define SSH_FILEXFER_ATTR_SIZE          0x00000001
     485        #define SSH_FILEXFER_ATTR_UIDGID        0x00000002
     486        #define SSH_FILEXFER_ATTR_PERMISSIONS   0x00000004
     487        #define SSH_FILEXFER_ATTR_ACMODTIME     0x00000008
     488        #define SSH_FILEXFER_ATTR_EXTENDED      0x80000000
     489
     490
     491
     492
     493
     494
     495
     496
     497
     498
     499
     500
     501
     502
     503
     504
     505
     506
     507
     508
     509
     510
     511Ylonen & Lehtinen         Expires April 1, 2002                 [Page 9]
     512
    8513
     514Internet-Draft         SSH File Transfer Protocol           October 2001
     515
     516
     5176. Requests From the Client to the Server
     518
     519   Requests from the client to the server represent the various file
     520   system operations.  Each request begins with an `id' field, which is
     521   a 32-bit identifier identifying the request (selected by the client).
     522   The same identifier will be returned in the response to the request.
     523   One possible implementation of it is a monotonically increasing
     524   request sequence number (modulo 2^32).
     525
     526   Many operations in the protocol operate on open files.  The
     527   SSH_FXP_OPEN request can return a file handle (which is an opaque
     528   variable-length string) which may be used to access the file later
     529   (e.g.  in a read operation).  The client MUST NOT send requests the
     530   server with bogus or closed handles.  However, the server MUST
     531   perform adequate checks on the handle in order to avoid security
     532   risks due to fabricated handles.
     533
     534   This design allows either stateful and stateless server
     535   implementation, as well as an implementation which caches state
     536   between requests but may also flush it.  The contents of the file
     537   handle string are entirely up to the server and its design.  The
     538   client should not modify or attempt to interpret the file handle
     539   strings.
     540
     541   The file handle strings MUST NOT be longer than 256 bytes.
     542
     5436.1 Request Synchronization and Reordering
     544
     545   The protocol and implementations MUST process requests relating to
     546   the same file in the order in which they are received.  In other
     547   words, if an application submits multiple requests to the server, the
     548   results in the responses will be the same as if it had sent the
     549   requests one at a time and waited for the response in each case.  For
     550   example, the server may process non-overlapping read/write requests
     551   to the same file in parallel, but overlapping reads and writes cannot
     552   be reordered or parallelized.  However, there are no ordering
     553   restrictions on the server for processing requests from two different
     554   file transfer connections.  The server may interleave and parallelize
     555   them at will.
     556
     557   There are no restrictions on the order in which responses to
     558   outstanding requests are delivered to the client, except that the
     559   server must ensure fairness in the sense that processing of no
     560   request will be indefinitely delayed even if the client is sending
     561   other requests so that there are multiple outstanding requests all
     562   the time.
     563
     564
     565
     566
     567
     568Ylonen & Lehtinen         Expires April 1, 2002                [Page 10]
     569
    9570
     571Internet-Draft         SSH File Transfer Protocol           October 2001
     572
     573
     5746.2 File Names
     575
     576   This protocol represents file names as strings.  File names are
     577   assumed to use the slash ('/') character as a directory separator.
     578
     579   File names starting with a slash are "absolute", and are relative to
     580   the root of the file system.  Names starting with any other character
     581   are relative to the user's default directory (home directory).  Note
     582   that identifying the user is assumed to take place outside of this
     583   protocol.
     584
     585   Servers SHOULD interpret a path name component ".." as referring to
     586   the parent directory, and "." as referring to the current directory.
     587   If the server implementation limits access to certain parts of the
     588   file system, it must be extra careful in parsing file names when
     589   enforcing such restrictions.  There have been numerous reported
     590   security bugs where a ".." in a path name has allowed access outside
     591   the intended area.
     592
     593   An empty path name is valid, and it refers to the user's default
     594   directory (usually the user's home directory).
     595
     596   Otherwise, no syntax is defined for file names by this specification.
     597   Clients should not make any other assumptions; however, they can
     598   splice path name components returned by SSH_FXP_READDIR together
     599   using a slash ('/') as the separator, and that will work as expected.
     600
     601   It is understood that the lack of well-defined semantics for file
     602   names may cause interoperability problems between clients and servers
     603   using radically different operating systems.  However, this approach
     604   is known to work acceptably with most systems, and alternative
     605   approaches that e.g.  treat file names as sequences of structured
     606   components are quite complicated.
     607
     6086.3 Opening, Creating, and Closing Files
     609
     610    Files are opened and created using the SSH_FXP_OPEN message, whose
     611   data part is as follows:
     612
     613        uint32        id
     614        string        filename
     615        uint32        pflags
     616        ATTRS         attrs
     617
     618   The `id' field is the request identifier as for all requests.
     619
     620   The `filename' field specifies the file name.  See Section ``File
     621   Names'' for more information.
     622
     623
     624
     625Ylonen & Lehtinen         Expires April 1, 2002                [Page 11]
     626
    10627
     628Internet-Draft         SSH File Transfer Protocol           October 2001
     629
     630
     631    The `pflags' field is a bitmask.  The following bits have been
     632   defined.
     633
     634        #define SSH_FXF_READ            0x00000001
     635        #define SSH_FXF_WRITE           0x00000002
     636        #define SSH_FXF_APPEND          0x00000004
     637        #define SSH_FXF_CREAT           0x00000008
     638        #define SSH_FXF_TRUNC           0x00000010
     639        #define SSH_FXF_EXCL            0x00000020
     640
     641   These have the following meanings:
     642
     643   SSH_FXF_READ
     644      Open the file for reading.
     645
     646   SSH_FXF_WRITE
     647      Open the file for writing.  If both this and SSH_FXF_READ are
     648      specified, the file is opened for both reading and writing.
     649
     650   SSH_FXF_APPEND
     651      Force all writes to append data at the end of the file.
     652
     653   SSH_FXF_CREAT
     654      If this flag is specified, then a new file will be created if one
     655      does not already exist (if O_TRUNC is specified, the new file will
     656      be truncated to zero length if it previously exists).
     657
     658   SSH_FXF_TRUNC
     659      Forces an existing file with the same name to be truncated to zero
     660      length when creating a file by specifying SSH_FXF_CREAT.
     661      SSH_FXF_CREAT MUST also be specified if this flag is used.
     662
     663   SSH_FXF_EXCL
     664      Causes the request to fail if the named file already exists.
     665      SSH_FXF_CREAT MUST also be specified if this flag is used.
     666
     667   The `attrs' field specifies the initial attributes for the file.
     668   Default values will be used for those attributes that are not
     669   specified.  See Section ``File Attributes'' for more information.
     670
     671   Regardless the server operating system, the file will always be
     672   opened in "binary" mode (i.e., no translations between different
     673   character sets and newline encodings).
     674
     675   The response to this message will be either SSH_FXP_HANDLE (if the
     676   operation is successful) or SSH_FXP_STATUS (if the operation fails).
     677
     678
     679
     680
     681
     682Ylonen & Lehtinen         Expires April 1, 2002                [Page 12]
     683
    11684
     685Internet-Draft         SSH File Transfer Protocol           October 2001
     686
     687
     688    A file is closed by using the SSH_FXP_CLOSE request.  Its data field
     689   has the following format:
     690
     691        uint32     id
     692        string     handle
     693
     694   where `id' is the request identifier, and `handle' is a handle
     695   previously returned in the response to SSH_FXP_OPEN or
     696   SSH_FXP_OPENDIR.  The handle becomes invalid immediately after this
     697   request has been sent.
     698
     699   The response to this request will be a SSH_FXP_STATUS message.  One
     700   should note that on some server platforms even a close can fail.
     701   This can happen e.g.  if the server operating system caches writes,
     702   and an error occurs while flushing cached writes during the close.
     703
     7046.4 Reading and Writing
     705
     706    Once a file has been opened, it can be read using the SSH_FXP_READ
     707   message, which has the following format:
     708
     709        uint32     id
     710        string     handle
     711        uint64     offset
     712        uint32     len
     713
     714   where `id' is the request identifier, `handle' is an open file handle
     715   returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative
     716   to the beginning of the file from where to start reading, and `len'
     717   is the maximum number of bytes to read.
     718
     719   In response to this request, the server will read as many bytes as it
     720   can from the file (up to `len'), and return them in a SSH_FXP_DATA
     721   message.  If an error occurs or EOF is encountered before reading any
     722   data, the server will respond with SSH_FXP_STATUS.  For normal disk
     723   files, it is guaranteed that this will read the specified number of
     724   bytes, or up to end of file.  For e.g.  device files this may return
     725   fewer bytes than requested.
     726
     727    Writing to a file is achieved using the SSH_FXP_WRITE message, which
     728   has the following format:
     729
     730        uint32     id
     731        string     handle
     732        uint64     offset
     733        string     data
     734
     735   where `id' is a request identifier, `handle' is a file handle
     736
     737
     738
     739Ylonen & Lehtinen         Expires April 1, 2002                [Page 13]
     740
    12741
     742Internet-Draft         SSH File Transfer Protocol           October 2001
     743
     744
     745   returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the
     746   beginning of the file where to start writing, and `data' is the data
     747   to be written.
     748
     749   The write will extend the file if writing beyond the end of the file.
     750   It is legal to write way beyond the end of the file; the semantics
     751   are to write zeroes from the end of the file to the specified offset
     752   and then the data.  On most operating systems, such writes do not
     753   allocate disk space but instead leave "holes" in the file.
     754
     755   The server responds to a write request with a SSH_FXP_STATUS message.
     756
     7576.5 Removing and Renaming Files
     758
     759    Files can be removed using the SSH_FXP_REMOVE message.  It has the
     760   following format:
     761
     762        uint32     id
     763        string     filename
     764
     765   where `id' is the request identifier and `filename' is the name of
     766   the file to be removed.  See Section ``File Names'' for more
     767   information.  This request cannot be used to remove directories.
     768
     769   The server will respond to this request with a SSH_FXP_STATUS
     770   message.
     771
     772    Files (and directories) can be renamed using the SSH_FXP_RENAME
     773   message.  Its data is as follows:
     774
     775        uint32     id
     776        string     oldpath
     777        string     newpath
     778
     779   where `id' is the request identifier, `oldpath' is the name of an
     780   existing file or directory, and `newpath' is the new name for the
     781   file or directory.  It is an error if there already exists a file
     782   with the name specified by newpath.  The server may also fail rename
     783   requests in other situations, for example if `oldpath' and `newpath'
     784   point to different file systems on the server.
     785
     786   The server will respond to this request with a SSH_FXP_STATUS
     787   message.
     788
     789
     790
     791
     792
     793
     794
     795
     796Ylonen & Lehtinen         Expires April 1, 2002                [Page 14]
     797
    13798
     799Internet-Draft         SSH File Transfer Protocol           October 2001
     800
     801
     8026.6 Creating and Deleting Directories
     803
     804    New directories can be created using the SSH_FXP_MKDIR request.  It
     805   has the following format:
     806
     807        uint32     id
     808        string     path
     809        ATTRS      attrs
     810
     811   where `id' is the request identifier, `path' and `attrs' specifies
     812   the modifications to be made to its attributes.  See Section ``File
     813   Names'' for more information on file names.  Attributes are discussed
     814   in more detail in Section ``File Attributes''.  specifies the
     815   directory to be created.  An error will be returned if a file or
     816   directory with the specified path already exists.  The server will
     817   respond to this request with a SSH_FXP_STATUS message.
     818
     819    Directories can be removed using the SSH_FXP_RMDIR request, which
     820   has the following format:
     821
     822        uint32     id
     823        string     path
     824
     825   where `id' is the request identifier, and `path' specifies the
     826   directory to be removed.  See Section ``File Names'' for more
     827   information on file names.  An error will be returned if no directory
     828   with the specified path exists, or if the specified directory is not
     829   empty, or if the path specified a file system object other than a
     830   directory.  The server responds to this request with a SSH_FXP_STATUS
     831   message.
     832
     8336.7 Scanning Directories
     834
     835   The files in a directory can be listed using the SSH_FXP_OPENDIR and
     836   SSH_FXP_READDIR requests.  Each SSH_FXP_READDIR request returns one
     837   or more file names with full file attributes for each file.  The
     838   client should call SSH_FXP_READDIR repeatedly until it has found the
     839   file it is looking for or until the server responds with a
     840   SSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF if
     841   there are no more files in the directory).  The client should then
     842   close the handle using the SSH_FXP_CLOSE request.
     843
     844
     845
     846
     847
     848
     849
     850
     851
     852
     853Ylonen & Lehtinen         Expires April 1, 2002                [Page 15]
     854
    14855
     856Internet-Draft         SSH File Transfer Protocol           October 2001
     857
     858
     859    The SSH_FXP_OPENDIR opens a directory for reading.  It has the
     860   following format:
     861
     862        uint32     id
     863        string     path
     864
     865   where `id' is the request identifier and `path' is the path name of
     866   the directory to be listed (without any trailing slash).  See Section
     867   ``File Names'' for more information on file names.  This will return
     868   an error if the path does not specify a directory or if the directory
     869   is not readable.  The server will respond to this request with either
     870   a SSH_FXP_HANDLE or a SSH_FXP_STATUS message.
     871
     872    Once the directory has been successfully opened, files (and
     873   directories) contained in it can be listed using SSH_FXP_READDIR
     874   requests.  These are of the format
     875
     876        uint32     id
     877        string     handle
     878
     879   where `id' is the request identifier, and `handle' is a handle
     880   returned by SSH_FXP_OPENDIR.  (It is a protocol error to attempt to
     881   use an ordinary file handle returned by SSH_FXP_OPEN.)
     882
     883   The server responds to this request with either a SSH_FXP_NAME or a
     884   SSH_FXP_STATUS message.  One or more names may be returned at a time.
     885   Full status information is returned for each name in order to speed
     886   up typical directory listings.
     887
     888   When the client no longer wishes to read more names from the
     889   directory, it SHOULD call SSH_FXP_CLOSE for the handle.  The handle
     890   should be closed regardless of whether an error has occurred or not.
     891
     8926.8 Retrieving File Attributes
     893
     894   Very often, file attributes are automatically returned by
     895   SSH_FXP_READDIR.  However, sometimes there is need to specifically
     896   retrieve the attributes for a named file.  This can be done using the
     897   SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests.
     898
     899    SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT
     900   follows symbolic links on the server, whereas SSH_FXP_LSTAT does not
     901   follow symbolic links.  Both have the same format:
     902
     903        uint32     id
     904        string     path
     905
     906   where `id' is the request identifier, and `path' specifies the file
     907
     908
     909
     910Ylonen & Lehtinen         Expires April 1, 2002                [Page 16]
     911
    15912
     913Internet-Draft         SSH File Transfer Protocol           October 2001
     914
     915
     916   system object for which status is to be returned.  The server
     917   responds to this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS.
     918
     919    SSH_FXP_FSTAT differs from the others in that it returns status
     920   information for an open file (identified by the file handle).  Its
     921   format is as follows:
     922
     923        uint32     id
     924        string     handle
     925
     926   where `id' is the request identifier and `handle' is a file handle
     927   returned by SSH_FXP_OPEN.  The server responds to this request with
     928   SSH_FXP_ATTRS or SSH_FXP_STATUS.
     929
     9306.9 Setting File Attributes
     931
     932   File attributes may be modified using the SSH_FXP_SETSTAT and
     933   SSH_FXP_FSETSTAT requests.  These requests are used for operations
     934   such as changing the ownership, permissions or access times, as well
     935   as for truncating a file.
     936
     937    The SSH_FXP_SETSTAT request is of the following format:
     938
     939        uint32     id
     940        string     path
     941        ATTRS      attrs
     942
     943   where `id' is the request identifier, `path' specifies the file
     944   system object (e.g.  file or directory) whose attributes are to be
     945   modified, and `attrs' specifies the modifications to be made to its
     946   attributes.  Attributes are discussed in more detail in Section
     947   ``File Attributes''.
     948
     949   An error will be returned if the specified file system object does
     950   not exist or the user does not have sufficient rights to modify the
     951   specified attributes.  The server responds to this request with a
     952   SSH_FXP_STATUS message.
     953
     954    The SSH_FXP_FSETSTAT request modifies the attributes of a file which
     955   is already open.  It has the following format:
     956
     957        uint32     id
     958        string     handle
     959        ATTRS      attrs
     960
     961   where `id' is the request identifier, `handle' (MUST be returned by
     962   SSH_FXP_OPEN) identifies the file whose attributes are to be
     963   modified, and `attrs' specifies the modifications to be made to its
     964
     965
     966
     967Ylonen & Lehtinen         Expires April 1, 2002                [Page 17]
     968
    16969
     970Internet-Draft         SSH File Transfer Protocol           October 2001
     971
     972
     973   attributes.  Attributes are discussed in more detail in Section
     974   ``File Attributes''.  The server will respond to this request with
     975   SSH_FXP_STATUS.
     976
     9776.10 Dealing with Symbolic links
     978
     979    The SSH_FXP_READLINK request may be used to read the target of a
     980   symbolic link.  It would have a data part as follows:
     981
     982        uint32     id
     983        string     path
     984
     985   where `id' is the request identifier and `path' specifies the path
     986   name of the symlink to be read.
     987
     988   The server will respond with a SSH_FXP_NAME packet containing only
     989   one name and a dummy attributes value.  The name in the returned
     990   packet contains the target of the link.  If an error occurs, the
     991   server may respond with SSH_FXP_STATUS.
     992
     993    The SSH_FXP_SYMLINK request will create a symbolic link on the
     994   server.  It is of the following format
     995
     996        uint32     id
     997        string     linkpath
     998        string     targetpath
     999
     1000   where `id' is the request identifier, `linkpath' specifies the path
     1001   name of the symlink to be created and `targetpath' specifies the
     1002   target of the symlink.  The server shall respond with a
     1003   SSH_FXP_STATUS indicating either success (SSH_FX_OK) or an error
     1004   condition.
     1005
     10066.11 Canonicalizing the Server-Side Path Name
     1007
     1008    The SSH_FXP_REALPATH request can be used to have the server
     1009   canonicalize any given path name to an absolute path.  This is useful
     1010   for converting path names containing ".." components or relative
     1011   pathnames without a leading slash into absolute paths.  The format of
     1012   the request is as follows:
     1013
     1014        uint32     id
     1015        string     path
     1016
     1017   where `id' is the request identifier and `path' specifies the path
     1018   name to be canonicalized.  The server will respond with a
     1019   SSH_FXP_NAME packet containing only one name and a dummy attributes
     1020   value.  The name is the returned packet will be in canonical form.
     1021
     1022
     1023
     1024Ylonen & Lehtinen         Expires April 1, 2002                [Page 18]
     1025
    171026
     1027Internet-Draft         SSH File Transfer Protocol           October 2001
     1028
     1029
     1030   If an error occurs, the server may also respond with SSH_FXP_STATUS.
     1031
     1032
     1033
     1034
     1035
     1036
     1037
     1038
     1039
     1040
     1041
     1042
     1043
     1044
     1045
     1046
     1047
     1048
     1049
     1050
     1051
     1052
     1053
     1054
     1055
     1056
     1057
     1058
     1059
     1060
     1061
     1062
     1063
     1064
     1065
     1066
     1067
     1068
     1069
     1070
     1071
     1072
     1073
     1074
     1075
     1076
     1077
     1078
     1079
     1080
     1081Ylonen & Lehtinen         Expires April 1, 2002                [Page 19]
     1082
    181083
     1084Internet-Draft         SSH File Transfer Protocol           October 2001
     1085
     1086
     10877. Responses from the Server to the Client
     1088
     1089   The server responds to the client using one of a few response
     1090   packets.  All requests can return a SSH_FXP_STATUS response upon
     1091   failure.  When the operation is successful, any of the responses may
     1092   be returned (depending on the operation).  If no data needs to be
     1093   returned to the client, the SSH_FXP_STATUS response with SSH_FX_OK
     1094   status is appropriate.  Otherwise, the SSH_FXP_HANDLE message is used
     1095   to return a file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR
     1096   requests), SSH_FXP_DATA is used to return data from SSH_FXP_READ,
     1097   SSH_FXP_NAME is used to return one or more file names from a
     1098   SSH_FXP_READDIR or SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is
     1099   used to return file attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and
     1100   SSH_FXP_FSTAT requests.
     1101
     1102   Exactly one response will be returned for each request.  Each
     1103   response packet contains a request identifier which can be used to
     1104   match each response with the corresponding request.  Note that it is
     1105   legal to have several requests outstanding simultaneously, and the
     1106   server is allowed to send responses to them in a different order from
     1107   the order in which the requests were sent (the result of their
     1108   execution, however, is guaranteed to be as if they had been processed
     1109   one at a time in the order in which the requests were sent).
     1110
     1111   Response packets are of the same general format as request packets.
     1112   Each response packet begins with the request identifier.
     1113
     1114    The format of the data portion of the SSH_FXP_STATUS response is as
     1115   follows:
     1116
     1117        uint32     id
     1118        uint32     error/status code
     1119        string     error message (ISO-10646 UTF-8 [RFC-2279])
     1120        string     language tag (as defined in [RFC-1766])
     1121
     1122   where `id' is the request identifier, and `error/status code'
     1123   indicates the result of the requested operation.  The value SSH_FX_OK
     1124   indicates success, and all other values indicate failure.
     1125
     1126
     1127
     1128
     1129
     1130
     1131
     1132
     1133
     1134
     1135
     1136
     1137
     1138Ylonen & Lehtinen         Expires April 1, 2002                [Page 20]
     1139
    191140
     1141Internet-Draft         SSH File Transfer Protocol           October 2001
     1142
     1143
     1144    Currently, the following values are defined (other values may be
     1145   defined by future versions of this protocol):
     1146
     1147        #define SSH_FX_OK                            0
     1148        #define SSH_FX_EOF                           1
     1149        #define SSH_FX_NO_SUCH_FILE                  2
     1150        #define SSH_FX_PERMISSION_DENIED             3
     1151        #define SSH_FX_FAILURE                       4
     1152        #define SSH_FX_BAD_MESSAGE                   5
     1153        #define SSH_FX_NO_CONNECTION                 6
     1154        #define SSH_FX_CONNECTION_LOST               7
     1155        #define SSH_FX_OP_UNSUPPORTED                8
     1156
     1157   SSH_FX_OK
     1158      Indicates successful completion of the operation.
     1159
     1160   SSH_FX_EOF
     1161      indicates end-of-file condition; for SSH_FX_READ it means that no
     1162      more data is available in the file, and for SSH_FX_READDIR it
     1163      indicates that no more files are contained in the directory.
     1164
     1165   SSH_FX_NO_SUCH_FILE
     1166      is returned when a reference is made to a file which should exist
     1167      but doesn't.
     1168
     1169   SSH_FX_PERMISSION_DENIED
     1170      is returned when the authenticated user does not have sufficient
     1171      permissions to perform the operation.
     1172
     1173   SSH_FX_FAILURE
     1174      is a generic catch-all error message; it should be returned if an
     1175      error occurs for which there is no more specific error code
     1176      defined.
     1177
     1178   SSH_FX_BAD_MESSAGE
     1179      may be returned if a badly formatted packet or protocol
     1180      incompatibility is detected.
     1181
     1182   SSH_FX_NO_CONNECTION
     1183      is a pseudo-error which indicates that the client has no
     1184      connection to the server (it can only be generated locally by the
     1185      client, and MUST NOT be returned by servers).
     1186
     1187   SSH_FX_CONNECTION_LOST
     1188      is a pseudo-error which indicates that the connection to the
     1189      server has been lost (it can only be generated locally by the
     1190      client, and MUST NOT be returned by servers).
     1191
     1192
     1193
     1194
     1195Ylonen & Lehtinen         Expires April 1, 2002                [Page 21]
     1196
    201197
     1198Internet-Draft         SSH File Transfer Protocol           October 2001
     1199
     1200
     1201   SSH_FX_OP_UNSUPPORTED
     1202      indicates that an attempt was made to perform an operation which
     1203      is not supported for the server (it may be generated locally by
     1204      the client if e.g.  the version number exchange indicates that a
     1205      required feature is not supported by the server, or it may be
     1206      returned by the server if the server does not implement an
     1207      operation).
     1208
     1209   The SSH_FXP_HANDLE response has the following format:
     1210
     1211        uint32     id
     1212        string     handle
     1213
     1214   where `id' is the request identifier, and `handle' is an arbitrary
     1215   string that identifies an open file or directory on the server.  The
     1216   handle is opaque to the client; the client MUST NOT attempt to
     1217   interpret or modify it in any way.  The length of the handle string
     1218   MUST NOT exceed 256 data bytes.
     1219
     1220    The SSH_FXP_DATA response has the following format:
     1221
     1222        uint32     id
     1223        string     data
     1224
     1225   where `id' is the request identifier, and `data' is an arbitrary byte
     1226   string containing the requested data.  The data string may be at most
     1227   the number of bytes requested in a SSH_FXP_READ request, but may also
     1228   be shorter if end of file is reached or if the read is from something
     1229   other than a regular file.
     1230
     1231    The SSH_FXP_NAME response has the following format:
     1232
     1233        uint32     id
     1234        uint32     count
     1235        repeats count times:
     1236                string     filename
     1237                string     longname
     1238                ATTRS      attrs
     1239
     1240   where `id' is the request identifier, `count' is the number of names
     1241   returned in this response, and the remaining fields repeat `count'
     1242   times (so that all three fields are first included for the first
     1243   file, then for the second file, etc).  In the repeated part,
     1244   `filename' is a file name being returned (for SSH_FXP_READDIR, it
     1245   will be a relative name within the directory, without any path
     1246   components; for SSH_FXP_REALPATH it will be an absolute path name),
     1247   `longname' is an expanded format for the file name, similar to what
     1248   is returned by "ls -l" on Unix systems, and `attrs' is the attributes
     1249
     1250
     1251
     1252Ylonen & Lehtinen         Expires April 1, 2002                [Page 22]
     1253
    211254
     1255Internet-Draft         SSH File Transfer Protocol           October 2001
     1256
     1257
     1258   of the file as described in Section ``File Attributes''.
     1259
     1260   The format of the `longname' field is unspecified by this protocol.
     1261   It MUST be suitable for use in the output of a directory listing
     1262   command (in fact, the recommended operation for a directory listing
     1263   command is to simply display this data).  However, clients SHOULD NOT
     1264   attempt to parse the longname field for file attributes; they SHOULD
     1265   use the attrs field instead.
     1266
     1267    The recommended format for the longname field is as follows:
     1268
     1269        -rwxr-xr-x   1 mjos     staff      348911 Mar 25 14:29 t-filexfer
     1270        1234567890 123 12345678 12345678 12345678 123456789012
     1271
     1272   Here, the first line is sample output, and the second field indicates
     1273   widths of the various fields.  Fields are separated by spaces.  The
     1274   first field lists file permissions for user, group, and others; the
     1275   second field is link count; the third field is the name of the user
     1276   who owns the file; the fourth field is the name of the group that
     1277   owns the file; the fifth field is the size of the file in bytes; the
     1278   sixth field (which actually may contain spaces, but is fixed to 12
     1279   characters) is the file modification time, and the seventh field is
     1280   the file name.  Each field is specified to be a minimum of certain
     1281   number of character positions (indicated by the second line above),
     1282   but may also be longer if the data does not fit in the specified
     1283   length.
     1284
     1285    The SSH_FXP_ATTRS response has the following format:
     1286
     1287        uint32     id
     1288        ATTRS      attrs
     1289
     1290   where `id' is the request identifier, and `attrs' is the returned
     1291   file attributes as described in Section ``File Attributes''.
     1292
     1293
     1294
     1295
     1296
     1297
     1298
     1299
     1300
     1301
     1302
     1303
     1304
     1305
     1306
     1307
     1308
     1309Ylonen & Lehtinen         Expires April 1, 2002                [Page 23]
     1310
    221311
     1312Internet-Draft         SSH File Transfer Protocol           October 2001
     1313
     1314
     13158. Vendor-Specific Extensions
     1316
     1317    The SSH_FXP_EXTENDED request provides a generic extension mechanism
     1318   for adding vendor-specific commands.  The request has the following
     1319   format:
     1320
     1321        uint32     id
     1322        string     extended-request
     1323        ... any request-specific data ...
     1324
     1325   where `id' is the request identifier, and `extended-request' is a
     1326   string of the format "name@domain", where domain is an internet
     1327   domain name of the vendor defining the request.  The rest of the
     1328   request is completely vendor-specific, and servers should only
     1329   attempt to interpret it if they recognize the `extended-request'
     1330   name.
     1331
     1332   The server may respond to such requests using any of the response
     1333   packets defined in Section ``Responses from the Server to the
     1334   Client''.  Additionally, the server may also respond with a
     1335   SSH_FXP_EXTENDED_REPLY packet, as defined below.  If the server does
     1336   not recognize the `extended-request' name, then the server MUST
     1337   respond with SSH_FXP_STATUS with error/status set to
     1338   SSH_FX_OP_UNSUPPORTED.
     1339
     1340    The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary
     1341   extension-specific data from the server to the client.  It is of the
     1342   following format:
     1343
     1344        uint32     id
     1345        ... any request-specific data ...
     1346
     1347
     1348
     1349
     1350
     1351
     1352
     1353
     1354
     1355
     1356
     1357
     1358
     1359
     1360
     1361
     1362
     1363
     1364
     1365
     1366Ylonen & Lehtinen         Expires April 1, 2002                [Page 24]
     1367
    231368
     1369Internet-Draft         SSH File Transfer Protocol           October 2001
     1370
     1371
     13729. Security Considerations
     1373
     1374   This protocol assumes that it is run over a secure channel and that
     1375   the endpoints of the channel have been authenticated.  Thus, this
     1376   protocol assumes that it is externally protected from network-level
     1377   attacks.
     1378
     1379   This protocol provides file system access to arbitrary files on the
     1380   server (only constrained by the server implementation).  It is the
     1381   responsibility of the server implementation to enforce any access
     1382   controls that may be required to limit the access allowed for any
     1383   particular user (the user being authenticated externally to this
     1384   protocol, typically using the SSH User Authentication Protocol [6].
     1385
     1386   Care must be taken in the server implementation to check the validity
     1387   of received file handle strings.  The server should not rely on them
     1388   directly; it MUST check the validity of each handle before relying on
     1389   it.
     1390
     1391
     1392
     1393
     1394
     1395
     1396
     1397
     1398
     1399
     1400
     1401
     1402
     1403
     1404
     1405
     1406
     1407
     1408
     1409
     1410
     1411
     1412
     1413
     1414
     1415
     1416
     1417
     1418
     1419
     1420
     1421
     1422
     1423Ylonen & Lehtinen         Expires April 1, 2002                [Page 25]
     1424
    241425
     1426Internet-Draft         SSH File Transfer Protocol           October 2001
     1427
     1428
     142910. Changes from previous protocol versions
     1430
     1431   The SSH File Transfer Protocol has changed over time, before it's
     1432   standardization.  The following is a description of the incompatible
     1433   changes between different versions.
     1434
     143510.1 Changes between versions 3 and 2
     1436
     1437   o  The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added.
     1438
     1439   o  The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were
     1440      added.
     1441
     1442   o  The SSH_FXP_STATUS message was changed to include fields `error
     1443      message' and `language tag'.
     1444
     1445
     144610.2 Changes between versions 2 and 1
     1447
     1448   o  The SSH_FXP_RENAME message was added.
     1449
     1450
     145110.3 Changes between versions 1 and 0
     1452
     1453   o  Implementation changes, no actual protocol changes.
     1454
     1455
     1456
     1457
     1458
     1459
     1460
     1461
     1462
     1463
     1464
     1465
     1466
     1467
     1468
     1469
     1470
     1471
     1472
     1473
     1474
     1475
     1476
     1477
     1478
     1479
     1480Ylonen & Lehtinen         Expires April 1, 2002                [Page 26]
     1481
    251482
     1483Internet-Draft         SSH File Transfer Protocol           October 2001
     1484
     1485
     148611. Trademark Issues
     1487
     1488   "ssh" is a registered trademark of SSH Communications Security Corp
     1489   in the United States and/or other countries.
     1490
     1491
     1492
     1493
     1494
     1495
     1496
     1497
     1498
     1499
     1500
     1501
     1502
     1503
     1504
     1505
     1506
     1507
     1508
     1509
     1510
     1511
     1512
     1513
     1514
     1515
     1516
     1517
     1518
     1519
     1520
     1521
     1522
     1523
     1524
     1525
     1526
     1527
     1528
     1529
     1530
     1531
     1532
     1533
     1534
     1535
     1536
     1537Ylonen & Lehtinen         Expires April 1, 2002                [Page 27]
     1538
    261539
     1540Internet-Draft         SSH File Transfer Protocol           October 2001
     1541
     1542
     1543References
     1544
     1545   [1]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
     1546        P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
     1547        1999.
     1548
     1549   [2]  Institute of Electrical and Electronics Engineers, "Information
     1550        Technology - Portable Operating System Interface (POSIX) - Part
     1551        1: System Application Program Interface (API) [C Language]",
     1552        IEEE Standard 1003.2, 1996.
     1553
     1554   [3]  Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
     1555        Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh-
     1556        architecture-09 (work in progress), July 2001.
     1557
     1558   [4]  Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
     1559        Lehtinen, "SSH Protocol Transport Protocol", draft-ietf-secsh-
     1560        architecture-09 (work in progress), July 2001.
     1561
     1562   [5]  Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
     1563        Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-11
     1564        (work in progress), July 2001.
     1565
     1566   [6]  Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
     1567        Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh-
     1568        userauth-11 (work in progress), July 2001.
     1569
     1570
     1571Authors' Addresses
     1572
     1573   Tatu Ylonen
     1574   SSH Communications Security Corp
     1575   Fredrikinkatu 42
     1576   HELSINKI  FIN-00100
     1577   Finland
     1578
     1579   EMail: ylo@ssh.com
     1580
     1581
     1582   Sami Lehtinen
     1583   SSH Communications Security Corp
     1584   Fredrikinkatu 42
     1585   HELSINKI  FIN-00100
     1586   Finland
     1587
     1588   EMail: sjl@ssh.com
     1589
     1590
     1591
     1592
     1593
     1594Ylonen & Lehtinen         Expires April 1, 2002                [Page 28]
     1595
    271596
     1597Internet-Draft         SSH File Transfer Protocol           October 2001
     1598
     1599
     1600Full Copyright Statement
     1601
     1602   Copyright (C) The Internet Society (2001).  All Rights Reserved.
     1603
     1604   This document and translations of it may be copied and furnished to
     1605   others, and derivative works that comment on or otherwise explain it
     1606   or assist in its implementation may be prepared, copied, published
     1607   and distributed, in whole or in part, without restriction of any
     1608   kind, provided that the above copyright notice and this paragraph are
     1609   included on all such copies and derivative works.  However, this
     1610   document itself may not be modified in any way, such as by removing
     1611   the copyright notice or references to the Internet Society or other
     1612   Internet organizations, except as needed for the purpose of
     1613   developing Internet standards in which case the procedures for
     1614   copyrights defined in the Internet Standards process must be
     1615   followed, or as required to translate it into languages other than
     1616   English.
     1617
     1618   The limited permissions granted above are perpetual and will not be
     1619   revoked by the Internet Society or its successors or assigns.
     1620
     1621   This document and the information contained herein is provided on an
     1622   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
     1623   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
     1624   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
     1625   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
     1626   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  • twisted/conch/test/test_filetransfer.py

    +
    +Acknowledgement
    +
    +   Funding for the RFC Editor function is currently provided by the
    +   Internet Society.
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +Ylonen & Lehtinen         Expires April 1, 2002                [Page 29]
    +
    
    +
    +
     
    569569        conn.serviceStopped()
    570570
    571571        self.assertSFTPConnectionLost()
     572
     573from twisted.python.util import sibpath
     574import re
     575
     576class TestConstants(unittest.TestCase):
     577
     578    def test_constants_against_spec(self):
     579        constants = {}
     580        draft_file = open(sibpath(__file__, 'draft-ietf-secsh-filexfer-02.txt'))
     581        for line in draft_file:
     582            m = re.match('^\s*#define SSH_([A-Z_]+)\s+([0-9x]*)\s*$', line)
     583            if m:
     584                constants[m.group(1)] = int(m.group(2), 0)
     585        self.assert_(len(constants) > 0)
     586        for k, v in constants.items():
     587            self.assertEqual(v, getattr(filetransfer, k))
  • twisted/conch/ssh/filetransfer.py

     
    866866FXP_EXTENDED_REPLY  = 201
    867867
    868868FILEXFER_ATTR_SIZE        = 0x00000001
    869 FILEXFER_ATTR_OWNERGROUP  = 0x00000002
     869FILEXFER_ATTR_UIDGID      = 0x00000002
     870FILEXFER_ATTR_OWNERGROUP  = FILEXFER_ATTR_UIDGID
    870871FILEXFER_ATTR_PERMISSIONS = 0x00000004
    871 FILEXFER_ATTR_ACMODTIME   = 0x00000009
     872FILEXFER_ATTR_ACMODTIME   = 0x00000008
    872873FILEXFER_ATTR_EXTENDED    = 0x80000000L
    873874
    874875FILEXFER_TYPE_REGULAR        = 1
     
    895896FX_CONNECTION_LOST             = 7
    896897FX_OP_UNSUPPORTED              = 8
    897898FX_FILE_ALREADY_EXISTS         = 11
    898 # https://datatracker.ietf.org/idtracker/draft-ietf-secsh-filexfer/ defines
    899 # more useful error codes, but so far OpenSSH doesn't implement them.  We use
    900 # them internally for clarity, but for now define them all as FX_FAILURE to be
     899# http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/ defines more
     900# useful error codes, but so far OpenSSH doesn't implement them.  We use them
     901# internally for clarity, but for now define them all as FX_FAILURE to be
    901902# compatible with existing software.
    902903FX_NOT_A_DIRECTORY             = FX_FAILURE
    903904FX_FILE_IS_A_DIRECTORY         = FX_FAILURE