draft-ietf-secsh-filexfer-04.txt   draft-ietf-secsh-filexfer-05.txt 
Secure Shell Working Group J. Galbraith Secure Shell Working Group J. Galbraith
Internet-Draft VanDyke Software Internet-Draft VanDyke Software
Expires: June 18, 2003 T. Ylonen Expires: July 1, 2004 T. Ylonen
S. Lehtinen S. Lehtinen
SSH Communications Security Corp SSH Communications Security Corp
December 18, 2002 January 2004
SSH File Transfer Protocol SSH File Transfer Protocol
draft-ietf-secsh-filexfer-04.txt draft-ietf-secsh-filexfer-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as groups may also distribute working documents as Internet-Drafts.
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 18, 2003. This Internet-Draft will expire on July 1, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
The SSH File Transfer Protocol provides secure file transfer The SSH File Transfer Protocol provides secure file transfer
functionality over any reliable data stream. It is the standard file functionality over any reliable data stream. It is the standard file
transfer protocol for use with the SSH2 protocol. This document transfer protocol for use with the SSH2 protocol. This document
describes the file transfer protocol and its interface to the SSH2 describes the file transfer protocol and its interface to the SSH2
protocol suite. protocol suite.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use with the SSH Connection Protocol . . . . . . . . . . . 4 2. Use with the SSH Connection Protocol . . . . . . . . . . . 5
3. General Packet Format . . . . . . . . . . . . . . . . . . 5 2.1 The Use of 'stderr' in the server . . . . . . . . . . . . 5
3.1 The use of stderr in the server . . . . . . . . . . . . . 6 3. General Packet Format . . . . . . . . . . . . . . . . . . 6
3.1 Packet Types . . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Initialization . . . . . . . . . . . . . . . . . 8 4. Protocol Initialization . . . . . . . . . . . . . . . . . 8
4.1 Client Initialization . . . . . . . . . . . . . . . . . . 8 4.1 Client Initialization . . . . . . . . . . . . . . . . . . 8
4.2 Server Initialization . . . . . . . . . . . . . . . . . . 8 4.2 Server Initialization . . . . . . . . . . . . . . . . . . 8
4.3 Determining Server Newline Convention . . . . . . . . . . 9 4.3 Determining Server Newline Convention . . . . . . . . . . 9
5. File Attributes . . . . . . . . . . . . . . . . . . . . . 10 4.4 Supported Features . . . . . . . . . . . . . . . . . . . . 9
5.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. File Attributes . . . . . . . . . . . . . . . . . . . . . 12
5.2 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1 valid-attribute-flags . . . . . . . . . . . . . . . . . . 12
5.3 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4 Owner and Group . . . . . . . . . . . . . . . . . . . . . 11 5.3 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5 Permissions . . . . . . . . . . . . . . . . . . . . . . . 12 5.4 Owner and Group . . . . . . . . . . . . . . . . . . . . . 14
5.6 Times . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.5 Permissions . . . . . . . . . . . . . . . . . . . . . . . 14
5.7 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.6 Times . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.8 Extended attributes . . . . . . . . . . . . . . . . . . . 14 5.7 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Requests From the Client to the Server . . . . . . . . . . 15 5.8 attrib-bits . . . . . . . . . . . . . . . . . . . . . . . 17
6.1 Request Synchronization and Reordering . . . . . . . . . . 15 5.9 Extended Attributes . . . . . . . . . . . . . . . . . . . 19
6.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Requests From the Client to the Server . . . . . . . . . . 20
6.3 Opening, Creating, and Closing Files . . . . . . . . . . . 16 6.1 Request Synchronization and Reordering . . . . . . . . . . 20
6.4 Reading and Writing . . . . . . . . . . . . . . . . . . . 19 6.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . 20
6.5 Removing and Renaming Files . . . . . . . . . . . . . . . 20 6.3 Opening and Closing Files and Directories . . . . . . . . 21
6.6 Creating and Deleting Directories . . . . . . . . . . . . 21 6.3.1 Opening a File . . . . . . . . . . . . . . . . . . . . . . 21
6.7 Scanning Directories . . . . . . . . . . . . . . . . . . . 21 6.3.2 Opening a Directory . . . . . . . . . . . . . . . . . . . 25
6.8 Retrieving File Attributes . . . . . . . . . . . . . . . . 22 6.3.3 Closing Handles . . . . . . . . . . . . . . . . . . . . . 26
6.9 Setting File Attributes . . . . . . . . . . . . . . . . . 23 6.4 Reading and Writing . . . . . . . . . . . . . . . . . . . 26
6.10 Dealing with Symbolic links . . . . . . . . . . . . . . . 24 6.4.1 Reading Files . . . . . . . . . . . . . . . . . . . . . . 26
6.11 Canonicalizing the Server-Side Path Name . . . . . . . . . 25 6.4.2 Reading Directories . . . . . . . . . . . . . . . . . . . 27
6.11.1 Best practice for dealing with paths . . . . . . . . . . . 25 6.4.3 Writing Files . . . . . . . . . . . . . . . . . . . . . . 27
7. Responses from the Server to the Client . . . . . . . . . 26 6.5 Removing and Renaming Files . . . . . . . . . . . . . . . 28
8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . 30 6.6 Creating and Deleting Directories . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . 31 6.7 Retrieving File Attributes . . . . . . . . . . . . . . . . 30
10. Changes from previous protocol versions . . . . . . . . . 32 6.8 Setting File Attributes . . . . . . . . . . . . . . . . . 30
10.1 Changes between versions 4 and 3 . . . . . . . . . . . . . 32 6.9 Dealing with Symbolic Links . . . . . . . . . . . . . . . 31
10.2 Changes between versions 3 and 2 . . . . . . . . . . . . . 33 6.10 Canonicalizing the Server-Side Path Name . . . . . . . . . 32
10.3 Changes between versions 2 and 1 . . . . . . . . . . . . . 33 6.10.1 Best Practice for Dealing with Paths . . . . . . . . . . . 32
10.4 Changes between versions 1 and 0 . . . . . . . . . . . . . 33 7. Responses from the Server to the Client . . . . . . . . . 34
11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . 34 8. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 39
References . . . . . . . . . . . . . . . . . . . . . . . . 35 8.1 Checking File Contents . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 35 9. Security Considerations . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . 37 10. Changes from Previous Protocol Versions . . . . . . . . . 43
10.1 Changes Between Versions 5 and 4 . . . . . . . . . . . . . 43
10.2 Changes Between Versions 4 and 3 . . . . . . . . . . . . . 44
10.3 Changes Between Versions 3 and 2 . . . . . . . . . . . . . 44
10.4 Changes Between Versions 2 and 1 . . . . . . . . . . . . . 45
10.5 Changes Between Versions 1 and 0 . . . . . . . . . . . . . 45
11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . 46
Normative References . . . . . . . . . . . . . . . . . . . 47
Informative References . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . 49
1. Introduction 1. Introduction
This protocol provides secure file transfer (and more generally file This protocol provides secure file transfer (and more generally file
system access) functionality over a reliable data stream, such as a system access.) It is designed so that it could be used to implement
channel in the SSH2 protocol [5]. a secure remote file system service, as well as a secure file
transfer service.
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 This protocol assumes that it runs over a secure channel, such as a
the server has already authenticated the user at the client end, and channel in the SSH2 protocol [3]. and that the server has already
that the identity of the client user is externally available to the authenticated the client, and that the identity of the client user is
server implementation. available to the protocol.
In general, this protocol follows a simple request-response model. In general, this protocol follows a simple request-response model.
Each request and response contains a sequence number and multiple Each request and response contains a sequence number and multiple
requests may be pending simultaneously. There are a relatively large requests may be pending simultaneously. There are a relatively large
number of different request messages, but a small number of possible number of different request messages, but a small number of possible
response messages. Each request has one or more response messages response messages. Each request has one or more response messages
that may be returned in result (e.g., a read either returns data or that may be returned in result (e.g., a read either returns data or
reports error status). reports error status).
The packet format descriptions in this specification follow the The packet format descriptions in this specification follow the
notation presented in the secsh architecture draft. [5] notation presented in the secsh architecture draft. [3]
Even though this protocol is described in the context of the SSH2 Even though this protocol is described in the context of the SSH2
protocol, this protocol is general and independent of the rest of the protocol, this protocol is general and independent of the rest of the
SSH2 protocol suite. It could be used in a number of different SSH2 protocol suite. It could be used in a number of different
applications, such as secure file transfer over TLS RFC 2246 [1] and applications, such as secure file transfer over TLS RFC 2246 [6] and
transfer of management information in VPN applications. transfer of management information in VPN applications.
2. Use with the SSH Connection Protocol 2. Use with the SSH Connection Protocol
When used with the SSH2 Protocol suite, this protocol is intended to When used with the SSH2 Protocol suite, this protocol is intended to
be used from the SSH Connection Protocol [7] as a subsystem, as be used from the SSH Connection Protocol [5] as a subsystem, as
described in section ``Starting a Shell or a Command''. The described in section ''Starting a Shell or a Command''. The subsystem
subsystem name used with this protocol is "sftp". name used with this protocol is "sftp".
2.1 The Use of 'stderr' in the server
This protocol uses stdout and stdin to transmit binary protocol data.
The "session" channel SSH Connection Protocol [5], which is used by
the subsystem, also supports the use of stderr.
Data sent on stderr by the server SHOULD be considered free format
debug or supplemental error information, and MAY be displayed to the
user.
For example, during initialization, there is no client request
active, so errors or warning information cannot be sent to the client
as part of the SFTP protocol at this early stage. However, the
errors or warnings MAY be sent as stderr text.
3. General Packet Format 3. General Packet Format
All packets transmitted over the secure connection are of the All packets transmitted over the secure connection are of the
following format: following format:
uint32 length uint32 length
byte type byte type
byte[length - 1] data payload byte[length - 1] data payload
That is, they are just data preceded by 32-bit length and 8-bit type That is, they are data preceded by 32-bit length and 8-bit type
fields. The `length' is the length of the data area, and does not fields. The 'length' is the length of the data area, and does not
include the `length' field itself. The format and interpretation of include the 'length' field itself. The format and interpretation of
the data area depends on the packet type. the data area depends on the packet type.
All packet descriptions below only specify the packet type and the All packet descriptions specify the packet type and the data that
data that goes into the data field. Thus, they should be prefixed by goes into the data field. Thus, they should be prefixed by the
the `length' and `type' fields. 'length' fields.
This document defines one data type in addition to those defined in
secsh architecture draft. [3]
int64
Represents a 64-bit signed integer. Stored as eight bytes in the
order of decreasing significance (network byte order).
The maximum size of a packet is in practice determined by the client The maximum size of a packet is in practice determined by the client
(the maximum size of read or write requests that it sends, plus a few (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 bytes of packet overhead). All servers SHOULD support packets of at
least 34000 bytes (where the packet size refers to the full length, least 34000 bytes (where the packet size refers to the full length,
including the header above). This should allow for reads and writes including the header above). This should allow for reads and writes
of at most 32768 bytes. of at most 32768 bytes.
There is no limit on the number of outstanding (non-acknowledged) There is no limit on the number of outstanding (non-acknowledged)
requests that the client may send to the server. In practice this is requests that the client may send to the server. In practice this is
limited by the buffering available on the data stream and the queuing 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 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 not read any more data from the stream, and flow control will prevent
the client from sending more requests. Note, however, that while the client from sending more requests. Note, however, that while
there is no restriction on the protocol level, the client's API may there is no restriction on the protocol level, the client's API may
provide a limit in order to prevent infinite queuing of outgoing provide a limit in order to prevent infinite queuing of outgoing
requests at the client. requests at the client.
3.1 Packet Types
The following values are defined for packet types. The following values are defined for packet types.
#define SSH_FXP_INIT 1 #define SSH_FXP_INIT 1
#define SSH_FXP_VERSION 2 #define SSH_FXP_VERSION 2
#define SSH_FXP_OPEN 3 #define SSH_FXP_OPEN 3
#define SSH_FXP_CLOSE 4 #define SSH_FXP_CLOSE 4
#define SSH_FXP_READ 5 #define SSH_FXP_READ 5
#define SSH_FXP_WRITE 6 #define SSH_FXP_WRITE 6
#define SSH_FXP_LSTAT 7 #define SSH_FXP_LSTAT 7
#define SSH_FXP_FSTAT 8 #define SSH_FXP_FSTAT 8
skipping to change at page 6, line 38 skipping to change at page 7, line 38
#define SSH_FXP_DATA 103 #define SSH_FXP_DATA 103
#define SSH_FXP_NAME 104 #define SSH_FXP_NAME 104
#define SSH_FXP_ATTRS 105 #define SSH_FXP_ATTRS 105
#define SSH_FXP_EXTENDED 200 #define SSH_FXP_EXTENDED 200
#define SSH_FXP_EXTENDED_REPLY 201 #define SSH_FXP_EXTENDED_REPLY 201
RESERVED_FOR_EXTENSIONS 210-255 RESERVED_FOR_EXTENSIONS 210-255
Additional packet types should only be defined if the protocol Additional packet types should only be defined if the protocol
version number (see Section ``Protocol Initialization'') is version number (see Section ''Protocol Initialization'') is
incremented, and their use MUST be negotiated using the version incremented, and their use MUST be negotiated using the version
number. However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY number. However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY
packets can be used to implement vendor-specific extensions. See packets can be used to implement extensions, which can be vendor
Section ``Vendor-Specific-Extensions'' for more details. specific. See Section ''Extensions'' for more details.
3.1 The use of stderr in the server
Packets are sent and received on stdout and stdin. Data sent on
stderr by the server SHOULD be considered debug or supplemental error
information, and MAY be displayed to the user.
For example, during initialization, there is no client request
active, so errors or warning information cannot be sent to the client
as part of the SFTP protocol at this early stage. However, the
errors or warnings MAY be sent as stderr text.
4. Protocol Initialization 4. Protocol Initialization
When the file transfer protocol starts, the client first sends a When the file transfer protocol starts, the client first sends a
SSH_FXP_INIT (including its version number) packet to the server. SSH_FXP_INIT (including its version number) packet to the server. The
The server responds with a SSH_FXP_VERSION packet, supplying the server responds with a SSH_FXP_VERSION packet, supplying the lowest
lowest of its own and the client's version number. Both parties of its own and the client's version number. Both parties should from
should from then on adhere to particular version of the protocol. then on adhere to particular version of the protocol.
The version number of the protocol specified in this document is 4. The version number of the protocol specified in this document is 5.
The version number should be incremented for each incompatible The version number should be incremented for each incompatible
revision of this protocol. revision of this protocol.
4.1 Client Initialization 4.1 Client Initialization
The SSH_FXP_INIT packet (from client to server) has the following The SSH_FXP_INIT packet (from client to server) has the following
data: data:
uint32 version uint32 version
skipping to change at page 8, line 52 skipping to change at page 8, line 52
'version' is the lower of the protocol version supported by the 'version' is the lower of the protocol version supported by the
server and the version number received from the client. server and the version number received from the client.
The extension data may be empty, or may be a sequence of The extension data may be empty, or may be a sequence of
string extension_name string extension_name
string extension_data string extension_data
pairs (both strings MUST always be present if one is, but the pairs (both strings MUST always be present if one is, but the
`extension_data' string may be of zero length). If present, these 'extension_data' string may be of zero length). If present, these
strings indicate extensions to the baseline protocol. The strings indicate extensions to the baseline protocol. The
`extension_name' field(s) identify the name of the extension. 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 name should be of the form "name@domain", where the domain is the DNS
domain name of the organization defining the extension. Additional domain name of the organization defining the extension. Additional
names that are not of this format may be defined later by the IETF. names that are not of this format may be defined later by the IETF.
Implementations MUST silently ignore any extensions whose name they Implementations MUST silently ignore any extensions whose name they
do not recognize. do not recognize.
4.3 Determining Server Newline Convention 4.3 Determining Server Newline Convention
In order to correctly process text files in a cross platform In order to correctly process text files in a cross platform
compatible way, the newline convention must be converted from that of compatible way, newline sequences must be converted between client
the server to that of the client, or, during an upload, from that of and server conventions.
the client to that of the server.
Versions 3 and prior of this protocol made no provisions for
processing text files. Many clients implemented some sort of
conversion algorithm, but without either a 'canonical' on the wire
format or knowledge of the servers newline convention, correct
conversion was not always possible.
Starting with Version 4, the SSH_FXF_TEXT file open flag (Section The SSH_FXF_TEXT file open flag (Section 6.3.1) makes it possible to
6.3) makes it possible to request that the server translate a file to request that the server translate a file to a 'canonical' wire
a 'canonical' on the wire format. This format uses \r\n as the line format. This format uses \r\n as the line separator.
separator.
Servers for systems using multiple newline characters (for example, Servers for systems using multiple newline characters (for example,
Mac OS X or VMS) or systems using counted records, MUST translate to Mac OS X or VMS) or systems using counted records, MUST translate to
the canonical form. the canonical form.
However, to ease the burden of implementation on servers that use a However, to ease the burden of implementation on servers that use a
single, simple separator sequence, the following extension allows the single, simple separator sequence, the following extension allows the
canonical format to be changed. canonical format to be changed.
string "newline" string "newline"
string new-canonical-separator (usually "\r" or "\n" or "\r\n") string new-canonical-separator (usually "\r" or "\n" or "\r\n")
All clients MUST support this extension. All clients MUST support this extension.
When processing text files, clients SHOULD NOT translate any When processing text files, clients SHOULD NOT translate any
character or sequence that is not an exact match of the servers character or sequence that is not an exact match of the server's
newline separator. newline separator.
In particular, if the newline sequence being used is the canonical In particular, if the newline sequence being used is the canonical
"\r\n" sequence, a lone \r or a lone \n SHOULD be written through "\r\n" sequence, a lone "\r" or a lone "\n" SHOULD be written through
without change. without change.
4.4 Supported Features
The sftp protocol has grown to be very rich, and now supports a
number of features that may not be available on all servers.
When a server receives a request for a feature it cannot support, it
MUST return a SSH_FX_OP_UNSUPPORTED status code, unless otherwise
specified. In order to facilitate clients being able to use the
maximum available feature set, and yet not be overly burdened by
dealing with SSH_FX_OP_UNSUPPORTED status codes, the following
extension is introduced.
string "supported"
string supported-structure
uint32 supported-attribute-mask
uint32 supported-attribute-bits
uint32 supported-open-flags
uint32 supported-access-mask
uint32 max-read-size
string extension-names[0..n]
supported-attribute-mask
This mask MAY by applied to the 'File Attributes'
valid-attribute-flags field (Section 5.1) to ensure that no
unsupported attributes are present during a operation which writes
attributes.
supported-attribute-bits
This mask MAY by applied to the 'File Attributes' attrib-bits
field (Section 5.8) to ensure that no unsupported attrib-bits are
present during a operation which writes attributes.
supported-open-flags
The supported-open-flags mask MAY be applied to the SSH_FXP_OPEN
(Section 6.3.1) flags field.
supported-access-mask
The supported-access-mask mask MAY be applied to the SSH_FXP_OPEN
(Section 6.3.1) desired-access field or the ace-mask field of an
ACL.
max-read-size
This is the maximum read size that the server gaurantees to
complete. For example, certain embedded server implementations
only complete the first 4K of a read, even if there is additional
data to be read from the file.
If the server specifies a non-zero value, it MUST return at least
the max-read-size number of bytes for any read requesting
max-read-size bytes. Failure to return max-read-size bytes in
such a case indicates either EOF or another error condition
occurred.
extension names
The extension names may be empty (contains zero strings), or it
may contain any named extensions that the server wishes to
advertise.
The client must be able to differentiate between attribute
extensions (Section 5.9) and extended requests (Section 8) by the
extension name.
Naturally, if a given attribute field, attribute mask bit, open flag,
or extension is required for correct operation, the client MUST
either not allow the bit to be masked off, or MUST fail the operation
gracefully without sending the request to the server.
The client MAY send requests that are not supported by the server;
however, it is not normally expected to be productive to do so. The
client SHOULD apply the mask even to attrib structures received from
the server. The server MAY include attributes or attrib-bits that
are not included in the mask. Such attributes or attrib-bits are
effectively read-only.
5. File Attributes 5. File Attributes
A new compound data type is defined for encoding file attributes. A new compound data type is defined for encoding file attributes. The
The same encoding is used both when returning file attributes from same encoding is used both when returning file attributes from the
the server and when sending file attributes to the server. When server and when sending file attributes to the server.
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 uint32 valid-attribute-flags
byte type always present byte type always present
uint64 size present only if flag SIZE uint64 size present only if flag SIZE
string owner present only if flag OWNERGROUP string owner present only if flag OWNERGROUP
string group present only if flag OWNERGROUP string group present only if flag OWNERGROUP
uint32 permissions present only if flag PERMISSIONS uint32 permissions present only if flag PERMISSIONS
uint64 atime present only if flag ACCESSTIME int64 atime present only if flag ACCESSTIME
uint32 atime_nseconds present only if flag SUBSECOND_TIMES uint32 atime_nseconds present only if flag SUBSECOND_TIMES
uint64 createtime present only if flag CREATETIME int64 createtime present only if flag CREATETIME
uint32 createtime_nseconds present only if flag SUBSECOND_TIMES uint32 createtime_nseconds present only if flag SUBSECOND_TIMES
uint64 mtime present only if flag MODIFYTIME int64 mtime present only if flag MODIFYTIME
uint32 mtime_nseconds present only if flag SUBSECOND_TIMES uint32 mtime_nseconds present only if flag SUBSECOND_TIMES
string acl present only if flag ACL string acl present only if flag ACL
uint32 attrib-bits present only if flag BITS
uint32 extended_count present only if flag EXTENDED uint32 extended_count present only if flag EXTENDED
string extended_type string extended_type
string extended_data string extended_data
... more extended data (extended_type - extended_data pairs), ... more extended data (extended_type - extended_data pairs),
so that number of pairs equals extended_count so that number of pairs equals extended_count
5.1 Flags 5.1 valid-attribute-flags
The `flags' specify which of the fields are present. Those fields The 'valid-attribute-flags' specifies which of the fields are
for which the corresponding flag is not set are not present (not present. Those fields for which the corresponding flag is not set are
included in the packet). New flags can only be added by incrementing not present (not included in the packet).
the protocol version number (or by using the extension mechanism
described below).
The flags bits are defined to have the following values: The server generally includes all attributes it knows about; however,
it may exclude attributes that are overly expensive to retrieve
unless the client explicitly requests them.
When writing attributes, the server SHOULD NOT modify attributes that
are not present in the structure. However, if necessary, the server
MAY use a default value for an absent attribute.
New fields can only be added by incrementing the protocol version
number (or by using the extension mechanism described below).
The following values are defined:
#define SSH_FILEXFER_ATTR_SIZE 0x00000001 #define SSH_FILEXFER_ATTR_SIZE 0x00000001
#define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000040 #define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004
#define SSH_FILEXFER_ATTR_ACCESSTIME 0x00000008 #define SSH_FILEXFER_ATTR_ACCESSTIME 0x00000008
#define SSH_FILEXFER_ATTR_CREATETIME 0x00000010 #define SSH_FILEXFER_ATTR_CREATETIME 0x00000010
#define SSH_FILEXFER_ATTR_MODIFYTIME 0x00000020 #define SSH_FILEXFER_ATTR_MODIFYTIME 0x00000020
#define SSH_FILEXFER_ATTR_ACL 0x00000040 #define SSH_FILEXFER_ATTR_ACL 0x00000040
#define SSH_FILEXFER_ATTR_OWNERGROUP 0x00000080 #define SSH_FILEXFER_ATTR_OWNERGROUP 0x00000080
#define SSH_FILEXFER_ATTR_SUBSECOND_TIMES 0x00000100 #define SSH_FILEXFER_ATTR_SUBSECOND_TIMES 0x00000100
#define SSH_FILEXFER_ATTR_BITS 0x00000200
#define SSH_FILEXFER_ATTR_EXTENDED 0x80000000 #define SSH_FILEXFER_ATTR_EXTENDED 0x80000000
In previous versions of this protocol flags value 0x00000002 was 0x00000002 was used in a previous version of this protocol. It is
SSH_FILEXFER_ATTR_UIDGID. This value is now unused, and OWNERGROUP now a reserved value and MUST NOT appear in the mask. Some future
was given a new value in order to ease implementation burden. version of this protocol may reuse this value.
0x00000002 MUST NOT appear in the mask. Some future version of this
protocol may reuse flag 0x00000002.
5.2 Type 5.2 Type
The type field is always present. The following types are defined: The type field is always present. The following types are defined:
#define SSH_FILEXFER_TYPE_REGULAR 1 #define SSH_FILEXFER_TYPE_REGULAR 1
#define SSH_FILEXFER_TYPE_DIRECTORY 2 #define SSH_FILEXFER_TYPE_DIRECTORY 2
#define SSH_FILEXFER_TYPE_SYMLINK 3 #define SSH_FILEXFER_TYPE_SYMLINK 3
#define SSH_FILEXFER_TYPE_SPECIAL 4 #define SSH_FILEXFER_TYPE_SPECIAL 4
#define SSH_FILEXFER_TYPE_UNKNOWN 5 #define SSH_FILEXFER_TYPE_UNKNOWN 5
#define SSH_FILEXFER_TYPE_SOCKET 6
#define SSH_FILEXFER_TYPE_CHAR_DEVICE 7
#define SSH_FILEXFER_TYPE_BLOCK_DEVICE 8
#define SSH_FILEXFER_TYPE_FIFO 9
On a POSIX system, these values would be derived from the permission On a POSIX system, these values would be derived from the mode field
field. of the stat structure. SPECIAL should be used for files that are of
a known type which cannot be expressed in the protocol. UNKNOWN
should be used if the type is not known.
5.3 Size 5.3 Size
The `size' field specifies the size of the file on disk, in bytes. The 'size' field specifies the size of the file on disk, in bytes. If
If it is present during file creation, it should be considered a hint it is present during file creation, it SHOULD be considered a hint as
as to the files eventual size. to the file's eventual size.
If this field is present during a setstat operation, the file MUST be
extended or truncated to the specified size. Clients SHOULD
therefore be careful specifying size during a setstat operation.
Files opened with the SSH_FXF_TEXT flag may have a size that is Files opened with the SSH_FXF_TEXT flag may have a size that is
greater or less than the value of the size field. greater or less than the value of the size field.
5.4 Owner and Group 5.4 Owner and Group
The `owner' and `group' fields are represented as UTF-8 strings; this The 'owner' and 'group' fields are represented as UTF-8 strings; this
is the form used by NFS v4. See NFS version 4 Protocol. [3] The is the form used by NFS v4. See NFS version 4 Protocol [1]. The
following text is selected quotations from section 5.6. following text is selected quotations from section 5.6.
To avoid a representation that is tied to a particular underlying To avoid a representation that is tied to a particular underlying
implementation at the client or server, the use of UTF-8 strings has implementation at the client or server, the use of UTF-8 strings has
been chosen. The string should be of the form user@dns_domain". been chosen. The string should be of the form user@dns_domain". This
This will allow for a client and server that do not use the same will allow for a client and server that do not use the same local
local representation the ability to translate to a common syntax that representation the ability to translate to a common syntax that can
can be interpreted by both. In the case where there is no be interpreted by both. In the case where there is no translation
translation available to the client or server, the attribute value available to the client or server, the attribute value must be
must be constructed without the "@". Therefore, the absence of the @ constructed without the "@". Therefore, the absence of the @ from
from the owner or owner_group attribute signifies that no translation the owner or owner_group attribute signifies that no translation was
was available and the receiver of the attribute should not place any available and the receiver of the attribute should not place any
special meaning with the attribute value. Even though the attribute special meaning with the attribute value. Even though the attribute
value can not be translated, it may still be useful. In the case of value cannot be translated, it may still be useful. In the case of a
a client, the attribute string may be used for local display of client, the attribute string may be used for local display of
ownership. ownership.
user@localhost represents a user in the context of the server.
If either the owner or group field is zero length, the field should
be considered absent, and no change should be made to that specific
field.
5.5 Permissions 5.5 Permissions
The `permissions' field contains a bit mask of file permissions as The 'permissions' field contains a bit mask specifying file
defined by POSIX [1]. permissions. These permissions correspond to the st_mode field of
the stat structure defined by POSIX [2].
This protocol uses the following values for the symbols declared in
the posix standard.
#define S_IRUSR 0000400 (octal)
#define S_IWUSR 0000200
#define S_IXUSR 0000100
#define S_IRGRP 0000040
#define S_IWGRP 0000020
#define S_IXGRP 0000010
#define S_IROTH 0000004
#define S_IWOTH 0000002
#define S_IXOTH 0000001
#define S_ISUID 0004000
#define S_ISGID 0002000
#define S_ISVTX 0001000
Implementations MUST NOT send bits that are not defined.
5.6 Times 5.6 Times
The 'atime', 'createtime', and 'mtime' contain the access, creation, The 'atime', 'createtime', and 'mtime' contain the accesses,
and modification times of the files, respectively. They are creation, and modification times of the files, respectively. They
represented as seconds from Jan 1, 1970 in UTC. are represented as seconds from Jan 1, 1970 in UTC.
A negative value indicates number of seconds before Jan 1, 1970. In A negative value indicates number of seconds before Jan 1, 1970. In
both cases, if the SSH_FILEXFER_ATTR_SUBSECOND_TIMES flag is set, the both cases, if the SSH_FILEXFER_ATTR_SUBSECOND_TIMES flag is set, the
nseconds field is to be added to the seconds field for the final time nseconds field is to be added to the seconds field for the final time
representation. For example, if the time to be represented is representation. For example, if the time to be represented is
one-half second before 0 hour January 1, 1970, the seconds field one-half second before 0 hour January 1, 1970, the seconds field
would have a value of negative one (-1) and the nseconds fields would would have a value of negative one (-1) and the nseconds fields would
have a value of one-half second (500000000). Values greater than have a value of one-half second (500000000). Values greater than
999,999,999 for nseconds are considered invalid. 999,999,999 for nseconds are considered invalid.
5.7 ACL 5.7 ACL
The 'ACL' field contains an ACL similar to that defined in section The 'ACL' field contains an ACL similar to that defined in section
5.9 of NFS version 4 Protocol [3]. 5.9 of NFS version 4 Protocol [1].
uint32 ace-count uint32 ace-count
repeated ace-count time: repeated ace-count time:
uint32 ace-type uint32 ace-type
uint32 ace-flag uint32 ace-flag
uint32 ace-mask uint32 ace-mask
string who [UTF-8] string who [UTF-8]
ace-type is one of the following four values (taken from NFS Version ace-type is one of the following four values (taken from NFS Version
4 Protocol [3]: 4 Protocol [1]:
const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000; #define ACE4_ACCESS_ALLOWED_ACE_TYPE 0x00000000;
const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001; #define ACE4_ACCESS_DENIED_ACE_TYPE 0x00000001;
const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002; #define ACE4_SYSTEM_AUDIT_ACE_TYPE 0x00000002;
const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003; #define ACE4_SYSTEM_ALARM_ACE_TYPE 0x00000003;
ace-flag is a combination of the following flag values. See NFS ace-flag is a combination of the following flag values. See NFS
Version 4 Protocol [3] section 5.9.2: Version 4 Protocol [1] section 5.9.2:
const ACE4_FILE_INHERIT_ACE = 0x00000001;
const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002;
const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004;
const ACE4_INHERIT_ONLY_ACE = 0x00000008;
const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010;
const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020;
const ACE4_IDENTIFIER_GROUP = 0x00000040;
#define ACE4_FILE_INHERIT_ACE 0x00000001;
#define ACE4_DIRECTORY_INHERIT_ACE 0x00000002;
#define ACE4_NO_PROPAGATE_INHERIT_ACE 0x00000004;
#define ACE4_INHERIT_ONLY_ACE 0x00000008;
#define ACE4_SUCCESSFUL_ACCESS_ACE_FLAG 0x00000010;
#define ACE4_FAILED_ACCESS_ACE_FLAG 0x00000020;
#define ACE4_IDENTIFIER_GROUP 0x00000040;
ace-mask is any combination of the following flags (taken from NFS ace-mask is any combination of the following flags (taken from NFS
Version 4 Protocol [3] section 5.9.3: Version 4 Protocol [1] section 5.9.3:
const ACE4_READ_DATA = 0x00000001; #define ACE4_READ_DATA 0x00000001;
const ACE4_LIST_DIRECTORY = 0x00000001; #define ACE4_LIST_DIRECTORY 0x00000001;
const ACE4_WRITE_DATA = 0x00000002; #define ACE4_WRITE_DATA 0x00000002;
const ACE4_ADD_FILE = 0x00000002; #define ACE4_ADD_FILE 0x00000002;
const ACE4_APPEND_DATA = 0x00000004; #define ACE4_APPEND_DATA 0x00000004;
const ACE4_ADD_SUBDIRECTORY = 0x00000004; #define ACE4_ADD_SUBDIRECTORY 0x00000004;
const ACE4_READ_NAMED_ATTRS = 0x00000008; #define ACE4_READ_NAMED_ATTRS 0x00000008;
const ACE4_WRITE_NAMED_ATTRS = 0x00000010; #define ACE4_WRITE_NAMED_ATTRS 0x00000010;
const ACE4_EXECUTE = 0x00000020; #define ACE4_EXECUTE 0x00000020;
const ACE4_DELETE_CHILD = 0x00000040; #define ACE4_DELETE_CHILD 0x00000040;
const ACE4_READ_ATTRIBUTES = 0x00000080; #define ACE4_READ_ATTRIBUTES 0x00000080;
const ACE4_WRITE_ATTRIBUTES = 0x00000100; #define ACE4_WRITE_ATTRIBUTES 0x00000100;
const ACE4_DELETE = 0x00010000; #define ACE4_DELETE 0x00010000;
const ACE4_READ_ACL = 0x00020000; #define ACE4_READ_ACL 0x00020000;
const ACE4_WRITE_ACL = 0x00040000; #define ACE4_WRITE_ACL 0x00040000;
const ACE4_WRITE_OWNER = 0x00080000; #define ACE4_WRITE_OWNER 0x00080000;
const ACE4_SYNCHRONIZE = 0x00100000; #define ACE4_SYNCHRONIZE 0x00100000;
who is a UTF-8 string of the form described in 'Owner and Group' who is a UTF-8 string of the form described in 'Owner and Group'
(Section 5.4) (Section 5.4)
Also, as per '5.9.4 ACE who' [3] there are several identifiers that Also, as per '5.9.4 ACE who' [1] there are several identifiers that
need to be understood universally. Some of these identifiers cannot need to be understood universally. Some of these identifiers cannot
be understood when an client access the server, but have meaning when be understood when an client access the server, but have meaning when
a local process accesses the file. The ability to display and modify a local process accesses the file. The ability to display and modify
these permissions is permitted over SFTP. these permissions is permitted over SFTP.
OWNER The owner of the file. OWNER The owner of the file.
GROUP The group associated with the file. GROUP The group associated with the file.
EVERYONE The world. EVERYONE The world.
skipping to change at page 14, line 24 skipping to change at page 17, line 8
BATCH Accessed from a batch job. BATCH Accessed from a batch job.
ANONYMOUS Accessed without any authentication. ANONYMOUS Accessed without any authentication.
AUTHENTICATED Any authenticated user (opposite of ANONYMOUS). AUTHENTICATED Any authenticated user (opposite of ANONYMOUS).
SERVICE Access from a system service. SERVICE Access from a system service.
To avoid conflict, these special identifiers are distinguish by an To avoid conflict, these special identifiers are distinguish by an
appended "@" and should appear in the form "xxxx@" (note: no domain appended "@". For example: ANONYMOUS@.
name after the "@"). For example: ANONYMOUS@.
5.8 Extended attributes 5.8 attrib-bits
These bits reflect various attributes of the file or directory on the
server.
The following attrib-bits are defined:
#define SSH_FILEXFER_ATTR_FLAGS_READONLY 0x00000001
#define SSH_FILEXFER_ATTR_FLAGS_SYSTEM 0x00000002
#define SSH_FILEXFER_ATTR_FLAGS_HIDDEN 0x00000004
#define SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE 0x00000008
#define SSH_FILEXFER_ATTR_FLAGS_ARCHIVE 0x00000010
#define SSH_FILEXFER_ATTR_FLAGS_ENCRYPTED 0x00000020
#define SSH_FILEXFER_ATTR_FLAGS_COMPRESSED 0x00000040
#define SSH_FILEXFER_ATTR_FLAGS_SPARSE 0x00000080
#define SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY 0x00000100
#define SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE 0x00000200
#define SSH_FILEXFER_ATTR_FLAGS_SYNC 0x00000400
SSH_FILEXFER_ATTR_FLAGS_READONLY
Advisory, read-only bit. This bit is not part of the access
control information on the file, but is rather an advisory field
indicating that the file should not be written.
SSH_FILEXFER_ATTR_FLAGS_SYSTEM
The file is part of operating system.
SSH_FILEXFER_ATTR_FLAGS_HIDDEN
File SHOULD NOT be shown to user unless specifically requested.
For example, most UNIX systems SHOULD set this bit if the filename
begins with a 'period'. This bit may be read-only (Section 4.4).
Most UNIX systems will not allow this to be changed.
SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE
This attribute can only apply to directories. This attribute is
always read-only, and cannot be modified. This attribute means
that files and directory names in this directory should be
compared without regard to case.
It is recommended that where possible, the server's filesystem be
allowed to do comparisons. For example, if a client wished to
prompt a user before overwriting a file, it should not compare the
new name with the previously retrieved list of names in the
directory. Rather, it should first try to create the new file by
specifying SSH_FXF_CREATE_NEW flag. Then, if this fails and
returns SSH_FX_FILE_ALREADY_EXISTS, it should prompt the user and
then retry the create specifying SSH_FXF_CREATE_TRUNCATE.
Unless otherwise specified, filenames are assumed to be case
sensitive.
SSH_FILEXFER_ATTR_FLAGS_ARCHIVE
The file should be included in backup / archive operations.
SSH_FILEXFER_ATTR_FLAGS_ENCRYPTED
The file is encrypted.
SSH_FILEXFER_ATTR_FLAGS_COMPRESSED
The file is compressed.
SSH_FILEXFER_ATTR_FLAGS_SPARSE
The file is a sparse file; this means that file blocks that have
not been explicitly written are not stored on disk. For example,
if a client writes a buffer at 10 M from the beginning of the
file, the blocks between the previous EOF marker and the 10 M
offset would not consume physical disk space.
Some server may store all files as sparse files, in which case
this bit will be unconditionally set. Other servers may not have
a mechanism for determining if the file is sparse, and so the file
MAY be stored sparse even if this flag is not set.
SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY
The file can only be opened for writing in append mode.
SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE
The file cannot be deleted or renamed, no hard link can be created
to this file and no data can be written to the file.
This bit implies a stronger level of protection than
SSH_FILEXFER_ATTR_FLAGS_READONLY, the file permission mask or
ACLs. Typically even the superuser cannot write to immutable
files, and only the superuser can set or remove the bit.
SSH_FILEXFER_ATTR_FLAGS_SYNC
When the file is modified, the changes are written synchronously
to the disk.
5.9 Extended Attributes
The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension
mechanism for vendor-specific extensions. If the flag is specified, mechanism for the attrib structure. If the flag is specified, then
then the `extended_count' field is present. It specifies the number the 'extended_count' field is present. It specifies the number of
of extended_type-extended_data pairs that follow. Each of these extended_type-extended_data pairs that follow. Each of these pairs
pairs specifies an extended attribute. For each of the attributes, specifies an extended attribute. For each of the attributes, the
the extended_type field should be a string of the format extended_type field should be a string of the format "name@domain",
"name@domain", where "domain" is a valid, registered domain name and where "domain" is a valid, registered domain name and "name"
"name" identifies the method. The IETF may later standardize certain identifies the method. The IETF may later standardize certain names
names that deviate from this format (e.g., that do not contain the that deviate from this format (e.g., that do not contain the "@"
"@" sign). The interpretation of `extended_data' depends on the sign). The interpretation of 'extended_data' depends on the type.
type. Implementations SHOULD ignore extended data fields that they Implementations SHOULD ignore extended data fields that they do not
do not understand. understand.
Additional fields can be added to the attributes by either defining Additional fields can be added to the attributes by either defining
additional bits to the flags field to indicate their presence, or by additional bits to the flags field to indicate their presence, or by
defining extended attributes for them. The extended attributes defining extended attributes for them. The extended attributes
mechanism is recommended for most purposes; additional flags bits mechanism is recommended for most purposes; additional flags bits
should only be defined by an IETF standards action that also should only be defined by an IETF standards action that also
increments the protocol version number. The use of such new fields increments the protocol version number. The use of such new fields
MUST be negotiated by the version number in the protocol exchange. MUST be negotiated by the version number in the protocol exchange.
It is a protocol error if a packet with unsupported protocol bits is It is a protocol error if a packet with unsupported protocol bits is
received. received.
6. Requests From the Client to the Server 6. Requests From the Client to the Server
Requests from the client to the server represent the various file Requests from the client to the server represent the various file
system operations. Each request begins with an `id' field, which is system operations. Each request begins with an 'request-id' field,
a 32-bit identifier identifying the request (selected by the client). which is a 32-bit identifier identifying the request (selected by the
The same identifier will be returned in the response to the request. client). The same identifier will be returned in the response to the
One possible implementation is a monotonically increasing request request. One possible implementation is a monotonically increasing
sequence number (modulo 2^32). 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 (which is an opaque
variable-length string) which may be used to access the file later
(e.g. in a read operation). The client MUST NOT send requests the
server with bogus or closed handles. However, the server MUST
perform adequate checks on the handle in order to avoid security
risks due to fabricated handles.
This design allows either stateful and stateless server
implementation, as well as an implementation which caches state
between requests but may also flush it. The contents of the file
handle string are entirely up to the server and its design. The
client should not modify or attempt to interpret the file handle
strings.
The file handle strings MUST NOT be longer than 256 bytes.
6.1 Request Synchronization and Reordering 6.1 Request Synchronization and Reordering
The protocol and implementations MUST process requests relating to The protocol and implementations MUST process requests relating to
the same file in the order in which they are received. In other the same file in the order in which they are received. In other
words, if an application submits multiple requests to the server, the words, if an application submits multiple requests to the server, the
results in the responses will be the same as if it had sent the results in the responses will be the same as if it had sent the
requests one at a time and waited for the response in each case. For requests one at a time and waited for the response in each case. For
example, the server may process non-overlapping read/write requests example, the server may process non-overlapping read/write requests
to the same file in parallel, but overlapping reads and writes cannot to the same file in parallel, but overlapping reads and writes cannot
skipping to change at page 16, line 33 skipping to change at page 21, line 14
An empty path name is valid, and it refers to the user's default An empty path name is valid, and it refers to the user's default
directory (usually the user's home directory). directory (usually the user's home directory).
Otherwise, no syntax is defined for file names by this specification. Otherwise, no syntax is defined for file names by this specification.
Clients should not make any other assumptions; however, they can Clients should not make any other assumptions; however, they can
splice path name components returned by SSH_FXP_READDIR together splice path name components returned by SSH_FXP_READDIR together
using a slash ('/') as the separator, and that will work as expected. using a slash ('/') as the separator, and that will work as expected.
In order to comply with IETF Policy on Character Sets and Languages In order to comply with IETF Policy on Character Sets and Languages
[2], all filenames are to be encoded in UTF-8. The shortest valid [7], all filenames MUST be encoded in UTF-8. The shortest valid UTF-8
UTF-8 encoding of the UNICODE data MUST be used. The server is encoding of the UNICODE data MUST be used. The server is responsible
responsible for converting the UNICODE data to whatever canonical for converting the UNICODE data to whatever canonical form it
form it requires. requires.
For example, if the server requires that precomposed characters For example, if the server requires that precomposed characters
always be used, the server MUST NOT assume the filename as sent by always be used, the server MUST NOT assume the filename as sent by
the client has this attribute, but must do this normalization itself. the client has this attribute, but must do this normalization itself.
It is understood that the lack of well-defined semantics for file It is understood that the lack of well-defined semantics for file
names may cause interoperability problems between clients and servers names may cause interoperability problems between clients and servers
using radically different operating systems. However, this approach using radically different operating systems. However, this approach
is known to work acceptably with most systems, and alternative is known to work acceptably with most systems, and alternative
approaches that e.g. treat file names as sequences of structured approaches that e.g. treat file names as sequences of structured
components are quite complicated. components are quite complicated.
6.3 Opening, Creating, and Closing Files 6.3 Opening and Closing Files and Directories
Files are opened and created using the SSH_FXP_OPEN message, whose Many operations in the protocol operate on open files. The
data part is as follows: SSH_FXP_OPEN and SSH_FXP_OPENDIR requests return a handle (which is
an opaque, variable-length string) which may be used to access the
file or directory later. The client MUST NOT send requests the
server with bogus or closed handles. However, the server MUST
perform adequate checks on the handle in order to avoid security
risks due to fabricated handles.
uint32 id This design allows either stateful and stateless server
implementation, as well as an implementation which caches state
between requests but may also flush it. The contents of the file
handle string are entirely up to the server and its design. The
client should not modify or attempt to interpret the file handle
strings.
The file handle strings MUST NOT be longer than 256 bytes.
6.3.1 Opening a File
Files are opened and created using the SSH_FXP_OPEN message:
byte SSH_FXP_OPEN
uint32 request-id
string filename [UTF-8] string filename [UTF-8]
uint32 pflags uint32 desired-access
uint32 flags
ATTRS attrs ATTRS attrs
The `id' field is the request identifier as for all requests. The response to this message will be either SSH_FXP_HANDLE (if the
operation is successful) or SSH_FXP_STATUS (if the operation fails).
The `filename' field specifies the file name. See Section ``File The 'request-id' field is the request identifier as for all requests.
The 'filename' field specifies the file name. See Section ''File
Names'' for more information. Names'' for more information.
The `pflags' field is a bitmask. The following bits have been The 'desired-access' field is a bitmask containing a combination of
defined. values from the ace-mask flags from section 5.7.
#define SSH_FXF_READ 0x00000001 The 'flags' field controls various aspects of the operation,
#define SSH_FXF_WRITE 0x00000002 including whether or not the file is created and the kind of locking
#define SSH_FXF_APPEND 0x00000004 desired.
#define SSH_FXF_CREAT 0x00000008
#define SSH_FXF_TRUNC 0x00000010
#define SSH_FXF_EXCL 0x00000020
#define SSH_FXF_TEXT 0x00000040
These have the following meanings: The following 'flags' are defined:
SSH_FXF_READ SSH_FXF_ACCESS_DISPOSITION = 0x00000007
Open the file for reading. SSH_FXF_CREATE_NEW = 0x00000000
SSH_FXF_CREATE_TRUNCATE = 0x00000001
SSH_FXF_OPEN_EXISTING = 0x00000002
SSH_FXF_OPEN_OR_CREATE = 0x00000003
SSH_FXF_TRUNCATE_EXISTING = 0x00000004
SSH_FXF_ACCESS_APPEND_DATA = 0x00000008
SSH_FXF_ACCESS_APPEND_DATA_ATOMIC = 0x00000010
SSH_FXF_ACCESS_TEXT_MODE = 0x00000020
SSH_FXF_ACCESS_READ_LOCK = 0x00000040
SSH_FXF_ACCESS_WRITE_LOCK = 0x00000080
SSH_FXF_ACCESS_DELETE_LOCK = 0x00000100
SSH_FXF_WRITE SSH_FXF_ACCESS_DISPOSITION
Open the file for writing. If both this and SSH_FXF_READ are Disposition is a 3 bit field that controls how the file is opened.
specified, the file is opened for both reading and writing. The server MUST support these bits. Any one of the following
enumeration is allowed:
SSH_FXF_APPEND SSH_FXF_CREATE_NEW
Force all writes to append data at the end of the file. The A new file is created; if the file already exists, the server
offset parameter to write will be ignored. MUST return status SSH_FX_FILE_ALREADY_EXISTS.
SSH_FXF_CREAT SSH_FXF_CREATE_TRUNCATE
If this flag is specified, then a new file will be created if one A new file is create; if the file already exists, it is
does not already exist (if O_TRUNC is specified, the new file will truncated.
be truncated to zero length if it previously exists).
SSH_FXF_TRUNC SSH_FXF_OPEN_EXISTING
Forces an existing file with the same name to be truncated to zero An existing file is opened. If the file does not exist, the
length when creating a file by specifying SSH_FXF_CREAT. server MUST return SSH_FX_NO_SUCH_FILE. If a directory in the
SSH_FXF_CREAT MUST also be specified if this flag is used. path does not exist, the server SHOULD return
SSH_FX_NO_SUCH_PATH. It is also acceptable if the server
returns SSH_FX_NO_SUCH_FILE in this case.
SSH_FXF_EXCL SSH_FXF_OPEN_OR_CREATE
Causes the request to fail if the named file already exists. If the file exists, it is opened. If the file does not exist,
SSH_FXF_CREAT MUST also be specified if this flag is used. it is created.
SSH_FXF_TRUNCATE_EXISTING
An existing file is opened and truncated. If the file does not
exist, the server MUST return the same error codes as defined
for SSH_FXF_OPEN_EXISTING.
SSH_FXF_ACCESS_APPEND_DATA
Data is always written at the end of the file. The offset field
of the SSH_FXP_WRITE requests are ignored.
Data is not required to be appended atomically. This means that
if multiple writers attempt to append data simultaneously, data
from the first may be lost. However, data MAY be appended
atomically.
SSH_FXF_ACCESS_APPEND_DATA_ATOMIC
Data is always written at the end of the file. The offset field
of the SSH_FXP_WRITE requests are ignored.
Date MUST be written atomically so that there is no chance that
multiple appenders can collide and result in data being lost.
If both append flags are specified, the server SHOULD use atomic
append if it is available, but SHOULD use non-atomic appends
otherwise. The server SHOULD NOT fail the request in this case.
SSH_FXF_TEXT SSH_FXF_TEXT
Indicates that the server should treat the file as text and Indicates that the server should treat the file as text and
convert it to the canonical newline convention in use. (See convert it to the canonical newline convention in use. (See
Determining Server Newline Convention. (Section 4.3) Determining Server Newline Convention. (Section 4.3)
When a file is opened with the FXF_TEXT flag, the offset field in When a file is opened with the FXF_TEXT flag, the offset field in
both the read and write function are ignored. both the read and write function are ignored.
Servers MUST correctly process multiple parallel reads and writes Servers MUST correctly process multiple, parallel reads and writes
correctly in this mode. Naturally, it is permissible for them to correctly in this mode. Naturally, it is permissible for them to
do this by serializing the requests. It would not be possible for do this by serializing the requests.
a client to reliably detect a server that does not implement
parallel writes in time to prevent damage.
Clients SHOULD use the SSH_FXF_APPEND flag to append data to a Clients SHOULD use the SSH_FXF_ACCESS_APPEND_DATA flag to append
text file rather then using write with a calculated offset. data to a text file rather then using write with a calculated
offset.
To support seeks on text file the following SSH_FXP_EXTENDED To support seeks on text files the following SSH_FXP_EXTENDED
packet is defined. packet is defined.
string "text-seek" string "text-seek"
string file-handle string file-handle
uint64 line-number uint64 line-number
line-number is the index of the line number to seek to, where byte line-number is the index of the line number to seek to, where byte
0 in the file is line number 0, and the byte directly following 0 in the file is line number 0, and the byte directly following
the first newline sequence in the file is line number 1 and so on. the first newline sequence in the file is line number 1 and so on.
skipping to change at page 18, line 47 skipping to change at page 24, line 38
SSH_FX_EOF status. SSH_FX_EOF status.
Servers SHOULD support at least one "text-seek" in order to Servers SHOULD support at least one "text-seek" in order to
support resume. However, a client MUST be prepared to receive support resume. However, a client MUST be prepared to receive
SSH_FX_OP_UNSUPPORTED when attempting a "text-seek" operation. SSH_FX_OP_UNSUPPORTED when attempting a "text-seek" operation.
The client can then try a fall-back strategy, if it has one. The client can then try a fall-back strategy, if it has one.
Clients MUST be prepared to handle SSH_FX_OP_UNSUPPORTED returned Clients MUST be prepared to handle SSH_FX_OP_UNSUPPORTED returned
for read or write operations that are not sequential. for read or write operations that are not sequential.
The `attrs' field specifies the initial attributes for the file. SSH_FXF_ACCESS_READ_LOCK
Default values will be used for those attributes that are not The file should be opened with a read lock. The server MUST
specified. See Section ``File Attributes'' for more information. gaurantee that the client will be the exclusive reader of the file
until the client closes the handle. If there is a conflicting lock
the server MUST return SSH_FX_LOCK_CONFlICT. If the server cannot
make the locking gaurantee, it MUST return SSH_FX_OP_UNSUPPORTED.
SSH_FXF_ACCESS_WRITE_LOCK
The file should be opened with a write lock. The server MUST
gaurantee that the client will be the exclusive writer of the file
until the client closes the handle.
SSH_FXF_ACCESS_DELETE_LOCK
The file should be opened with a delete lock. The server MUST
gaurantee that the file will not be deleted until the client
closes the handle.
The 'attrs' field specifies the initial attributes for the file.
Default values MUST be supplied by the server for those attributes
that are not specified. See Section ''File Attributes'' for more
information.
The following table is provided to assist in mapping posix semantics
to equivalent SFTP file open parameters:
O_RDONLY
desired-access = READ_DATA|READ_ATTRIBUTES
O_WRONLY
desired-access = WRITE_DATA|WRITE_ATTRIBUTES
O_RDWR
desired-access =
READ_DATA|READ_ATTRIBUTES|WRITE_DATA|WRITE_ATTRIBUTES
O_APPEND
desired-access = WRITE_DATA|WRITE_ATTRIBUTES|APPEND_DATA
flags = SSH_FXF_ACCESS_APPEND_DATA and or
SSH_FXF_ACCESS_APPEND_DATA_ATOMIC
O_CREAT
flags = SSH_FXF_OPEN_OR_CREATE
O_TRUNC
flags = SSH_FXF_TRUNCATE_EXISTING
O_TRUNC|O_CREATE
flags = SSH_FXF_CREATE_TRUNCATE
6.3.2 Opening a Directory
To enumerate a directory, the client first obtains a handle and then
issues directory read requests. When enumeration is complete, the
handle MUST be closed.
byte SSH_FXP_OPENDIR
uint32 request-id
string path [UTF-8]
'request-id' is the request identifier.
'path' is the path name of the directory to be listed (without any
trailing slash). See Section 'File Names' for more information on
file names.
The response to this message will be either SSH_FXP_HANDLE (if the The response to this message will be either SSH_FXP_HANDLE (if the
operation is successful) or SSH_FXP_STATUS (if the operation fails). operation is successful) or SSH_FXP_STATUS (if the operation fails).
A file is closed by using the SSH_FXP_CLOSE request. Its data field 6.3.3 Closing Handles
has the following format:
uint32 id A handle is closed using the following request.
byte SSH_FXP_CLOSE
uint32 request-id
string handle string handle
where `id' is the request identifier, and `handle' is a handle 'request-id' is the request identifier, and 'handle' is a handle
previously returned in the response to SSH_FXP_OPEN or previously returned in the response to SSH_FXP_OPEN or
SSH_FXP_OPENDIR. The handle becomes invalid immediately after this SSH_FXP_OPENDIR. The handle becomes invalid immediately after this
request has been sent. request has been sent.
The response to this request will be a SSH_FXP_STATUS message. One The response to this request will be a SSH_FXP_STATUS message. Note
should note that on some server platforms even a close can fail. that on some server platforms even a close can fail. For example, if
This can happen e.g. if the server operating system caches writes, the server operating system caches writes, and an error occurs while
and an error occurs while flushing cached writes during the close. flushing cached writes, the close operation may fail.
6.4 Reading and Writing 6.4 Reading and Writing
Once a file has been opened, it can be read using the following 6.4.1 Reading Files
message:
The following request can be used to read file data:
byte SSH_FXP_READ byte SSH_FXP_READ
uint32 id uint32 request-id
string handle string handle
uint64 offset uint64 offset
uint32 len uint32 length
where `id' is the request identifier, `handle' is an open file handle where 'request-id' is the request identifier, 'handle' is an open
returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative file handle returned by SSH_FXP_OPEN, 'offset' is the offset (in
to the beginning of the file from where to start reading, and `len' bytes) relative to the beginning of the file from where to start
is the maximum number of bytes to read. reading, and 'length' is the maximum number of bytes to read.
In response to this request, the server will read as many bytes as it In response to this request, the server will read as many bytes as it
can from the file (up to `len'), and return them in a SSH_FXP_DATA can from the file (up to 'length'), and return them in a SSH_FXP_DATA
message. If an error occurs or EOF is encountered before reading any message. If an error occurs or EOF is encountered before reading any
data, the server will respond with SSH_FXP_STATUS. data, the server will respond with SSH_FXP_STATUS.
For normal disk files, it is normally guaranteed that this will read For normal disk files, it is normally guaranteed that this will read
the specified number of bytes, or up to end of file. However, if the the specified number of bytes, or up to end of file. However, if the
read length is very long, the server may truncate it if it doesn't read length is very long, the server may truncate it if it doesn't
support packets of that length. See General Packet Format (Section support packets of that length. See General Packet Format (Section
3). 3).
For e.g. device files this may return fewer bytes than requested. 6.4.2 Reading Directories
In order to retrieve a directory listing, the client issues one or
more SSH_FXP_READDIR requests. In order to obtain a complete
directory listing, the client MUST issue repeated SSH_FXP_READDIR
requests until the server responds with an SSH_FXP_STATUS message.
byte SSH_FXP_READDIR
uint32 request-id
string handle
where 'request-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 SSH_FXP_OPEN.)
The server responds to this 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 returned for each name in order to speed
up typical directory listings.
If there are no more names available to be read, the server MUST
respond with a SSH_FXP_STATUS message with error code of SSH_FX_EOF.
6.4.3 Writing Files
Writing to a file is achieved using the following message: Writing to a file is achieved using the following message:
byte SSH_FXP_WRITE byte SSH_FXP_WRITE
uint32 id uint32 request-id
string handle string handle
uint64 offset uint64 offset
string data string data
where `id' is a request identifier, `handle' is a file handle where 'request-id' is a request identifier, 'handle' is a file handle
returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the returned by SSH_FXP_OPEN, 'offset' is the offset (in bytes) from the
beginning of the file where to start writing, and `data' is the data beginning of the file where to start writing, and 'data' is the data
to be written. to be written.
The write will extend the file if writing beyond the end of the file. The write will extend the file if writing beyond the end of the file.
It is legal to write way beyond the end of the file; the semantics It is legal to write to an offset that extends beyond the end of the
are to write zeroes from the end of the file to the specified offset file; the semantics are to write zeroes from the end of the file to
and then the data. On most operating systems, such writes do not the specified offset and then the data. On most operating systems,
allocate disk space but instead leave "holes" in the file. such writes do not allocate disk space but instead create a sparse
file.
The server responds to a write request with a SSH_FXP_STATUS message. The server responds to a write request with a SSH_FXP_STATUS message.
6.5 Removing and Renaming Files 6.5 Removing and Renaming Files
Files can be removed using the SSH_FXP_REMOVE message. It has the The following request can be used to remove a file:
following format:
uint32 id byte SSH_FXP_REMOVE
uint32 request-id
string filename [UTF-8] string filename [UTF-8]
where `id' is the request identifier and `filename' is the name of where 'request-id' is the request identifier and 'filename' is the
the file to be removed. See Section ``File Names'' for more name of the file to be removed. See Section ''File Names'' for more
information. This request cannot be used to remove directories. information. This request cannot be used to remove directories.
The server will respond to this request with a SSH_FXP_STATUS The server will respond to this request with a SSH_FXP_STATUS
message. message.
Files (and directories) can be renamed using the SSH_FXP_RENAME Files (and directories) can be renamed using the SSH_FXP_RENAME
message. Its data is as follows: message.
uint32 id byte SSH_FXP_RENAME
uint32 request-id
string oldpath [UTF-8] string oldpath [UTF-8]
string newpath [UTF-8] string newpath [UTF-8]
uint32 flags
where `id' is the request identifier, `oldpath' is the name of an where 'request-id' is the request identifier, 'oldpath' is the name
existing file or directory, and `newpath' is the new name for the of an existing file or directory, and 'newpath' is the new name for
file or directory. It is an error if there already exists a file the file or directory.
with the name specified by newpath. The server may also fail rename
requests in other situations, for example if `oldpath' and `newpath' 'flags' is 0 or a combination of:
point to different file systems on the server.
SSH_FXP_RENAME_OVERWRITE 0x00000001
SSH_FXP_RENAME_ATOMIC 0x00000002
SSH_FXP_RENAME_NATIVE 0x00000004
If flags does not include SSH_FXP_RENAME_OVERWRITE, and there already
exists a file with the name specified by newpath, the server MUST
respond with SSH_FX_FILE_ALREADY_EXISTS.
If flags includes SSH_FXP_RENAME_ATOMIC, and the destination file
already exists, it is replaced in an atomic fashion. I.e., there is
no observable instant in time where the name does not refer to either
the old or the new file. SSH_FXP_RENAME_ATOMIC implies
SSH_FXP_RENAME_OVERWRITE.
If flags includes SSH_FXP_RENAME_ATOMIC and the server cannot replace
the destination in an atomic fashion, then the server MUST respond
with SSH_FX_OP_UNSUPPORTED.
Because some servers cannot provide atomic rename, clients should
only specify atomic rename if correct operation requires it. If
SSH_FXP_RENAME_OVERWRITE is specified, the server MAY perform an
atomic rename even if it is not requested.
If flags includes SSH_FXP_RENAME_NATIVE, the server is free to do the
rename operation in whatever fashion it deems appropriate. Other
flag values are considered hints as to desired behavior, but not
requirements.
The server will respond to this request with a SSH_FXP_STATUS The server will respond to this request with a SSH_FXP_STATUS
message. message.
6.6 Creating and Deleting Directories 6.6 Creating and Deleting Directories
New directories can be created using the SSH_FXP_MKDIR request. It New directories can be created using the SSH_FXP_MKDIR request. It
has the following format: has the following format:
uint32 id byte SSH_FXP_MKDIR
uint32 request-id
string path [UTF-8] string path [UTF-8]
ATTRS attrs ATTRS attrs
where `id' is the request identifier. where 'request-id' is the request identifier.
`path' specifies the directory to be created. See Section ``File 'path' specifies the directory to be created. See Section ''File
Names'' for more information on file names. Names'' for more information on file names.
`attrs' specifies the attributes that should be applied to it upon 'attrs' specifies the attributes that should be applied to it upon
creation. Attributes are discussed in more detail in Section ``File creation. Attributes are discussed in more detail in Section ''File
Attributes''. Attributes''.
The server will respond to this request with a SSH_FXP_STATUS The server will respond to this request with a SSH_FXP_STATUS
message. If a file or directory with the specified path already message. If a file or directory with the specified path already
exists, an error will be returned. exists, an error will be returned.
Directories can be removed using the SSH_FXP_RMDIR request, which has Directories can be removed using the SSH_FXP_RMDIR request, which has
the following format: the following format:
uint32 id byte SSH_FXP_RMDIR
uint32 request-id
string path [UTF-8] string path [UTF-8]
where `id' is the request identifier, and `path' specifies the where 'request-id' is the request identifier, and 'path' specifies
directory to be removed. See Section ``File Names'' for more the directory to be removed. See Section ''File Names'' for more
information on file names. information on file names.
The server responds to this request with a SSH_FXP_STATUS message. The server responds to this request with a SSH_FXP_STATUS message.
Errors may be returned from this operation for various reasons,
including, but not limited to, the path does not exist, the path does
not refer to a directory object, the directory is not empty, or the
user has insufficient access or permission to perform the requested
operation.
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 each file. The
client should call SSH_FXP_READDIR repeatedly until it has found the
file it is looking for or until the server responds with a
SSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF if
there are no more files in the directory). The client should then
close the handle using the SSH_FXP_CLOSE request.
The SSH_FXP_OPENDIR opens a directory for reading. It has the 6.7 Retrieving File Attributes
following format:
uint32 id
string path [UTF-8]
where `id' is the request identifier and `path' is the path name 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. The server will respond to this request with either
a SSH_FXP_HANDLE or a SSH_FXP_STATUS message.
Once the directory has been successfully opened, files (and
directories) contained in it can be 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 SSH_FXP_OPEN.)
The server responds to this 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 returned for each name in order to speed
up typical directory listings.
If there are no more names available to be read, the server MUST
respond with a SSH_FXP_STATUS message with error code of SSH_FX_EOF.
When the client no longer wishes to read more names from the
directory, it SHOULD call SSH_FXP_CLOSE for the handle. The handle
should be closed regardless of whether an error has occurred or not.
6.8 Retrieving File Attributes
Very often, file attributes are automatically returned by Very often, file attributes are automatically returned by
SSH_FXP_READDIR. However, sometimes there is need to specifically SSH_FXP_READDIR. However, sometimes there is need to specifically
retrieve the attributes for a named file. This can be done using the retrieve the attributes for a named file. This can be done using the
SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests. SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests.
SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT
follows symbolic links on the server, whereas SSH_FXP_LSTAT does not follows symbolic links on the server, whereas SSH_FXP_LSTAT does not
follow symbolic links. Both have the same format: follow symbolic links. Both have the same format:
uint32 id byte SSH_FXP_STAT or SSH_FXP_LSTAT
uint32 request-id
string path [UTF-8] string path [UTF-8]
uint32 flags uint32 flags
where `id' is the request identifier, and `path' specifies the file where 'request-id' is the request identifier, and 'path' specifies
system object for which status is to be returned. The server the file system object for which status is to be returned. The
responds to this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS. server responds to this request with either SSH_FXP_ATTRS or
SSH_FXP_STATUS.
The flags field specify the attribute flags in which the client has The flags field specify the attribute flags in which the client has
particular interest. This is a hint to the server. For example, particular interest. This is a hint to the server. For example,
because retrieving owner / group and acl information can be an because retrieving owner / group and acl information can be an
expensive operation under some operating systems, the server may expensive operation under some operating systems, the server may
choose not to retrieve this information unless the client expresses a choose not to retrieve this information unless the client expresses a
specific interest in it. specific interest in it.
The client has no guarantee the server will provide all the fields The client has no guarantee the server will provide all the fields
that it has expressed an interest in. that it has expressed an interest in.
SSH_FXP_FSTAT differs from the others in that it returns status SSH_FXP_FSTAT differs from the others in that it returns status
information for an open file (identified by the file handle). Its information for an open file (identified by the file handle).
format is as follows:
uint32 id byte SSH_FXP_FSTAT
uint32 request-id
string handle string handle
uint32 flags uint32 flags
where `id' is the request identifier and `handle' is a file handle where 'request-id' is the request identifier and 'handle' is a file
returned by SSH_FXP_OPEN. The server responds to this request with handle returned by SSH_FXP_OPEN. The server responds to this request
SSH_FXP_ATTRS or SSH_FXP_STATUS. with SSH_FXP_ATTRS or SSH_FXP_STATUS.
6.9 Setting File Attributes 6.8 Setting File Attributes
File attributes may be modified using the SSH_FXP_SETSTAT and File attributes may be modified using the SSH_FXP_SETSTAT and
SSH_FXP_FSETSTAT requests. These requests are used for operations SSH_FXP_FSETSTAT requests.
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 byte SSH_FXP_SETSTAT
uint32 request-id
string path [UTF-8] string path [UTF-8]
ATTRS attrs ATTRS attrs
where `id' is the request identifier, `path' specifies the file byte SSH_FXP_FSETSTAT
system object (e.g. file or directory) whose attributes are to be uint32 request-id
modified, and `attrs' specifies the modifications to be made to its string handle
attributes. Attributes are discussed in more detail in Section ATTRS attrs
``File Attributes''.
An error will be returned if the specified file system object does request-id
not exist or the user does not have sufficient rights to modify the The request identifier to be returned as part of the response.
specified attributes. The server responds to this request with a
SSH_FXP_STATUS message.
The SSH_FXP_FSETSTAT request modifies the attributes of a file which path
is already open. It has the following format: The file system object (e.g. file or directory) whose attributes
are to be modified. If this object does not exist, or the user
does not have sufficient access to write the attributes, the
request MUST fail.
uint32 id handle
string handle The handle is a handle previously returned from a SSH_FXP_OPEN
ATTRS attrs request which identifies the file whose attributes are to be
modified. If the handle was not opened with sufficient access to
write the requested attributes, the request MUST fail.
where `id' is the request identifier, `handle' (MUST be returned by attrs
SSH_FXP_OPEN) identifies the file whose attributes are to be Specifies the modified attributes to be applied. Attributes are
modified, and `attrs' specifies the modifications to be made to its discussed in more detail in Section ''File Attributes''.
attributes. Attributes are discussed in more detail in Section
``File Attributes''. The server will respond to this request with
SSH_FXP_STATUS.
6.10 Dealing with Symbolic links The server will respond with a SSH_FXP_STATUS message.
The SSH_FXP_READLINK request may be used to read the target of a Because some systems must use separate system calls to set various
symbolic link. It would have a data part as follows: attributes, it is possible that a failure response will be returned,
but yet some of the attributes may be have been successfully
modified. If possible, servers SHOULD avoid this situation; however,
client MUST be aware that this is possible.
uint32 id 6.9 Dealing with Symbolic Links
string path [UTF-8]
where `id' is the request identifier and `path' specifies the path The SSH_FXP_READLINK request reads the target of a symbolic link.
name of the symlink to be read.
byte SSH_FXP_READLINK
uint32 request-id
string path [UTF-8]
where 'request-id' is the request identifier and 'path' specifies the
path name of the symlink to be read.
The server will respond with a SSH_FXP_NAME packet containing only The server will respond with a SSH_FXP_NAME packet containing only
one name and a dummy attributes value. The name in the returned one name and a dummy attributes value. The name in the returned
packet contains the target of the link. If an error occurs, the packet contains the target of the link. If an error occurs, the
server may respond with SSH_FXP_STATUS. server MAY respond with SSH_FXP_STATUS.
The SSH_FXP_SYMLINK request will create a symbolic link on the The SSH_FXP_SYMLINK request creates a symbolic link on the server.
server. It is of the following format
uint32 id byte SSH_FXP_SYMLINK
uint32 request-id
string linkpath [UTF-8] string linkpath [UTF-8]
string targetpath [UTF-8] string targetpath [UTF-8]
where `id' is the request identifier, `linkpath' specifies the path where 'request-id' is the request identifier, 'linkpath' specifies
name of the symlink to be created and `targetpath' specifies the the path name of the symlink to be created and 'targetpath' specifies
target of the symlink. The server shall respond with a the target of the symlink. The server shall respond with a
SSH_FXP_STATUS indicating either success (SSH_FX_OK) or an error SSH_FXP_STATUS.
condition.
6.11 Canonicalizing the Server-Side Path Name 6.10 Canonicalizing the Server-Side Path Name
The SSH_FXP_REALPATH request can be used to have the server The SSH_FXP_REALPATH request can be used to have the server
canonicalize any given path name to an absolute path. This is useful canonicalize any given path name to an absolute path. This is useful
for converting path names containing ".." components or relative for converting path names containing ".." components or relative
pathnames without a leading slash into absolute paths. The format of pathnames without a leading slash into absolute paths. The format of
the request is as follows: the request is as follows:
uint32 id byte SSH_FXP_REALPATH
uint32 request-id
string path [UTF-8] string path [UTF-8]
where `id' is the request identifier and `path' specifies the path where 'request-id' is the request identifier and 'path' specifies the
name to be canonicalized. The server will respond with a path name to be canonicalized. The server will respond with a
SSH_FXP_NAME packet containing the name in canonical form and a dummy SSH_FXP_NAME packet containing the name in canonical form and a dummy
attributes value. If an error occurs, the server may also respond attributes value. If an error occurs, the server may also respond
with SSH_FXP_STATUS. with SSH_FXP_STATUS.
6.11.1 Best practice for dealing with paths The server SHOULD fail the request if the path is not present on the
server.
6.10.1 Best Practice for Dealing with Paths
The client SHOULD treat the results of SSH_FXP_REALPATH as a The client SHOULD treat the results of SSH_FXP_REALPATH as a
canonical absolute path, even if the path does not appear to be canonical absolute path, even if the path does not appear to be
absolute. A client that use REALPATH(".") and treats the result as absolute. A client that use REALPATH(".") and treats the result as
absolute, even if there is no leading slash, will continue to absolute, even if there is no leading slash, will continue to
function correctly, even when talking to a Windows NT or VMS style function correctly, even when talking to a Windows NT or VMS style
system, where absolute paths may not begin with a slash. system, where absolute paths may not begin with a slash.
For example, if the client wishes to change directory up, and the For example, if the client wishes to change directory up, and the
server has returned "c:/x/y/z" from REALPATH, the client SHOULD use server has returned "c:/x/y/z" from REALPATH, the client SHOULD use
skipping to change at page 26, line 9 skipping to change at page 34, line 9
As a second example, if the client wishes to open the file "x.txt" in As a second example, if the client wishes to open the file "x.txt" in
the current directory, and server has returned "dka100:/x/y/z" as the the current directory, and server has returned "dka100:/x/y/z" as the
canonical path of the directory, the client SHOULD open "dka100:/x/y/ canonical path of the directory, the client SHOULD open "dka100:/x/y/
z/x.txt" z/x.txt"
7. Responses from the Server to the Client 7. Responses from the Server to the Client
The server responds to the client using one of a few response The server responds to the client using one of a few response
packets. All requests can return a SSH_FXP_STATUS response upon packets. All requests can return a SSH_FXP_STATUS response upon
failure. When the operation is successful, any of the responses may failure. When the operation is successful, and no data needs to be
be returned (depending on the operation). If no data needs to be returned, the SSH_FXP_STATUS response with SSH_FX_OK status is
returned to the client, the SSH_FXP_STATUS response with SSH_FX_OK appropriate.
status is appropriate. Otherwise, the SSH_FXP_HANDLE message is used
to 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 is used to return one or more file names 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 request. Each Exactly one response will be returned for each request. Each
response packet contains a request identifier which can be used to response packet contains a request identifier which can be used to
match each response with the corresponding request. Note that it is match each response with the corresponding request. Note that it is
legal to have several requests outstanding simultaneously, and the legal to have several requests outstanding simultaneously, and the
server is allowed to send responses to them in a different order from server is allowed to send responses to them in a different order from
the order in which the requests were sent (the result of their the order in which the requests were sent (the result of their
execution, however, is guaranteed to be as if they had been processed execution, however, is guaranteed to be as if they had been processed
one at a time in the order in which the requests were sent). one at a time in the order in which the requests were sent).
Response packets are of the same general format as request packets. Response packets are of the same general format as request packets.
Each response packet begins with the request identifier. Each response packet begins with the request identifier.
The format of the data portion of the SSH_FXP_STATUS response is as The format of the data portion of the SSH_FXP_STATUS response is as
follows: follows:
uint32 id byte SSH_FXP_STATUS
uint32 request-id
uint32 error/status code uint32 error/status code
string error message (ISO-10646 UTF-8 [RFC-2279]) string error message (ISO-10646 UTF-8 [RFC-2279])
string language tag (as defined in [RFC-1766]) string language tag (as defined in [RFC-1766])
<error-specific data>
where `id' is the request identifier, and `error/status code' request-id
indicates the result of the requested operation. The value SSH_FX_OK The 'request-id' specified by the client in the request the server
is responding to.
error/status code
Machine readable status code indicating the result of the request.
Error code values are defined below. The value SSH_FX_OK
indicates success, and all other values indicate failure. indicates success, and all other values indicate failure.
Currently, the following values are defined (other values may be error message
defined by future versions of this protocol): Human readable description of the error. 'language tag' specifies
the language the error is in.
<error-specific data>
The error-specific data may be empty, or may contain additional
information about the error. For error codes that send
error-specific data, the format of the data is defined below.
Error codes:
#define SSH_FX_OK 0 #define SSH_FX_OK 0
#define SSH_FX_EOF 1 #define SSH_FX_EOF 1
#define SSH_FX_NO_SUCH_FILE 2 #define SSH_FX_NO_SUCH_FILE 2
#define SSH_FX_PERMISSION_DENIED 3 #define SSH_FX_PERMISSION_DENIED 3
#define SSH_FX_FAILURE 4 #define SSH_FX_FAILURE 4
#define SSH_FX_BAD_MESSAGE 5 #define SSH_FX_BAD_MESSAGE 5
#define SSH_FX_NO_CONNECTION 6 #define SSH_FX_NO_CONNECTION 6
#define SSH_FX_CONNECTION_LOST 7 #define SSH_FX_CONNECTION_LOST 7
#define SSH_FX_OP_UNSUPPORTED 8 #define SSH_FX_OP_UNSUPPORTED 8
#define SSH_FX_INVALID_HANDLE 9 #define SSH_FX_INVALID_HANDLE 9
#define SSH_FX_NO_SUCH_PATH 10 #define SSH_FX_NO_SUCH_PATH 10
#define SSH_FX_FILE_ALREADY_EXISTS 11 #define SSH_FX_FILE_ALREADY_EXISTS 11
#define SSH_FX_WRITE_PROTECT 12 #define SSH_FX_WRITE_PROTECT 12
#define SSH_FX_NO_MEDIA 13 #define SSH_FX_NO_MEDIA 13
#define SSH_FX_NO_SPACE_ON_FILESYSTEM 14
#define SSH_FX_QUOTA_EXCEEDED 15
#define SSH_FX_UNKNOWN_PRINCIPLE 16
#define SSH_FX_LOCK_CONFlICT 17
SSH_FX_OK SSH_FX_OK
Indicates successful completion of the operation. Indicates successful completion of the operation.
SSH_FX_EOF SSH_FX_EOF
indicates end-of-file condition; for SSH_FX_READ it means that no An attempt to read past the end-of-file was made; or, there are no
more data is available in the file, and for SSH_FX_READDIR it more directory entries to return.
indicates that no more files are contained in the directory.
SSH_FX_NO_SUCH_FILE SSH_FX_NO_SUCH_FILE
is returned when a reference is made to a file which does not A reference was made to a file which does not exist.
exist.
SSH_FX_PERMISSION_DENIED SSH_FX_PERMISSION_DENIED
is returned when the authenticated user does not have sufficient The user does not have sufficient permissions to perform the
permissions to perform the operation. operation.
SSH_FX_FAILURE SSH_FX_FAILURE
is a generic catch-all error message; it should be returned if an An error occured, but no specific error code exists to describe
error occurs for which there is no more specific error code the failure.
defined.
This error message SHOULD always have meaningful text in the the
'error message' field.
SSH_FX_BAD_MESSAGE SSH_FX_BAD_MESSAGE
may be returned if a badly formatted packet or protocol A badly formatted packet or other SFTP protocol incompatibility
incompatibility is detected. was detected.
SSH_FX_NO_CONNECTION SSH_FX_NO_CONNECTION
is a pseudo-error which indicates that the client has no There is no connection to the server. This error can only be
connection to the server (it can only be generated locally by the generated locally, and MUST NOT be return by a server.
client, and MUST NOT be returned by servers).
SSH_FX_CONNECTION_LOST SSH_FX_CONNECTION_LOST
is a pseudo-error which indicates that the connection to the The connection to the server was lost. This error can only be
server has been lost (it can only be generated locally by the generated locally, and MUST NOT be return by a server.
client, and MUST NOT be returned by servers).
SSH_FX_OP_UNSUPPORTED SSH_FX_OP_UNSUPPORTED
indicates that an attempt was made to perform an operation which An attempted operation could not be completed by the server
is not supported for the server (it may be generated locally by because the server does not support the operation.
the client if e.g. the version number exchange indicates that a
required feature is not supported by the server, or it may be This error MAY be generated locally by the client if e.g. the
returned by the server if the server does not implement an version number exchange indicates that a required feature is not
operation). supported by the server, or it may be returned by the server if
the server does not implement an operation).
SSH_FX_INVALID_HANDLE SSH_FX_INVALID_HANDLE
The handle value was invalid. The handle value was invalid.
SSH_FX_NO_SUCH_PATH SSH_FX_NO_SUCH_PATH
The file path does not exist or is invalid. The file path does not exist or is invalid.
SSH_FX_FILE_ALREADY_EXISTS SSH_FX_FILE_ALREADY_EXISTS
The file already exists. The file already exists.
SSH_FX_WRITE_PROTECT SSH_FX_WRITE_PROTECT
The file is on read only media, or the media is write protected. The file is on read-only media, or the media is write protected.
SSH_FX_NO_MEDIA SSH_FX_NO_MEDIA
The requested operation can not be completed because there is no The requested operation can not be completed because there is no
media available in the drive. media available in the drive.
SSH_FX_NO_SPACE_ON_FILESYSTEM
The requested operation cannot be completed because there is no
free space on the filesystem.
SSH_FX_QUOTA_EXCEEDED
The operation cannot be completed because the it would exceed the
users storage quota.
SSH_FX_UNKNOWN_PRINCIPLE
A principle referenced by the request (either the 'owner',
'group', or 'who' field of an ACL), was unknown. The error
specific data contains the problematic names. The format is one
or more:
string unknown-name
Each string contains the name of a principle that was unknown.
SSH_FX_LOCK_CONFlICT
The file could not be opened because it is locked by another
process.
The SSH_FXP_HANDLE response has the following format: The SSH_FXP_HANDLE response has the following format:
uint32 id byte SSH_FXP_HANDLE
uint32 request-id
string handle string handle
where `id' is the request identifier, and `handle' is an arbitrary where 'request-id' is the request identifier, and 'handle' is an
string that identifies an open file or directory on the server. The arbitrary string that identifies an open file or directory on the
handle is opaque to the client; the client MUST NOT attempt to server. The handle is opaque to the client; the client MUST NOT
interpret or modify it in any way. The length of the handle string attempt to interpret or modify it in any way. The length of the
MUST NOT exceed 256 data bytes. handle string MUST NOT exceed 256 data bytes.
The SSH_FXP_DATA response has the following format: The SSH_FXP_DATA response has the following format:
uint32 id byte SSH_FXP_DATA
uint32 request-id
string data string data
where `id' is the request identifier, and `data' is an arbitrary byte where 'request-id' is the request identifier, and 'data' is an
string containing the requested data. The data string may be at most arbitrary byte string containing the requested data. The data string
the number of bytes requested in a SSH_FXP_READ request, but may also may be at most the number of bytes requested in a SSH_FXP_READ
be shorter if end of file is reached or if the read is from something request, but may also be shorter if end of file is reached or if the
other than a regular file. read is from something other than a regular file.
The SSH_FXP_NAME response has the following format: The SSH_FXP_NAME response has the following format:
uint32 id byte SSH_FXP_NAME
uint32 request-id
uint32 count uint32 count
repeats count times: repeats count times:
string filename [UTF-8] string filename [UTF-8]
ATTRS attrs ATTRS attrs
where `id' is the request identifier, `count' is the number of names where 'request-id' is the request identifier, 'count' is the number
returned in this response, and the remaining fields repeat `count' of names returned in this response, and the remaining fields repeat
times (so that all three fields are first included for the first 'count' times. In the repeated part, 'filename' is a file name being
file, then for the second file, etc). In the repeated part, returned (for SSH_FXP_READDIR, it will be a relative name within the
`filename' is a file name being returned (for SSH_FXP_READDIR, it directory, without any path components; for SSH_FXP_REALPATH it will
will be a relative name within the directory, without any path be an absolute path name), and 'attrs' is the attributes of the file
components; for SSH_FXP_REALPATH it will be an absolute path name), as described in Section ''File Attributes''.
and `attrs' is the attributes of the file as described in Section
``File Attributes''.
The SSH_FXP_ATTRS response has the following format: The SSH_FXP_ATTRS response has the following format:
uint32 id byte SSH_FXP_ATTRS
uint32 request-id
ATTRS attrs ATTRS attrs
where `id' is the request identifier, and `attrs' is the returned where 'request-id' is the request identifier, and 'attrs' is the
file attributes as described in Section ``File Attributes''. returned file attributes as described in Section ''File Attributes''.
8. Vendor-Specific Extensions 8. Extensions
The SSH_FXP_EXTENDED request provides a generic extension mechanism The SSH_FXP_EXTENDED request provides a generic extension mechanism
for adding vendor-specific commands. The request has the following for adding additional commands.
format:
uint32 id byte SSH_FXP_EXTENDED
uint32 request-id
string extended-request string extended-request
... any request-specific data ... ... any request-specific data ...
where `id' is the request identifier, and `extended-request' is a request-id
string of the format "name@domain", where domain is an internet Identifier to be returned from the server with the response.
domain name of the vendor defining the request. The rest of the
request is completely vendor-specific, and servers should only extended-request
attempt to interpret it if they recognize the `extended-request' A string naming the extension. Vendor-specific extensions have
name. use the "name@domain" syntax, where domain is an internet domain
name of the vendor defining the request.
The IETF may also define extensions to the protocol. These
extension names will not have an '@' in them.
request-specific data
The rest of the request is defined by the extension, 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 The server may respond to such requests using any of the response
packets defined in Section ``Responses from the Server to the packets defined in Section ''Responses from the Server to the
Client''. Additionally, the server may also respond with a Client''. Additionally, the server may also respond with a
SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does
not recognize the `extended-request' name, then the server MUST not recognize the 'extended-request' name, then the server MUST
respond with SSH_FXP_STATUS with error/status set to respond with SSH_FXP_STATUS with error/status set to
SSH_FX_OP_UNSUPPORTED. SSH_FX_OP_UNSUPPORTED.
The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary 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 extension-specific data from the server to the client. It is of the
following format: following format:
uint32 id byte SSH_FXP_EXTENDED_REPLY
uint32 request-id
... any request-specific data ... ... any request-specific data ...
There is a range of packet types reserved for use by extensions. In There is a range of packet types reserved for use by extensions. In
order to avoid collision, extensions that turn on the use of order to avoid collision, extensions that that use additional packet
additional packet types should determine those numbers dynamically. types should determine those numbers dynamically.
The suggested way of doing this is have an extension request from the The suggested way of doing this is have an extension request from the
client to the server that enables the extension; the extension client to the server that enables the extension; the extension
response from the server to the client would specify the actual type response from the server to the client would specify the actual type
values to use, in additional to any other data. values to use, in additional to any other data.
Extension authors should be mindful of the limited range of packet Extension authors should be mindful of the limited range of packet
types available (there are only 45 values available) and avoid types available (there are only 45 values available) and avoid
requiring a new packet type where possible. requiring a new packet type where possible.
8.1 Checking File Contents
This extension allows a client to easily check if a file (or portion
thereof) that it already has matches what is on the server.
byte SSH_FXP_EXTENDED
uint32 request-id
string "md5-hash" / "md5-hash-handle"
string filename / file-handle
uint64 start-offset
uint64 length
string quick-check-hash
filename
Used if "md5-hash" is specified; indicates the name of the file to
use.
file-handle
Used if "md5-hash-handle" is specified; specifies a file handle to
read the data from. The handle MUST be a file handle, and
ACE4_READ_DATA MUST have been included in the desired-access when
the fail was opened.
start-offset
The starting offset of the data to hash.
length
The length of data to include in the hash. If both start-offset
and length are zero, the entire file should be included.
quick-check-hash
The hash over the first 2048 bytes of the data range as the client
knows it, or the entire range, if it is less than 2048 bytes.
This allows the server to quickly check if it is worth the
resources to hash a big file.
If this is a zero length string, the client does not have the
data, and is requesting the hash for reasons other than comparing
with a local file. The server MAY return SSH_FX_OP_UNSUPPORTED in
this case.
The response is either a SSH_FXP_STATUS packet, indicating an error,
or the following extended reply packet:
byte SSH_FXP_EXTENDED_REPLY
uint32 request-id
string "md5-hash"
string hash
If 'hash' is zero length, then the 'quick-check-hash' did not match,
and no hash operation was preformed. Otherwise, 'hash' contains the
hash of the entire data range (including the first 2048 bytes that
were included in the 'quick-check-hash'.)
9. Security Considerations 9. Security Considerations
This protocol assumes that it is run over a secure channel and that It is assumed that both ends of the connection have been
the endpoints of the channel have been authenticated. Thus, this authenticated and that the connection has privacy and integrity
protocol assumes that it is externally protected from network-level features. Such security issues are left to the underlying transport
attacks. protocol, except to note that if this is not the case, an attacker
could manipulate files on the server at will and thus wholly
compromise the server.
This protocol provides file system access to arbitrary files on the This protocol provides file system access to arbitrary files on the
server (only constrained by the server implementation). It is the server (only constrained by the server implementation). It is the
responsibility of the server implementation to enforce any access responsibility of the server implementation to enforce any access
controls that may be required to limit the access allowed for any controls that may be required to limit the access allowed for any
particular user (the user being authenticated externally to this particular user (the user being authenticated externally to this
protocol, typically using the SSH User Authentication Protocol [8]. protocol, typically using the SSH User Authentication Protocol [8].
Care must be taken in the server implementation to check the validity Extreme care must be used when interpreting file handle strings. In
of received file handle strings. The server should not rely on them particular, care must be taken that a file handle string is valid in
directly; it MUST check the validity of each handle before relying on the context of a given SFTP session. For example, the sftp server
it. daemon may have files which it has opened for its own purposes, and
the client must not be able to access these files by specifying an
arbitrary file handle string.
10. Changes from previous protocol versions The permission field of the attrib structure (Section 5.5) may
include the SUID, SGID, and SVTX (sticky) bits. Clients should use
extreme caution when setting these bits on either remote or local
files. (I.e., just because a file was SUID on the remote system does
not necessarily imply that it should be SUID on the local system.)
The SSH File Transfer Protocol has changed over time, before it's Filesystems often contain entries for objects that are not files at
all, but are rather devices. For example, it may be possible to
access serial ports, tape devices, or named pipes using this
protocol. Servers should exercise caution when granting access to
such resources. In addition to the dangers inherent in allowing
access to such a device, some devices may be 'slow', and could cause
denial of service by causing the server to block for a long period of
time while I/O is performed to such a device.
Servers should take care that file-system quotas are respected for
users. In addition, implementations should be aware that attacks may
be possible, or facilitated, by filling a filesystem. For example,
filling the filesystem where event logging and auditing occurs may,
at best, cause the system to crash, or at worst, allow the attacker
to take untraceable actions in the future.
Servers should take care that filenames are in their appropriate
canonical form, and to insure that filenames not in canonical form
cannot be used to bypass access checks or controls.
10. Changes from Previous Protocol Versions
The SSH File Transfer Protocol has changed over time, before its
standardization. The following is a description of the incompatible standardization. The following is a description of the incompatible
changes between different versions. changes between different versions.
10.1 Changes between versions 4 and 3 10.1 Changes Between Versions 5 and 4
Many of the changes between version 5 and version 4 are to better
support the changes in version 4, and to better specify error
conditions.
o Add "supported" extension to communicate features supported.
o Clarify error handling when client requests unsupported feature.
(For example, attempts to write an unsupported attribute.)
o Add attrib-bits field to the attribute structure, which specifies
a number of boolean attributes related to files and directories,
including advisory read-only and case-sensitivity bits.
o Clarify the actual bit values to be used for the permissions field
(since posix doesn't define values) and correct the value of
ATTR_PERMISSIONS flag.
o Some reordering of sections to attempt to get a better grouping of
related functionality.
o Open request explicitly specifies the access desired for the file.
o Add support for explicitly requesting file locking.
o Add support for better control of the rename operation.
o Add SSH_FX_NO_SPACE_ON_FILESYSTEM, SSH_FX_QUOTA_EXCEEDED, and
SSH_FX_UNKNOWN_PRINCIPLE error codes.
o Add support for error specific data. This is used by a new
SSH_FX_UNKNOWN_PRINCIPLE error to communicate which principles are
unknown.
o Add support for retrieving md5-hash of file contents.
o Update security section.
10.2 Changes Between Versions 4 and 3
Many of the changes between version 4 and version 3 are to the Many of the changes between version 4 and version 3 are to the
attribute structure to make it more flexible for non-unix platforms. attribute structure to make it more flexible for non-unix platforms.
o Clarify the use of stderr by the server. o Clarify the use of stderr by the server.
o Clarify handling of very large read requests by the server. o Clarify handling of very large read requests by the server.
o Make all filenames UTF-8. o Make all filenames UTF-8.
o Added 'newline' extension. o Added 'newline' extension.
o Made time fields 64 bit, and optionally have nanosecond resultion. o Made time fields 64 bit, and optionally have nanosecond
resolution.
o Made file attribute owner and group strings so they can actually o Made file attribute owner and group strings so they can actually
be used on disparate systems. be used on disparate systems.
o Added createtime field, and added separate flags for atime, o Added createtime field, and added separate flags for atime,
createtime, and mtime so they can be set separately. createtime, and mtime so they can be set separately.
o Split the file type out of the permissions field and into it's own o Split the file type out of the permissions field and into its own
field (which is always present.) field (which is always present.)
o Added acl attribute. o Added acl attribute.
o Added SSH_FXF_TEXT file open flag. o Added SSH_FXF_TEXT file open flag.
o Added flags field to the get stat commands so that the client can o Added flags field to the get stat commands so that the client can
specifically request information the server might not normally specifically request information the server might not normally
included for performance reasons. included for performance reasons.
o Removed the long filename from the names structure-- it can now be o Removed the long filename from the names structure-- it can now be
built from information available in the attrs structure. built from information available in the attrs structure.
o Added reserved range of packet numbers for extensions. o Added reserved range of packet numbers for extensions.
o Added several additional error codes. o Added several additional error codes.
10.2 Changes between versions 3 and 2 10.3 Changes Between Versions 3 and 2
o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added. o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added.
o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were
added. added.
o The SSH_FXP_STATUS message was changed to include fields `error o The SSH_FXP_STATUS message was changed to include fields 'error
message' and `language tag'. message' and 'language tag'.
10.3 Changes between versions 2 and 1 10.4 Changes Between Versions 2 and 1
o The SSH_FXP_RENAME message was added. o The SSH_FXP_RENAME message was added.
10.4 Changes between versions 1 and 0 10.5 Changes Between Versions 1 and 0
o Implementation changes, no actual protocol changes. o Implementation changes, no actual protocol changes.
11. Trademark Issues 11. Trademark Issues
"ssh" is a registered trademark of SSH Communications Security Corp "ssh" is a registered trademark of SSH Communications Security Corp
in the United States and/or other countries. in the United States and/or other countries.
References Normative References
[1] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999.
[2] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[3] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, [1] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC
3010, December 2000. 3010, December 2000.
[4] Institute of Electrical and Electronics Engineers, "Information [2] Institute of Electrical and Electronics Engineers, "Information
Technology - Portable Operating System Interface (POSIX) - Part Technology - Portable Operating System Interface (POSIX) - Part
1: System Application Program Interface (API) [C Language]", 1: System Application Program Interface (API) [C Language]",
IEEE Standard 1003.2, 1996. IEEE Standard 1003.2, 1996.
[5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. [3] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
Lehtinen, "SSH Protocol Architecture", Lehtinen, "SSH Protocol Architecture",
draft-ietf-secsh-architecture-13 (work in progress), September draft-ietf-secsh-architecture-13 (work in progress), September
2002. 2002.
[6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. [4] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
Lehtinen, "SSH Protocol Transport Protocol", Lehtinen, "SSH Protocol Transport Protocol",
draft-ietf-secsh-transport-15 (work in progress), September draft-ietf-secsh-transport-15 (work in progress), September
2002. 2002.
[7] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. [5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-16 Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-16
(work in progress), September 2002. (work in progress), September 2002.
Informative References
[6] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999.
[7] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[8] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. [8] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
Lehtinen, "SSH Authentication Protocol", Lehtinen, "SSH Authentication Protocol",
draft-ietf-secsh-userauth-16 (work in progress), September 2002. draft-ietf-secsh-userauth-16 (work in progress), September 2002.
Authors' Addresses Authors' Addresses
Joseph Galbraith Joseph Galbraith
VanDyke Software VanDyke Software
4848 Tramway Ridge Blvd 4848 Tramway Ridge Blvd
Suite 101 Suite 101
skipping to change at page 37, line 29 skipping to change at page 49, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 38, line 7 skipping to change at page 50, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/