Network Working Group                                          T. Ylonen and
Internet-Draft                                               S. Lehtinen
INTERNET-DRAFT
Expires: April 1, 2002                  SSH Communications Security

Expires: 2 September, Corp
                                                            October 2001

                  Secure Shell

                       SSH File Transfer Protocol
                    draft-ietf-secsh-filexfer-02.txt

Status of This 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.

   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 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 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 Secure Shell 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 Secure Shell Remote Login Protocol. SSH2 protocol.  This document
   describes the file transfer protocol and its interface to the Secure Shell SSH2
   protocol suite.

Table of Contents

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

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 Secure Shell Remote Login Protocol [SECSH-ARCH]. 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 [SECSH-ARCH]. the secsh architecture draft.[3].

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

2. Use with the Secure Shell SSH Connection Protocol

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

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 practise 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 practise 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 queueing queuing of outgoing
   requests at the client.

   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'' ``Vendor-Specific-Extensions'' for more details.

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 `exten-
sion_data'
   `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 orga-
nization 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.

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
   remaining attributes (or will not modify the values of remaining
   attributes).  When receiving attributes from the server, the flags
   specify which attributes are included in the returned data.  The
   server normally returns all attributes it knows about.

   	uint32   flags
   	uint64   size           present only if flag SSH_FILEXFER_ATTR_SIZE
   	uint32   uid            present only if flag SSH_FILEXFER_ATTR_UIDGID
   	uint32   gid            present only if flag SSH_FILEXFER_ATTR_UIDGID
   	uint32   permissions    present only if flag SSH_FILEXFER_ATTR_PERMISSIONS
   	uint32   atime          present only if flag SSH_FILEXFER_ACMODTIME
   	uint32   mtime          present only if flag SSH_FILEXFER_ACMODTIME
   	uint32   extended_count present only if flag SSH_FILEXFER_ATTR_EXTENDED
   	string   extended_type
   	string   extended_data
   	...      more extended data (extended_type - extended_data pairs),
   		   so that number of pairs equals extended_count

   The `flags' specify which of the fields are present.  Those fields
   for which the corresponding flag is not set are not present (not
   included in the packet).  New flags can only be added by incrementing
   the protocol version number (or by using the extension mechanism
   described below).

   The `size' field specifies the size of the file in bytes.

   The `uid' and `gid' fields contain numeric Unix-like user and group
   identifiers, respectively.

   The `permissions' field contains a bit mask of file permissions as
   defined by [POSIX]. posix [1].

   The `atime' and `mtime' contain the access and modification times of
   the files, respectively.  They are represented as seconds from Jan 1,
   1970 in UTC.

   The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension
   mechanism for vendor-specific extensions.  If the flag is specified,
   then the `extended_count' field is present.  It specifies the number
   of extended_type-extended_data pairs that follow.  Each of these
   pairs specifies an extended attribute.  For each of the attributes,
   the extended_type field should be a string of the format
   "name@domain", where "domain" is a valid, registered domain name and
   "name" identifies the method.  The IETF may later standardize certain
   names that deviate from this format (e.g., that do not contain the
   "@" sign).  The interpretation of `extended_data' depends on the
   type.  Implementations SHOULD ignore extended data fields that they
   do not understand.

   Additional fields can be added to the attributes by either defining
   additional bits to the flags field to indicate their presence, or by
   defining extended attributes for them.  The extended attributes
   mechanism is recommended for most purposes; additional flags bits
   should only be defined by an IETF standards action that also
   increments the protocol version number.  The use of such new fields
   MUST be negotiated by the version number in the protocol exchange.
   It is a protocol error if a packet with unsupported protocol bits is
   received.

    The flags bits are defined to have the following values:

   	#define SSH_FILEXFER_ATTR_SIZE          0x00000001
   	#define SSH_FILEXFER_ATTR_UIDGID        0x00000002
   	#define SSH_FILEXFER_ATTR_PERMISSIONS   0x00000004
   	#define SSH_FILEXFER_ATTR_ACMODTIME     0x00000008
   	#define SSH_FILEXFER_ATTR_EXTENDED      0x80000000

6.  Responses from the Server to Requests From the Client

The server responds to the Server

   Requests from the client using one of a few response packets.
All requests can return a SSH_FXP_STATUS response upon failure.  When to the operation server represent the various file
   system operations.  Each request begins with an `id' field, which is successful, any of
   a 32-bit identifier identifying the responses may be returned
(depending on request (selected by the operation).  If no data needs to client).
   The same identifier will be returned to the
client, in the SSH_FXP_STATUS response with SSH_FX_OK status is
appropriate.  Otherwise, to the SSH_FXP_HANDLE message request.
   One possible implementation of it is used to a monotonically increasing
   request sequence number (modulo 2^32).

   Many operations in the protocol operate on open files.  The
   SSH_FXP_OPEN request can return a file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR requests),
SSH_FXP_DATA is used to return data from SSH_FXP_READ, SSH_FXP_NAME (which is an opaque
   variable-length string) which may be used to return one or more access the file names from later
   (e.g.  in a SSH_FXP_READDIR read operation).  The client MUST NOT send requests the
   server with bogus or
SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is used closed handles.  However, the server MUST
   perform adequate checks on the handle in order to return file
attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, avoid security
   risks due to fabricated handles.

   This design allows either stateful and SSH_FXP_FSTAT requests.

Exactly one response will be returned for each request.  Each response
packet contains a request identifier stateless server
   implementation, as well as an implementation which can be used to match each
response with caches state
   between requests but may also flush it.  The contents of the corresponding request.  Note that it is legal file
   handle string are entirely up to have
several requests outstanding simultaneously, and the server is allowed
to send responses and its design.  The
   client should not modify or attempt to them in a different order from the order in which interpret the file handle
   strings.

   The file handle strings MUST NOT be longer than 256 bytes.

6.1 Request Synchronization and Reordering

   The protocol and implementations MUST process requests were sent (the result of their execution, however, is
guaranteed relating to be as if they had been processed one at a time
   the same file in the order in which the requests were sent).

Response packets they are of received.  In other
   words, if an application submits multiple requests to the server, the
   results in the responses will be the same general format as request packets.
Each response packet begins with the request identifier.

The format of if it had sent the data portion of
   requests one at a time and waited for the SSH_FXP_STATUS response is as
follows:

  uint32     id
  uint32     error/status code
  string     error message (ISO-10646 UTF-8 [RFC-2279])
  string     language tag (as defined in [RFC-1766])

where `id' is each case.  For
   example, the request identifier, and `error/status code' indicates server may process non-overlapping read/write requests
   to the result of same file in parallel, but overlapping reads and writes cannot
   be reordered or parallelized.  However, there are no ordering
   restrictions on the requested operation. server for processing requests from two different
   file transfer connections.  The value SSH_FX_OK indicates
success, server may interleave and all other values indicate failure.  Currently, parallelize
   them at will.

   There are no restrictions on the follow-
ing values order in which responses to
   outstanding requests are defined (other values may be defined by future versions
of this protocol):

  #define SSH_FX_OK                            0
  #define SSH_FX_EOF                           1
  #define SSH_FX_NO_SUCH_FILE                  2
  #define SSH_FX_PERMISSION_DENIED             3
  #define SSH_FX_FAILURE                       4
  #define SSH_FX_BAD_MESSAGE                   5
  #define SSH_FX_NO_CONNECTION                 6
  #define SSH_FX_CONNECTION_LOST               7
  #define SSH_FX_OP_UNSUPPORTED                8

   SSH_FX_OK
      Indicates successful completion of delivered to the operation.

   SSH_FX_EOF
      indicates end-of-file condition; for SSH_FX_READ it means client, except that no
      more data is available the
   server must ensure fairness in the file, and for SSH_FX_READDIR it
      indicates sense that processing of no more files are contained in
   request will be indefinitely delayed even if the directory.

   SSH_FX_NO_SUCH_FILE client is returned when a reference is made to a file which should exist
      but doesn't.

   SSH_FX_PERMISSION_DENIED
      is returned when the authenticated user does not have sufficient
      permissions to perform the operation.

   SSH_FX_FAILURE
      is a generic catch-all error message; it should be returned if an
      error occurs for which there is no more specific error code
      defined.

   SSH_FX_BAD_MESSAGE
      may be returned if a badly formatted packet or protocol
      incompatibility is detected.

   SSH_FX_NO_CONNECTION
      is a pseudo-error which indicates that the client has no
      connection to the server (it can only be generated locally by the
      client, and MUST NOT be returned by servers).

   SSH_FX_CONNECTION_LOST
      is a pseudo-error which indicates that the connection to the
      server has been lost (it can only be generated locally by the
      client, and MUST NOT be returned by servers).

   SSH_FX_OP_UNSUPPORTED
      indicates that an attempt was made to perform an operation which
      is not supported for the server (it may be generated locally by
      the client if e.g. the version number exchange indicates sending
   other requests so that a
      required feature is not supported by the server, or it may be
      returned by the server if the server does not implement an
      operation).

The SSH_FXP_HANDLE response has the following format:

  uint32     id
  string     handle

where `id' is there are multiple outstanding requests all
   the request identifier, and `handle' is an arbitrary
string that identifies an open time.

6.2 File Names

   This protocol represents file or directory on the server.  The
handle is opaque to the client; the client MUST NOT attempt names as strings.  File names are
   assumed to interpret
or modify it in any way.  The length of the handle string MUST NOT
exceed 256 data bytes.

The SSH_FXP_DATA response has the following format:

   uint32     id
   string     data

where `id' is the request identifier, and `data' is an arbitrary byte
string containing the requested data.  The data string may be at most use the number of bytes requested in slash ('/') character as a SSH_FXP_READ request, but may also be
shorter if end of file is reached or if the read is from something other
than directory separator.

   File names starting with a regular file.

The SSH_FXP_NAME response has the following format:

  uint32     id
  uint32     count
  repeats count times:
    string     filename
    string     longname
    ATTRS      attrs

where `id' is the request identifier, `count' is slash are "absolute", and are relative to
   the number root of names
returned in this response, and the remaining fields repeat `count' times
(so that all three fields file system.  Names starting with any other character
   are first included for the first file, then
for relative to the second file, etc).  In user's default directory (home directory).  Note
   that identifying the repeated part, `filename' user is assumed to take place outside of this
   protocol.

   Servers SHOULD interpret a file
name being returned (for SSH_FXP_READDIR, it will be a relative path name
within component ".." as referring to
   the parent directory, without any path components; for SSH_FXP_REALPATH
it will be an absolute path name), `longname' is an expanded format for
the file name, similar to what is returned by "ls -l" on Unix systems, and `attrs' is "." as referring to the attributes current directory.
   If the server implementation limits access to certain parts of the
   file as described system, it must be extra careful in Section ``File
Attributes''.

The format of parsing file names when
   enforcing such restrictions.  There have been numerous reported
   security bugs where a ".." in a path name has allowed access outside
   the `longname' field intended area.

   An empty path name is unspecified by this protocol.  It
MUST be suitable for use in valid, and it refers to the output of a user's default
   directory listing command
(in fact, (usually the recommended operation user's home directory).

   Otherwise, no syntax is defined for file names by this specification.
   Clients should not make any other assumptions; however, they can
   splice path name components returned by SSH_FXP_READDIR together
   using a directory listing command slash ('/') as the separator, and that will work as expected.

   It is
to simply display this data).  However, clients SHOULD NOT attempt to
parse understood that the longname field lack of well-defined semantics for file attributes; they SHOULD use the attrs
field instead.

The recommended format for the longname field is as follows:

-rwxr-xr-x   1 mjos     staff      348911 Mar 25 14:29 t-filexfer
1234567890 123 12345678 12345678 12345678 123456789012

Here, the first line
   names may cause interoperability problems between clients and servers
   using radically different operating systems.  However, this approach
   is sample output, known to work acceptably with most systems, and the second field indicates
widths alternative
   approaches that e.g.  treat file names as sequences of the various fields.  Fields structured
   components are separated by spaces.  The
first field lists file permissions for user, group, quite complicated.

6.3 Opening, Creating, and others; Closing Files

    Files are opened and created using the sec-
ond field SSH_FXP_OPEN message, whose
   data part is link count; the third as follows:

   	uint32        id
   	string        filename
   	uint32        pflags
   	ATTRS         attrs

   The `id' field is the name of the user who
owns the file; the fourth request identifier as for all requests.

   The `filename' field is the name of the group that owns the
file; specifies the fifth file name.  See Section ``File
   Names'' for more information.

    The `pflags' field is a bitmask.  The following bits have been
   defined.

   	#define SSH_FXF_READ            0x00000001
   	#define SSH_FXF_WRITE           0x00000002
   	#define SSH_FXF_APPEND          0x00000004
   	#define SSH_FXF_CREAT           0x00000008
   	#define SSH_FXF_TRUNC           0x00000010
   	#define SSH_FXF_EXCL            0x00000020

   These have the size of following meanings:

   SSH_FXF_READ
      Open the file in bytes; for reading.

   SSH_FXF_WRITE
      Open the sixth field
(which actually may contain spaces, but is fixed to 12 characters) is file for writing.  If both this and SSH_FXF_READ are
      specified, the file modification time, is opened for both reading and writing.

   SSH_FXF_APPEND
      Force all writes to append data at the seventh field is end of the file.

   SSH_FXF_CREAT
      If this flag is specified, then a new file name.
Each field will be created if one
      does not already exist (if O_TRUNC is specified specified, the new file will
      be truncated to zero length if it previously exists).

   SSH_FXF_TRUNC
      Forces an existing file with the same name to be truncated to zero
      length when creating a minimum of certain number of character
positions (indicated file by the second line above), but may specifying SSH_FXF_CREAT.
      SSH_FXF_CREAT MUST also be longer specified if this flag is used.

   SSH_FXF_EXCL
      Causes the data does not fit in request to fail if the named file already exists.
      SSH_FXF_CREAT MUST also be specified length.

The SSH_FXP_ATTRS response has the following format:

  uint32     id
  ATTRS      attrs

where `id' if this flag is the request identifier, and used.

   The `attrs' is field specifies the returned file initial attributes as described in for the file.
   Default values will be used for those attributes that are not
   specified.  See Section ``File Attributes''.

7.  Requests From the Client to Attributes'' for more information.

   Regardless the Server

Requests from server operating system, the client file will always be
   opened in "binary" mode (i.e., no translations between different
   character sets and newline encodings).

   The response to this message will be either SSH_FXP_HANDLE (if the server represent
   operation is successful) or SSH_FXP_STATUS (if the various operation fails).

    A file system

operations.  Each request begins with an `id' field, which is a 32-bit
identifier identifying closed by using the SSH_FXP_CLOSE request.  Its data field
   has the following format:

   	uint32     id
   	string     handle

   where `id' is the request (selected by the client).  The same
identifier will be identifier, and `handle' is a handle
   previously returned in the response to the request.  One
possible implementation of it is a monotonically increasing SSH_FXP_OPEN or
   SSH_FXP_OPENDIR.  The handle becomes invalid immediately after this
   request
sequence number (modulo 2^32).

Many operations in the protocol operate on open files. has been sent.

   The SSH_FXP_OPEN response to this request can return a file handle (which is an opaque variable-length
string) which may will be used to access the file later (e.g. in a read
operation).  The client MUST NOT send requests the SSH_FXP_STATUS message.  One
   should note that on some server with bogus or
closed handles.  However, platforms even a close can fail.
   This can happen e.g.  if the server MUST perform adequate checks on the
handle in order to avoid security risks due to fabricated handles.

This design allows either stateful operating system caches writes,
   and stateless server implementation,
as well as an implementation which caches state between requests but may
also flush it.  The contents of error occurs while flushing cached writes during the close.

6.4 Reading and Writing

    Once a file handle string are entirely up
to has been opened, it can be read using the server and its design.  The client should not modify or attempt
to interpret SSH_FXP_READ
   message, which has the file following format:

   	uint32     id
   	string     handle strings.

The
   	uint64     offset
   	uint32     len

   where `id' is the request identifier, `handle' is an open file handle strings MUST NOT be longer than 256 bytes.

7.1.  Request Synchronization and Reordering

The protocol and implementations MUST process requests relating
   returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative
   to the
same beginning of the file in from where to start reading, and `len'
   is the order in which they are received. maximum number of bytes to read.

   In other words, if
an application submits multiple requests response to this request, the server, the results in
the responses server will be the same read as many bytes as if it had sent the requests one at a
time and waited for the response in each case.  For example, the server
may process non-overlapping read/write requests to
   can from the same file in
parallel, but overlapping reads (up to `len'), and writes cannot be reordered return them in a SSH_FXP_DATA
   message.  If an error occurs or
parallelized.  However, there are no ordering restrictions on EOF is encountered before reading any
   data, the server
for processing requests from two different file transfer connections.
The server may interleave and parallelize them at will.

There are no restrictions on will respond with SSH_FXP_STATUS.  For normal disk
   files, it is guaranteed that this will read the order in which responses specified number of
   bytes, or up to outstanding
requests are delivered end of file.  For e.g.  device files this may return
   fewer bytes than requested.

    Writing to a file is achieved using the client, except that the server must ensure
fairness in SSH_FXP_WRITE message, which
   has the sense that processing of no following format:

   	uint32     id
   	string     handle
   	uint64     offset
   	string     data

   where `id' is a request will be indefinitely
delayed even if the client identifier, `handle' is sending other requests so that there are
multiple outstanding requests all a file handle
   returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the
   beginning of the time.

7.2.  File Names

This protocol represents file names as strings.  File names are assumed where to use the slash ('/') character as a directory separator.

File names starting with a slash are "absolute", start writing, and are relative `data' is the data
   to be written.

   The write will extend the
root file if writing beyond the end of the file system.  Names starting with any other character are
relative file.
   It is legal to write way beyond the user's default directory (home directory).  Note that
identifying end of the user is assumed file; the semantics
   are to take place outside write zeroes from the end of this protocol.

Servers SHOULD interpret a path name component ".." as referring the file to the
parent directory, specified offset
   and "." as referring to then the current directory.  If data.  On most operating systems, such writes do not
   allocate disk space but instead leave "holes" in the file.

   The server implementation limits access responds to certain parts a write request with a SSH_FXP_STATUS message.

6.5 Removing and Renaming Files

    Files can be removed using the SSH_FXP_REMOVE message.  It has the
   following format:

   	uint32     id
   	string     filename

   where `id' is the request identifier and `filename' is the name of
   the file system,

it must to be extra careful in parsing file names when enforcing such
restrictions.  There have been numerous reported security bugs removed.  See Section ``File Names'' for more
   information.  This request cannot be used to remove directories.

   The server will respond to this request with a SSH_FXP_STATUS
   message.

    Files (and directories) can be renamed using the SSH_FXP_RENAME
   message.  Its data is as follows:

   	uint32     id
   	string     oldpath
   	string     newpath

   where a
".." in a path name has allowed access outside `id' is the intended area.

An empty path name request identifier, `oldpath' is valid, the name of an
   existing file or directory, and it refers to `newpath' is the user's default
directory (usually new name for the user's home directory).

Otherwise, no syntax
   file or directory.  It is defined for an error if there already exists a file names
   with the name specified by this specification.
Clients should not make any newpath.  The server may also fail rename
   requests in other assumptions; however, they situations, for example if `oldpath' and `newpath'
   point to different file systems on the server.

   The server will respond to this request with a SSH_FXP_STATUS
   message.

6.6 Creating and Deleting Directories

    New directories can splice
path name components returned by SSH_FXP_READDIR together be created using a slash
('/') as the separator, and that will work as expected. SSH_FXP_MKDIR request.  It
   has the following format:

   	uint32     id
   	string     path
   	ATTRS      attrs

   where `id' is understood that the lack of well-defined semantics for file names
may cause interoperability problems between clients request identifier, `path' and servers using
radically different operating systems.  However, this approach is known `attrs' specifies
   the modifications to work acceptably with most systems, and alternative approaches that
e.g. treat be made to its attributes.  See Section ``File
   Names'' for more information on file names as sequences of structured components are quite
complicated.

7.3.  Opening, Creating, and Closing Files

Files names.  Attributes are opened and created discussed
   in more detail in Section ``File Attributes''.  specifies the
   directory to be created.  An error will be returned if a file or
   directory with the specified path already exists.  The server will
   respond to this request with a SSH_FXP_STATUS message.

    Directories can be removed using the SSH_FXP_OPEN message, whose data
part is as follows: SSH_FXP_RMDIR request, which
   has the following format:

   	uint32     id
   	string        filename
  uint32        pflags
  ATTRS         attrs

The     path

   where `id' field is the request identifier as for all requests.

The `filename' field identifier, and `path' specifies the file name.
   directory to be removed.  See Section ``File Names'' for more information.

The `pflags' field
   information on file names.  An error will be returned if no directory
   with the specified path exists, or if the specified directory is not
   empty, or if the path specified a bitmask. file system object other than a
   directory.  The following bits have been defined.

  #define SSH_FXF_READ            0x00000001
  #define SSH_FXF_WRITE           0x00000002
  #define SSH_FXF_APPEND          0x00000004
  #define SSH_FXF_CREAT           0x00000008
  #define SSH_FXF_TRUNC           0x00000010
  #define SSH_FXF_EXCL            0x00000020

These have the following meanings:

   SSH_FXF_READ
      Open server responds to this request with a SSH_FXP_STATUS
   message.

6.7 Scanning Directories

   The files in a directory can be listed using the SSH_FXP_OPENDIR and
   SSH_FXP_READDIR requests.  Each SSH_FXP_READDIR request returns one
   or more file names with full file attributes for reading.

   SSH_FXF_WRITE
      Open each file.  The
   client should call SSH_FXP_READDIR repeatedly until it has found the
   file it is looking for writing.  If both this and SSH_FXF_READ or until the server responds with a
   SSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF if
   there are
      specified, no more files in the file is opened directory).  The client should then
   close the handle using the SSH_FXP_CLOSE request.

    The SSH_FXP_OPENDIR opens a directory for both reading and writing.

   SSH_FXF_APPEND
      Force all writes to append data at reading.  It has the
   following format:

   	uint32     id
   	string     path

   where `id' is the end request identifier and `path' is the path name of
   the file.

   SSH_FXF_CREAT
      If this flag is specified, then a new directory to be listed (without any trailing slash).  See Section
   ``File Names'' for more information on file names.  This will be created return
   an error if one the path does not alread exist (if O_TRUNC is specified, specify a directory or if the new file directory
   is not readable.  The server will
      be truncated respond to zero length if it previously exists).

   SSH_FXF_TRUNC
      Forces an existing file this request with either
   a SSH_FXP_HANDLE or a SSH_FXP_STATUS message.

    Once the same name to directory has been successfully opened, files (and
   directories) contained in it can be truncated to zero
      length when creating listed using SSH_FXP_READDIR
   requests.  These are of the format

   	uint32     id
   	string     handle

   where `id' is the request identifier, and `handle' is a handle
   returned by SSH_FXP_OPENDIR.  (It is a protocol error to attempt to
   use an ordinary file handle returned by specifying SSH_FXF_CREAT.
      SSH_FXF_CREAT MUST also be specified if SSH_FXP_OPEN.)

   The server responds to this flag request with either a SSH_FXP_NAME or a
   SSH_FXP_STATUS message.  One or more names may be returned at a time.
   Full status information is used.

   SSH_FXF_EXCL
      Causes returned for each name in order to speed
   up typical directory listings.

   When the request client no longer wishes to fail if read more names from the named file already exists.
      SSH_FXF_CREAT MUST also
   directory, it SHOULD call SSH_FXP_CLOSE for the handle.  The handle
   should be specified if this flag closed regardless of whether an error has occurred or not.

6.8 Retrieving File Attributes

   Very often, file attributes are automatically returned by
   SSH_FXP_READDIR.  However, sometimes there is used.

The `attrs' field specifies need to specifically
   retrieve the initial attributes for the a named file.
Default values will  This can be used for those attributes done using the
   SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests.

    SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that are SSH_FXP_STAT
   follows symbolic links on the server, whereas SSH_FXP_LSTAT does not specified.
See Section ``File Attributes'' for more information.

Regardless
   follow symbolic links.  Both have the server operating system, same format:

   	uint32     id
   	string     path

   where `id' is the request identifier, and `path' specifies the file will always
   system object for which status is to be opened
in "binary" mode (i.e., no translations between different character sets
and newline encodings). returned.  The response server
   responds to this message will be request with either SSH_FXP_HANDLE (if the
operation is successful) SSH_FXP_ATTRS or SSH_FXP_STATUS (if SSH_FXP_STATUS.

    SSH_FXP_FSTAT differs from the operation fails).

A others in that it returns status
   information for an open file is closed (identified by using the SSH_FXP_CLOSE request. file handle).  Its data field has
the following format:
   format is as follows:

   	uint32     id
   	string     handle

   where `id' is the request identifier, identifier and `handle' is a file handle previ-
ously
   returned by SSH_FXP_OPEN.  The server responds to this request with
   SSH_FXP_ATTRS or SSH_FXP_STATUS.

6.9 Setting File Attributes

   File attributes may be modified using the SSH_FXP_SETSTAT and
   SSH_FXP_FSETSTAT requests.  These requests are used for operations
   such as changing the ownership, permissions or access times, as well
   as for truncating a file.

    The SSH_FXP_SETSTAT request is of the following format:

   	uint32     id
   	string     path
   	ATTRS      attrs

   where `id' is the request identifier, `path' specifies the file
   system object (e.g.  file or directory) whose attributes are to be
   modified, and `attrs' specifies the modifications to be made to its
   attributes.  Attributes are discussed in more detail in Section
   ``File Attributes''.

   An error will be returned if the response to SSH_FXP_OPEN specified file system object does
   not exist or SSH_FXP_OPENDIR.  The
handle becomes invalid immediately after this request has been sent. the user does not have sufficient rights to modify the
   specified attributes.  The response server responds to this request will be with a
   SSH_FXP_STATUS message.  One
should note that on some server platforms even a close can fail.  This
can happen e.g. if the server operating system caches writes, and an
error occurs while flushing cached writes during

    The SSH_FXP_FSETSTAT request modifies the close.

7.4.  Reading and Writing

Once attributes of a file has been opened, it can be read using the SSH_FXP_READ
message, which
   is already open.  It has the following format:

   	uint32     id
   	string     handle
  uint64     offset
  uint32     len
   	ATTRS      attrs

   where `id' is the request identifier, `handle' is an open file handle (MUST be returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative to
the beginning of
   SSH_FXP_OPEN) identifies the file from where whose attributes are to start reading, be
   modified, and `len' is `attrs' specifies the
maximum number of bytes to read.

In response modifications to this request, the server will read as many bytes as it
can from the file (up be made to `len'), and return them its
   attributes.  Attributes are discussed in a SSH_FXP_DATA
message.  If an error occurs or EOF is encountered before reading any
data, the more detail in Section
   ``File Attributes''.  The server will respond with SSH_FXP_STATUS.  For normal disk
files, it is guaranteed that this will read the specified number of
bytes, or up to end of file.  For e.g. device files this request with
   SSH_FXP_STATUS.

6.10 Dealing with Symbolic links

    The SSH_FXP_READLINK request may return
fewer bytes than requested.

Writing be used to a file is achieved using the SSH_FXP_WRITE message, which has read the following format: target of a
   symbolic link.  It would have a data part as follows:

   	uint32     id
   	string     handle
  uint64     offset
  string     data     path

   where `id' is a request identifier, `handle' is a file handle returned
by SSH_FXP_OPEN, `offset' is the offset (in bytes) from request identifier and `path' specifies the beginning path
   name of the file where to start writing, and `data' is the data symlink to be written. read.

   The write server will extend respond with a SSH_FXP_NAME packet containing only
   one name and a dummy attributes value.  The name in the file if writing beyond returned
   packet contains the end target of the file. link.  If an error occurs, the
   server may respond with SSH_FXP_STATUS.

    The SSH_FXP_SYMLINK request will create a symbolic link on the
   server.  It is legal to write way beyond the end of the file; following format

   	uint32     id
   	string     linkpath
   	string     targetpath

   where `id' is the semantics are
to write zeroes from request identifier, `linkpath' specifies the end path
   name of the file symlink to the specified offset be created and
then `targetpath' specifies the data.  On most operating systems, such writes do not allocate
disk space but instead leave "holes" in
   target of the file. symlink.  The server responds to a write request shall respond with a
   SSH_FXP_STATUS message.

7.5.  Removing and Renaming Files

Files indicating either success (SSH_FX_OK) or an error
   condition.

6.11 Canonicalizing the Server-Side Path Name

    The SSH_FXP_REALPATH request can be removed using used to have the SSH_FXP_REMOVE message.  It has server
   canonicalize any given path name to an absolute path.  This is useful
   for converting path names containing ".." components or relative
   pathnames without a leading slash into absolute paths.  The format of
   the
following format: request is as follows:

   	uint32     id
   	string     filename     path

   where `id' is the request identifier and `filename' is `path' specifies the path
   name of the
file to be removed.  See Section ``File Names'' for more information.
This request cannot be used to remove directories. canonicalized.  The server will respond to this request with a SSH_FXP_STATUS message.

Files (and directories) can be renamed using the SSH_FXP_RENAME message.
Its data is as follows:

  uint32     id
  string     oldpath
  string     newpath

where `id' is the request identifier, `oldpath' is the
   SSH_FXP_NAME packet containing only one name of an exist-
ing file or directory, and `newpath' is the new a dummy attributes
   value.  The name for the file or
directory.  It is the returned packet will be in canonical form.

   If an error if there already exists a file with occurs, the name
specified by newpath.  The server may also fail rename requests in other
situations, for example if `oldpath' and `newpath' point to different
file systems on the server.

The server will respond to this request with a SSH_FXP_STATUS message.

7.6.  Creating and Deleting Directories

New directories can be created using the SSH_FXP_MKDIR request.  It has
the following format:

  uint32     id
  string     path
  ATTRS      attrs

where `id' is the request identifier, `path'and `attrs' specifies the
modifications to be made to its attributes.  See Section ``File Names''
for more information on file names.  Attributes are discussed in more
detail in Section ``File Attributes''.  specifies SSH_FXP_STATUS.

7. Responses from the directory Server to be
created.  An error will be returned if a file or directory with the
specified path already exists. Client

   The server will respond responds to this request
with a SSH_FXP_STATUS message.

Directories can be removed using the SSH_FXP_RMDIR request, which has client using one of a few response
   packets.  All requests can return a SSH_FXP_STATUS response upon
   failure.  When the following format:

  uint32     id
  string     path

where `id' operation is successful, any of the request identifier, and `path' specifies the directory
to responses may
   be removed.  See Section ``File Names'' for more information returned (depending on file
names.  An error will the operation).  If no data needs to be
   returned if no directory with to the specified
path exists, or if client, the specified directory SSH_FXP_STATUS response with SSH_FX_OK
   status is not empty, or if appropriate.  Otherwise, the path
specified a file system object other than a directory.  The server
responds SSH_FXP_HANDLE message is used
   to this request with a SSH_FXP_STATUS message.

7.7.  Scanning Directories

The files in return a directory can be listed using the SSH_FXP_OPENDIR file handle (for SSH_FXP_OPEN and
SSH_FXP_READDIR requests.  Each SSH_FXP_READDIR request returns SSH_FXP_OPENDIR
   requests), SSH_FXP_DATA is used to return data from SSH_FXP_READ,
   SSH_FXP_NAME is used to return one or more file names with full from a
   SSH_FXP_READDIR or SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is
   used to return file attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and
   SSH_FXP_FSTAT requests.

   Exactly one response will be returned for each file.  The client
should call SSH_FXP_READDIR repeatedly until it has found request.  Each
   response packet contains a request identifier which can be used to
   match each response with the file corresponding request.  Note that it is
looking for or until
   legal to have several requests outstanding simultaneously, and the
   server responds with is allowed to send responses to them in a SSH_FXP_STATUS message
indicating an error (normally SSH_FX_EOF if there are no more files different order from
   the order in which the requests were sent (the result of their
   execution, however, is guaranteed to be as if they had been processed
   one at a time in the directory).  The client should then close order in which the handle using requests were sent).

   Response packets are of the
SSH_FXP_CLOSE request. same general format as request packets.
   Each response packet begins with the request identifier.

    The SSH_FXP_OPENDIR opens a directory for reading.  It has format of the following
format: data portion of the SSH_FXP_STATUS response is as
   follows:

   	uint32     id
   	uint32     error/status code
   	string     path     error message (ISO-10646 UTF-8 [RFC-2279])
   	string     language tag (as defined in [RFC-1766])

   where `id' is the request identifier identifier, and `path' is `error/status code'
   indicates the path name result of the
directory to be listed (without any trailing slash).  See Section ``File
Names'' for more information on file names.  This will return an error
if the path does not specify a directory or if the directory is not
readable. requested operation.  The server will respond to this request with either a
SSH_FXP_HANDLE or a SSH_FXP_STATUS message.

Once value SSH_FX_OK
   indicates success, and all other values indicate failure.

    Currently, the directory has been successfully opened, files (and directories)
contained in it can be listed using SSH_FXP_READDIR requests.  These following values are defined (other values may be
   defined by future versions of this protocol):

   	#define SSH_FX_OK                            0
   	#define SSH_FX_EOF                           1
   	#define SSH_FX_NO_SUCH_FILE                  2
   	#define SSH_FX_PERMISSION_DENIED             3
   	#define SSH_FX_FAILURE                       4
   	#define SSH_FX_BAD_MESSAGE                   5
   	#define SSH_FX_NO_CONNECTION                 6
   	#define SSH_FX_CONNECTION_LOST               7
   	#define SSH_FX_OP_UNSUPPORTED                8

   SSH_FX_OK
      Indicates successful completion of the format

  uint32     id
  string     handle

where `id' operation.

   SSH_FX_EOF
      indicates end-of-file condition; for SSH_FX_READ it means that no
      more data is available in the request identifier, file, and `handle' for SSH_FX_READDIR it
      indicates that no more files are contained in the directory.

   SSH_FX_NO_SUCH_FILE
      is a handle returned
by SSH_FXP_OPENDIR.  (It is when a protocol error to attempt reference is made to use an ordi-
nary a file handle which should exist
      but doesn't.

   SSH_FX_PERMISSION_DENIED
      is returned by SSH_FXP_OPEN.)

The server responds when the authenticated user does not have sufficient
      permissions to this request with either a SSH_FXP_NAME or perform the operation.

   SSH_FX_FAILURE
      is a
SSH_FXP_STATUS message.  One or generic catch-all error message; it should be returned if an
      error occurs for which there is no more names specific error code
      defined.

   SSH_FX_BAD_MESSAGE
      may be returned at if a time.
Full status information badly formatted packet or protocol
      incompatibility is returned for each name in order to speed up
typical directory listings.

When detected.

   SSH_FX_NO_CONNECTION
      is a pseudo-error which indicates that the client has no longer wishes
      connection to read more names from the directory,
it SHOULD call SSH_FXP_CLOSE for server (it can only be generated locally by the handle.  The handle should
      client, and MUST NOT be
closed regardless of whether an error has occurred or not.

7.8.  Retrieving File Attributes

Very often, file attributes are automatically returned by
SSH_FXP_READDIR.  However, sometimes there servers).

   SSH_FX_CONNECTION_LOST
      is need a pseudo-error which indicates that the connection to specifically
retrieve the attributes for a named file.  This
      server has been lost (it can only be done using generated locally by the
SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests.

SSH_FXP_STAT
      client, and SSH_FXP_LSTAT only differ in MUST NOT be returned by servers).

   SSH_FX_OP_UNSUPPORTED
      indicates that SSH_FXP_STAT follows
symbolic links on an attempt was made to perform an operation which
      is not supported for the server (it may be generated locally by
      the client if e.g.  the version number exchange indicates that a
      required feature is not supported by the server, whereas SSH_FXP_LSTAT or it may be
      returned by the server if the server does not follow
symbolic links.  Both have implement an
      operation).

   The SSH_FXP_HANDLE response has the same following format:

   	uint32     id
   	string     path     handle

   where `id' is the request identifier, and `path' spefifies the file sys-
tem object for which status `handle' is to be returned.  The server responds to
this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS.

SSH_FXP_FSTAT differs from the others in an arbitrary
   string that it returns status
information for identifies an open file (identified by or directory on the file handle).  Its
format is as follows:

  uint32     id
  string server.  The
   handle

where `id' is the request identifier and `handle' is a file handle
returned by SSH_FXP_OPEN.  The server responds opaque to this request with
SSH_FXP_ATTRS or SSH_FXP_STATUS.

7.9.  Setting File Attributes

File attributes may be modified using the SSH_FXP_SETSTAT and
SSH_FXP_FSETSTAT requests.  These requests are used for operations such
as changing client; the ownership, permissions client MUST NOT attempt to
   interpret or access times, as well as for
truncating a file. modify it in any way.  The SSH_FXP_SETSTAT request is length of the handle string
   MUST NOT exceed 256 data bytes.

    The SSH_FXP_DATA response has the following format:

   	uint32     id
   	string     path
  ATTRS      attrs     data

   where `id' is the request identifier, `path' specifies the file system
object (e.g. file or directory) whose attributes are to be modified, and
`attrs' specifies the modifications to be made to its attributes.
Attributes are discussed in more detail in Section ``File Attributes''.

An error will be returned if the specified file system object does not
exist or the user does not have sufficient rights to modify `data' is an arbitrary byte
   string containing the
specified attributes.  The server responds to this request with a
SSH_FXP_STATUS message. requested data.  The SSH_FXP_FSETSTAT request modifies data string may be at most
   the attributes number of bytes requested in a SSH_FXP_READ request, but may also
   be shorter if end of file which is
already open.  It reached or if the read is from something
   other than a regular file.

    The SSH_FXP_NAME response has the following format:

   	uint32     id
   	uint32     count
   	repeats count times:
   		string     handle     filename
   		string     longname
   		ATTRS      attrs

   where `id' is the request identifier, `handle' (MUST be `count' is the number of names
   returned by
SSH_FXP_OPEN) identifies in this response, and the file whose attributes remaining fields repeat `count'
   times (so that all three fields are to first included for the first
   file, then for the second file, etc).  In the repeated part,
   `filename' is a file name being returned (for SSH_FXP_READDIR, it
   will be modified,
and `attrs' specifies a relative name within the modifications to directory, without any path
   components; for SSH_FXP_REALPATH it will be made an absolute path name),
   `longname' is an expanded format for the file name, similar to its attributes.
Attributes are discussed in more detail what
   is returned by "ls -l" on Unix systems, and `attrs' is the attributes
   of the file as described in Section ``File Attributes''.

   The server will respond to format of the `longname' field is unspecified by this request with SSH_FXP_STATUS.

7.10.  Dealing with Symbolic links

The SSH_FXP_READLINK request may protocol.
   It MUST be used to read suitable for use in the target output of a
symbolic link. It would have directory listing
   command (in fact, the recommended operation for a data part directory listing
   command is to simply display this data).  However, clients SHOULD NOT
   attempt to parse the longname field for file attributes; they SHOULD
   use the attrs field instead.

    The recommended format for the longname field is as follows:

  uint32     id
  string     path

where `id' is

   	-rwxr-xr-x   1 mjos     staff      348911 Mar 25 14:29 t-filexfer
   	1234567890 123 12345678 12345678 12345678 123456789012

   Here, the request identifier first line is sample output, and `path' specifies the path name second field indicates
   widths of the symlink to be read. various fields.  Fields are separated by spaces.  The server will respond with a SSH_FXP_NAME packet containing only one
name
   first field lists file permissions for user, group, and a dummy attributes value. The name in the returned packet
contains the target of the link. If an error occurs, others; the server may
respond with SSH_FXP_STATUS.

The SSH_FXP_SYMLINK request will create a symbolic
   second field is link on count; the server.
It third field is the name of the following format

  uint32     id
  string     linkpath
  string     targetpath

where `id' is user
   who owns the request identifier, `linkpath' specifies file; the fourth field is the path name of the symlink to be created and `targetpath' specifies group that
   owns the target file; the fifth field is the size of the symlink. The server shall respond with a SSH_FXP_STATUS indicating
either success (SSH_FX_OK) or an error condition.

7.11.  Canonicalizing file in bytes; the Server-Side Path Name

The SSH_FXP_REALPATH request can be used
   sixth field (which actually may contain spaces, but is fixed to have 12
   characters) is the server canonicalize
any given path name to an absolute path.  This file modification time, and the seventh field is useful for converting
path names containing ".." components or relative pathnames without
   the file name.  Each field is specified to be a
leading slash into absolute paths. minimum of certain
   number of character positions (indicated by the second line above),
   but may also be longer if the data does not fit in the specified
   length.

    The format of SSH_FXP_ATTRS response has the request is as
follows: following format:

   	uint32     id
  string     path
   	ATTRS      attrs

   where `id' is the request identifier and `path' specifies the path name
to be canonicalized.  The server will respond with a SSH_FXP_NAME packet
containing only one name identifier, and a dummy attributes value.  The name `attrs' is the returned packet will be
   file attributes as described in canonical form.  If an error occurs, the
server may also respond with SSH_FXP_STATUS. Section ``File Attributes''.

8. Vendor-Specific Extensions

    The SSH_FXP_EXTENDED request provides a generic extension mechanism
   for adding vendor-specific commands.  The request has the following
   format:

   	uint32     id
   	string     extended-request
   	... any request-specific data ...

   where `id' is the request identifier, and `extended-request' is a
   string of the format "name@domain", where domain is an internet
   domain name of the vendor defining the request.  The rest of the
   request is completely vendor-specific, and servers should only
   attempt to interpret it if they recognize the `extended-request'
   name.

   The server may respond to such requests using any of the response
   packets defined in Section ``Responses from the Server to the
   Client''.  Additionally, the server may also respond with a
   SSH_FXP_EXTENDED_REPLY packet, as defined below.  If the server does
   not recognize the `extended-request' name, then the server MUST
   respond with SSH_FXP_STATUS with error/status set to
   SSH_FX_OP_UNSUPPORTED.

    The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary
   extension-specific data from the server to the client.  It is of the
   following format:

   	uint32     id
   	... any request-specific data ...

9. Security Considerations

   This protocol assumes that it is run over a secure channel and that
   the endpoints of the channel have been authenticated.  Thus, this
   protocol assumes that it is externally protected from network-level
   attacks.

   This protocol provides file system access to arbitrary files on the
   server (only constrained by the server implementation).  It is the
   responsibility of the server implementation to enforce any access
   controls that may be required to limit the access allowed for any
   particular user (the user being authenticated externally to this
   protocol, typically using the Secure Shell SSH User Authentication Protocol
[SECSH-USERAUTH]. [6].

   Care must be taken in the server implementation to check the validity
   of received file handle strings.  The server should not rely on them
   directly; it MUST check the validity of each handle before relying on
   it.

10. Changes from previous protocol versions

   The Secure Shell SSH File Transfer Protocol has changed over time, before it's
   standardization.  The following is a description of the incompatible
   changes between different versions.

10.1.

10.1 Changes between versions 3 and 2

   o  The SSH_FXP_READLINK and SSH_FXP_SYMLINK mesages messages were added.

   o  The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were
      added.

   o  The SSH_FXP_STATUS message was changed to include fields `error
      message' and `language tag'.

10.2.

10.2 Changes between versions 2 and 1

   o  The SSH_FXP_RENAME message was added.

10.3.

10.3 Changes between versions 1 and 0

   o  Implementation changes, no actual protocol changes.

11. Trademark Issues

   "ssh" is a registered trademark of SSH Communications Security Corp
   in the United States and/or other countries.

12.

References

[RFC-2246]

   [1]  Dierks, T. and T., Allen, C.: C., Treese, W., Karlton, P., Freier, A. and
        P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999

[POSIX] ISO/IEC Std 9945-1, ANSI/IEEE Std 1003.1 Information technology
--
        1999.

   [2]  Institute of Electrical and Electronics Engineers, "Information
        Technology - Portable Operating System Interface (POSIX)-Part (POSIX) - Part
        1: System Application Program Interface (API) [C Language], July Language]",
        IEEE Standard 1003.2, 1996.

[SECSH-ARCH]

   [3]  Rinne, T., Ylonen, T., et al: "Secure Shell Kivinen, T., Saarinen, M. and S.
        Lehtinen, "SSH Protocol Architecture",
Internet-Draft, draft-ietf-secsh-architecture-08.txt

[SECSH-TRANSPORT] draft-ietf-secsh-
        architecture-09 (work in progress), July 2001.

   [4]  Rinne, T., Ylonen, T., et al: "Secure Shell Kivinen, T., Saarinen, M. and S.
        Lehtinen, "SSH Protocol Transport Protocol",
Internet-Draft, draft-ietf-secsh-transport-10.txt

[SECSH-USERAUTH] draft-ietf-secsh-
        architecture-09 (work in progress), July 2001.

   [5]  Rinne, T., Ylonen, T., et al: "Secure Shell Authentication Kivinen, T., Saarinen, M. and S.
        Lehtinen, "SSH Connection Protocol", Internet-Draft, draft-ietf-secsh-userauth-10.txt

[SECSH-CONNECT] draft-ietf-secsh-connect-11
        (work in progress), July 2001.

   [6]  Rinne, T., Ylonen, T., et al: "Secure Shell Connection Kivinen, T., Saarinen, M. and S.
        Lehtinen, "SSH Authentication Protocol",
Internet-Draft, draft-ietf-secsh-connect-10.txt

13. draft-ietf-secsh-
        userauth-11 (work in progress), July 2001.

Authors' Addresses

   Tatu Ylonen
   SSH Communications Security Corp
   Fredrikinkatu 42
    FIN-00100
   HELSINKI  FIN-00100
   Finland
    E-mail:

   EMail: ylo@ssh.com

   Sami Lehtinen
   SSH Communications Security Corp
   Fredrikinkatu 42
    FIN-00100
   HELSINKI  FIN-00100
   Finland
    E-mail:

   EMail: sjl@ssh.com

Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.