draft-ietf-secsh-filexfer-01.txt   draft-ietf-secsh-filexfer-02.txt 
Network Working Group T. Ylonen and S. Lehtinen
INTERNET-DRAFT SSH Communications Security
Expires: 2 September, 2001 Network Working Group T. Ylonen
Internet-Draft S. Lehtinen
Expires: April 1, 2002 SSH Communications Security Corp
October 2001
Secure Shell File Transfer Protocol SSH File Transfer Protocol
draft-ietf-secsh-filexfer-02.txt
Status of This Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance with
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 groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet- time. It is inappropriate to use Internet-Drafts as reference
Drafts as reference material or to cite them other than as material or to cite them other than as "work in progress."
"work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at http://
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 April 1, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
The Secure Shell 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 Secure Shell Remote Login Protocol. transfer protocol for use with the SSH2 protocol. This document
This document describes the file transfer protocol and its interface to describes the file transfer protocol and its interface to the SSH2
the Secure Shell protocol suite. protocol suite.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use with the Secure Shell Connection Protocol . . . . . . . . . 3 2. Use with the SSH Connection Protocol . . . . . . . . . . . . 4
3. General Packet Format . . . . . . . . . . . . . . . . . . . . . 3 3. General Packet Format . . . . . . . . . . . . . . . . . . . 5
4. Protocol Initialization . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Initialization . . . . . . . . . . . . . . . . . . 7
5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . . 5 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . 8
6. Responses from the Server to the Client . . . . . . . . . . . . 6 6. Requests From the Client to the Server . . . . . . . . . . . 10
7. Requests From the Client to the Server . . . . . . . . . . . . . 9 6.1 Request Synchronization and Reordering . . . . . . . . . . . 10
7.1. Request Synchronization and Reordering . . . . . . . . . . . 10 6.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. File Names . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3 Opening, Creating, and Closing Files . . . . . . . . . . . . 11
7.3. Opening, Creating, and Closing Files . . . . . . . . . . . . 11 6.4 Reading and Writing . . . . . . . . . . . . . . . . . . . . 13
7.4. Reading and Writing . . . . . . . . . . . . . . . . . . . . 12 6.5 Removing and Renaming Files . . . . . . . . . . . . . . . . 14
7.5. Removing and Renaming Files . . . . . . . . . . . . . . . . 13 6.6 Creating and Deleting Directories . . . . . . . . . . . . . 15
7.6. Creating and Deleting Directories . . . . . . . . . . . . . 14 6.7 Scanning Directories . . . . . . . . . . . . . . . . . . . . 15
7.7. Scanning Directories . . . . . . . . . . . . . . . . . . . . 14 6.8 Retrieving File Attributes . . . . . . . . . . . . . . . . . 16
7.8. Retrieving File Attributes . . . . . . . . . . . . . . . . . 15 6.9 Setting File Attributes . . . . . . . . . . . . . . . . . . 17
7.9. Setting File Attributes . . . . . . . . . . . . . . . . . . 16 6.10 Dealing with Symbolic links . . . . . . . . . . . . . . . . 18
7.10. Dealing with Symbolic links . . . . . . . . . . . . . . . . 16 6.11 Canonicalizing the Server-Side Path Name . . . . . . . . . . 18
7.11. Canonicalizing the Server-Side Path Name . . . . . . . . . 17 7. Responses from the Server to the Client . . . . . . . . . . 20
8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . . . 17 8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . 25
10. Changes from previous protocol versions . . . . . . . . . . . . 18 10. Changes from previous protocol versions . . . . . . . . . . 26
10.1. Changes between versions 3 and 2 . . . . . . . . . . . . . 18 10.1 Changes between versions 3 and 2 . . . . . . . . . . . . . . 26
10.2. Changes between versions 2 and 1 . . . . . . . . . . . . . 18 10.2 Changes between versions 2 and 1 . . . . . . . . . . . . . . 26
10.3. Changes between versions 1 and 0 . . . . . . . . . . . . . 18 10.3 Changes between versions 1 and 0 . . . . . . . . . . . . . . 26
11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 18 11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 References . . . . . . . . . . . . . . . . . . . . . . . . . 28
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28
Full Copyright Statement . . . . . . . . . . . . . . . . . . 29
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) functionality over a reliable data stream, such as a
channel in the Secure Shell Remote Login Protocol [SECSH-ARCH]. channel in the SSH2 protocol [3].
This protocol is designed so that it could be used to implement a secure This protocol is designed so that it could be used to implement a
remote file system service, as well as a secure file transfer service. secure remote file system service, as well as a secure file transfer
service.
This protocol assumes that it runs over a secure channel, and that the This protocol assumes that it runs over a secure channel, and that
server has already authenticated the user at the client end, and that the server has already authenticated the user at the client end, and
the identity of the client user is externally available to the server that the identity of the client user is externally available to the
implementation. server implementation.
In general, this protocol follows a simple request-response model. Each In general, this protocol follows a simple request-response model.
request and response contains a sequence number and multiple requests Each request and response contains a sequence number and multiple
may be pending simultaneously. There are a relatively large number of requests may be pending simultaneously. There are a relatively large
different request messages, but a small number of possible response number of different request messages, but a small number of possible
messages. Each request has one or more response messages that may be response messages. Each request has one or more response messages
returned in result (e.g., a read either returns data or reports error that may be returned in result (e.g., a read either returns data or
status). reports error status).
The packet format descriptions in this specification follow the notation The packet format descriptions in this specification follow the
presented in [SECSH-ARCH]. notation presented in the secsh architecture draft.[3].
Even though this protocol is described in the context of the Secure Even though this protocol is described in the context of the SSH2
Shell Remote Login Protocol, this protocol is general and independent of protocol, this protocol is general and independent of the rest of the
the rest of the Secure Shell protocol suite. It could be used in a SSH2 protocol suite. It could be used in a number of different
number of different applications, such as secure file transfer over TLS applications, such as secure file transfer over TLS RFC 2246 [1] and
[RFC-2246] and transfer of management information in VPN applications. transfer of management information in VPN applications.
2. Use with the Secure Shell Connection Protocol 2. Use with the SSH Connection Protocol
When used with the Secure Shell protocol suite, this protocol is When used with the SSH2 Protocol suite, this protocol is intended to
intended to be used from the Secure Shell Connection Protocol as a be used from the SSH Connection Protocol [5] as a subsystem, as
subsystem, as described in [SECSH-CONN], Section ``Starting a Shell or a described in section ``Starting a Shell or a Command''. The
Command''. The subsystem name used with this protocol is "sftp". subsystem name used with this protocol is "sftp".
3. General Packet Format 3. General Packet Format
All packets transmitted over the secure connection are of the following All packets transmitted over the secure connection are of the
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 just 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 the include the `length' field itself. The format and interpretation of
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 data All packet descriptions below only specify the packet type and the
that goes into the data field. Thus, they should be prefixed by the data that goes into the data field. Thus, they should be prefixed by
`length' and `type' fields. the `length' and `type' fields.
The maximum size of a packet is in practise 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 of including the header above). This should allow for reads and writes
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 practise 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 not performed by the server. If the server's queues are full, it should
read any more data from the stream, and flow control will prevent the not read any more data from the stream, and flow control will prevent
client from sending more requests. Note, however, that while there is the client from sending more requests. Note, however, that while
no restriction on the protocol level, the client's API may provide a there is no restriction on the protocol level, the client's API may
limit in order to prevent infinite queueing of outgoing requests at the provide a limit in order to prevent infinite queuing of outgoing
client. requests at the client.
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
skipping to change at page 4, line 33 skipping to change at page 6, line 35
#define SSH_FXP_READLINK 19 #define SSH_FXP_READLINK 19
#define SSH_FXP_SYMLINK 20 #define SSH_FXP_SYMLINK 20
#define SSH_FXP_STATUS 101 #define SSH_FXP_STATUS 101
#define SSH_FXP_HANDLE 102 #define SSH_FXP_HANDLE 102
#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
Additional packet types should only be defined if the protocol version Additional packet types should only be defined if the protocol
number (see Section ``Protocol Initialization'') is incremented, and version number (see Section ``Protocol Initialization'') is
their use MUST be negotiated using the version number. However, the incremented, and their use MUST be negotiated using the version
SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY packets can be used to number. However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY
implement vendor-specific extensions. See Section ``Vendor-Specific packets can be used to implement vendor-specific extensions. See
Extensions'' for more details. Section ``Vendor-Specific-Extensions'' for more details.
4. Protocol Initialization 4. Protocol Initialization
When the file transfer protocol starts, it first sends a SSH_FXP_INIT When the file transfer protocol starts, it first sends a SSH_FXP_INIT
(including its version number) packet to the server. The server (including its version number) packet to the server. The server
responds with a SSH_FXP_VERSION packet, supplying the lowest of its own responds with a SSH_FXP_VERSION packet, supplying the lowest of its
and the client's version number. Both parties should from then on own and the client's version number. Both parties should from then
adhere to particular version of the protocol. on adhere to particular version of the protocol.
The SSH_FXP_INIT packet (from client to server) has the following data: The SSH_FXP_INIT packet (from client to server) has the following
data:
uint32 version uint32 version
<extension data> <extension data>
The SSH_FXP_VERSION packet (from server to client) has the following The SSH_FXP_VERSION packet (from server to client) has the following
data: data:
uint32 version uint32 version
<extension data> <extension data>
The version number of the protocol specified in this document is 3. The The version number of the protocol specified in this document is 3.
version number should be incremented for each incompatible revision of The version number should be incremented for each incompatible
this protocol. revision of this protocol.
The extension data in the above packets may be empty, or may be a The extension data in the above packets may be empty, or may be a
sequence of 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 `exten- pairs (both strings MUST always be present if one is, but the
sion_data' string may be of zero length). If present, these strings `extension_data' string may be of zero length). If present, these
indicate extensions to the baseline protocol. The `extension_name' strings indicate extensions to the baseline protocol. The
field(s) identify the name of the extension. The name should be of the `extension_name' field(s) identify the name of the extension. The
form "name@domain", where the domain is the DNS domain name of the orga- name should be of the form "name@domain", where the domain is the DNS
nization defining the extension. Additional names that are not of this domain name of the organization defining the extension. Additional
format may be defined later by the IETF. Implementations MUST silently names that are not of this format may be defined later by the IETF.
ignore any extensions whose name they do not recognize. Implementations MUST silently ignore any extensions whose name they
do not recognize.
5. File Attributes 5. File Attributes
A new compound data type is defined for encoding file attributes. It is A new compound data type is defined for encoding file attributes. It
basically just a combination of elementary types, but is defined once is basically just a combination of elementary types, but is defined
because of the non-trivial description of the fields and to ensure once because of the non-trivial description of the fields and to
maintainability. ensure maintainability.
The same encoding is used both when returning file attributes from the The same encoding is used both when returning file attributes from
server and when sending file attributes to the server. When sending it the server and when sending file attributes to the server. When
to the server, the flags field specifies which attributes are included, sending it to the server, the flags field specifies which attributes
and the server will use default values for the remaining attributes (or are included, and the server will use default values for the
will not modify the values of remaining attributes). When receiving remaining attributes (or will not modify the values of remaining
attributes from the server, the flags specify which attributes are attributes). When receiving attributes from the server, the flags
included in the returned data. The server normally returns all specify which attributes are included in the returned data. The
attributes it knows about. server normally returns all attributes it knows about.
uint32 flags uint32 flags
uint64 size present only if flag SSH_FILEXFER_ATTR_SIZE uint64 size present only if flag SSH_FILEXFER_ATTR_SIZE
uint32 uid present only if flag SSH_FILEXFER_ATTR_UIDGID uint32 uid present only if flag SSH_FILEXFER_ATTR_UIDGID
uint32 gid present only if flag SSH_FILEXFER_ATTR_UIDGID uint32 gid present only if flag SSH_FILEXFER_ATTR_UIDGID
uint32 permissions present only if flag uint32 permissions present only if flag SSH_FILEXFER_ATTR_PERMISSIONS
SSH_FILEXFER_ATTR_PERMISSIONS
uint32 atime present only if flag SSH_FILEXFER_ACMODTIME uint32 atime present only if flag SSH_FILEXFER_ACMODTIME
uint32 mtime present only if flag SSH_FILEXFER_ACMODTIME uint32 mtime present only if flag SSH_FILEXFER_ACMODTIME
uint32 extended_count present only if flag uint32 extended_count present only if flag SSH_FILEXFER_ATTR_EXTENDED
SSH_FILEXFER_ATTR_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
The `flags' specify which of the fields are present. Those fields for The `flags' specify which of the fields are present. Those fields
which the corresponding flag is not set are not present (not included in for which the corresponding flag is not set are not present (not
the packet). New flags can only be added by incrementing the protocol included in the packet). New flags can only be added by incrementing
the protocol version number (or by using the extension mechanism
version number (or by using the extension mechanism described below). described below).
The `size' field specifies the size of the file in bytes. The `size' field specifies the size of the file in bytes.
The `uid' and `gid' fields contain numeric Unix-like user and group The `uid' and `gid' fields contain numeric Unix-like user and group
identifiers, respectively. identifiers, respectively.
The `permissions' field contains a bit mask of file permissions as The `permissions' field contains a bit mask of file permissions as
defined by [POSIX]. defined by posix [1].
The `atime' and `mtime' contain the access and modification times of the The `atime' and `mtime' contain the access and modification times of
files, respectively. They are represented as seconds from Jan 1, 1970 the files, respectively. They are represented as seconds from Jan 1,
in UTC. 1970 in UTC.
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 vendor-specific extensions. If the flag is specified,
then the `extended_count' field is present. It specifies the number of then the `extended_count' field is present. It specifies the number
extended_type-extended_data pairs that follow. Each of these pairs of extended_type-extended_data pairs that follow. Each of these
specifies an extended attribute. For each of the attributes, the pairs specifies an extended attribute. For each of the attributes,
extended_type field should be a string of the format "name@domain", the extended_type field should be a string of the format
where "domain" is a valid, registered domain name and "name" identifies "name@domain", where "domain" is a valid, registered domain name and
the method. The IETF may later standardize certain names that deviate "name" identifies the method. The IETF may later standardize certain
from this format (e.g., that do not contain the "@" sign). The names that deviate from this format (e.g., that do not contain the
interpretation of `extended_data' depends on the type. Implementations "@" sign). The interpretation of `extended_data' depends on the
SHOULD ignore extended data fields that they do not understand. type. Implementations SHOULD ignore extended data fields that they
do not 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 should mechanism is recommended for most purposes; additional flags bits
only be defined by an IETF standards action that also increments the should only be defined by an IETF standards action that also
protocol version number. The use of such new fields MUST be negotiated increments the protocol version number. The use of such new fields
by the version number in the protocol exchange. It is a protocol error MUST be negotiated by the version number in the protocol exchange.
if a packet with unsupported protocol bits is received. It is a protocol error if a packet with unsupported protocol bits is
received.
The flags bits are defined to have the following values: The flags bits are defined to have the following values:
#define SSH_FILEXFER_ATTR_SIZE 0x00000001 #define SSH_FILEXFER_ATTR_SIZE 0x00000001
#define SSH_FILEXFER_ATTR_UIDGID 0x00000002 #define SSH_FILEXFER_ATTR_UIDGID 0x00000002
#define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004 #define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004
#define SSH_FILEXFER_ATTR_ACMODTIME 0x00000008 #define SSH_FILEXFER_ATTR_ACMODTIME 0x00000008
#define SSH_FILEXFER_ATTR_EXTENDED 0x80000000 #define SSH_FILEXFER_ATTR_EXTENDED 0x80000000
6. Responses from the Server to the Client 6. Requests From the Client to the Server
The server responds to the client using one of a few response packets.
All requests can return a SSH_FXP_STATUS response upon failure. When
the operation is successful, any of the responses may be returned
(depending on the operation). If no data needs to be returned to the
client, the SSH_FXP_STATUS response with SSH_FX_OK 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 response
packet contains a request identifier which can be used to match each
response with the corresponding request. Note that it is legal to have
several requests outstanding simultaneously, and the 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 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).
Response packets are of the same general format as request packets.
Each response packet begins with the request identifier.
The format of the data portion of the SSH_FXP_STATUS response is as
follows:
uint32 id
uint32 error/status code
string error message (ISO-10646 UTF-8 [RFC-2279])
string language tag (as defined in [RFC-1766])
where `id' is the request identifier, and `error/status code' indicates
the result of the requested operation. The value SSH_FX_OK indicates
success, and all other values indicate failure. Currently, the follow-
ing values are defined (other values may be defined by future versions
of this protocol):
#define SSH_FX_OK 0
#define SSH_FX_EOF 1
#define SSH_FX_NO_SUCH_FILE 2
#define SSH_FX_PERMISSION_DENIED 3
#define SSH_FX_FAILURE 4
#define SSH_FX_BAD_MESSAGE 5
#define SSH_FX_NO_CONNECTION 6
#define SSH_FX_CONNECTION_LOST 7
#define SSH_FX_OP_UNSUPPORTED 8
SSH_FX_OK
Indicates successful completion of the operation.
SSH_FX_EOF
indicates end-of-file condition; for SSH_FX_READ it means that no
more data is available in the file, and for SSH_FX_READDIR it
indicates that no more files are contained in the directory.
SSH_FX_NO_SUCH_FILE
is returned when a reference is made to a file which should exist
but doesn't.
SSH_FX_PERMISSION_DENIED
is returned when the authenticated user does not have sufficient
permissions to perform the operation.
SSH_FX_FAILURE
is a generic catch-all error message; it should be returned if an
error occurs for which there is no more specific error code
defined.
SSH_FX_BAD_MESSAGE
may be returned if a badly formatted packet or protocol
incompatibility is detected.
SSH_FX_NO_CONNECTION
is a pseudo-error which indicates that the client has no
connection to the server (it can only be generated locally by the
client, and MUST NOT be returned by servers).
SSH_FX_CONNECTION_LOST
is a pseudo-error which indicates that the connection to the
server has been lost (it can only be generated locally by the
client, and MUST NOT be returned by servers).
SSH_FX_OP_UNSUPPORTED
indicates that an attempt was made to perform an operation which
is not supported for the server (it may be generated locally by
the client if e.g. the version number exchange indicates that a
required feature is not supported by the server, or it may be
returned by the server if the server does not implement an
operation).
The SSH_FXP_HANDLE response has the following format:
uint32 id
string handle
where `id' is the request identifier, and `handle' is an arbitrary
string that identifies an open file or directory on the server. The
handle is opaque to the client; the client MUST NOT attempt to interpret
or modify it in any way. The length of the handle string MUST NOT
exceed 256 data bytes.
The SSH_FXP_DATA response has the following format:
uint32 id
string data
where `id' is the request identifier, and `data' is an arbitrary byte
string containing the requested data. The data string may be at most
the number of bytes requested in a SSH_FXP_READ request, but may also be
shorter if end of file is reached or if the read is from something other
than a regular file.
The SSH_FXP_NAME response has the following format:
uint32 id
uint32 count
repeats count times:
string filename
string longname
ATTRS attrs
where `id' is the request identifier, `count' is the number of names
returned in this response, and the remaining fields repeat `count' times
(so that all three fields are first included for the first file, then
for the second file, etc). In the repeated part, `filename' is a file
name being returned (for SSH_FXP_READDIR, it will be a relative name
within the directory, without any path components; for SSH_FXP_REALPATH
it will be an absolute path name), `longname' is an expanded format for
the file name, similar to what is returned by "ls -l" on Unix systems,
and `attrs' is the attributes of the file as described in Section ``File
Attributes''.
The format of the `longname' field is unspecified by this protocol. It
MUST be suitable for use in the output of a directory listing command
(in fact, the recommended operation for a directory listing command is
to simply display this data). However, clients SHOULD NOT attempt to
parse the longname field for file attributes; they SHOULD use the attrs
field instead.
The recommended format for the longname field is as follows:
-rwxr-xr-x 1 mjos staff 348911 Mar 25 14:29 t-filexfer
1234567890 123 12345678 12345678 12345678 123456789012
Here, the first line is sample output, and the second field indicates
widths of the various fields. Fields are separated by spaces. The
first field lists file permissions for user, group, and others; the sec-
ond field is link count; the third field is the name of the user who
owns the file; the fourth field is the name of the group that owns the
file; the fifth field is the size of the file in bytes; the sixth field
(which actually may contain spaces, but is fixed to 12 characters) is
the file modification time, and the seventh field is the file name.
Each field is specified to be a minimum of certain number of character
positions (indicated by the second line above), but may also be longer
if the data does not fit in the specified length.
The SSH_FXP_ATTRS response has the following format:
uint32 id
ATTRS attrs
where `id' is the request identifier, and `attrs' is the returned file
attributes as described in Section ``File Attributes''.
7. Requests From the Client to the Server
Requests from the client to the server represent the various file system
operations. Each request begins with an `id' field, which is a 32-bit Requests from the client to the server represent the various file
identifier identifying the request (selected by the client). The same system operations. Each request begins with an `id' field, which is
identifier will be returned in the response to the request. One a 32-bit identifier identifying the request (selected by the client).
possible implementation of it is a monotonically increasing request The same identifier will be returned in the response to the request.
sequence number (modulo 2^32). One possible implementation of it is a monotonically increasing
request sequence number (modulo 2^32).
Many operations in the protocol operate on open files. The SSH_FXP_OPEN Many operations in the protocol operate on open files. The
request can return a file handle (which is an opaque variable-length SSH_FXP_OPEN request can return a file handle (which is an opaque
string) which may be used to access the file later (e.g. in a read variable-length string) which may be used to access the file later
operation). The client MUST NOT send requests the server with bogus or (e.g. in a read operation). The client MUST NOT send requests the
closed handles. However, the server MUST perform adequate checks on the server with bogus or closed handles. However, the server MUST
handle in order to avoid security risks due to fabricated handles. 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, This design allows either stateful and stateless server
as well as an implementation which caches state between requests but may implementation, as well as an implementation which caches state
also flush it. The contents of the file handle string are entirely up between requests but may also flush it. The contents of the file
to the server and its design. The client should not modify or attempt handle string are entirely up to the server and its design. The
to interpret the file handle strings. client should not modify or attempt to interpret the file handle
strings.
The file handle strings MUST NOT be longer than 256 bytes. The file handle strings MUST NOT be longer than 256 bytes.
7.1. Request Synchronization and Reordering 6.1 Request Synchronization and Reordering
The protocol and implementations MUST process requests relating to the
same file in the order in which they are received. In other 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 requests one at a
time and waited for the response in each case. For example, the server
may process non-overlapping read/write requests to the same file in
parallel, but overlapping reads and writes cannot be reordered or
parallelized. However, there are no ordering restrictions on the server
for processing requests from two different file transfer connections.
The server may interleave and parallelize them at will.
There are no restrictions on the order in which responses to outstanding The protocol and implementations MUST process requests relating to
requests are delivered to the client, except that the server must ensure the same file in the order in which they are received. In other
fairness in the sense that processing of no request will be indefinitely words, if an application submits multiple requests to the server, the
delayed even if the client is sending other requests so that there are results in the responses will be the same as if it had sent the
multiple outstanding requests all the time. requests one at a time and waited for the response in each case. For
example, the server may process non-overlapping read/write requests
to the same file in parallel, but overlapping reads and writes cannot
be reordered or parallelized. However, there are no ordering
restrictions on the server for processing requests from two different
file transfer connections. The server may interleave and parallelize
them at will.
7.2. File Names There are no restrictions on the order in which responses to
outstanding requests are delivered to the client, except that the
server must ensure fairness in the sense that processing of no
request will be indefinitely delayed even if the client is sending
other requests so that there are multiple outstanding requests all
the time.
This protocol represents file names as strings. File names are assumed 6.2 File Names
to use the slash ('/') character as a directory separator.
File names starting with a slash are "absolute", and are relative to the This protocol represents file names as strings. File names are
root of the file system. Names starting with any other character are assumed to use the slash ('/') character as a directory separator.
relative to the user's default directory (home directory). Note that
identifying the user is assumed to take place outside of this protocol.
Servers SHOULD interpret a path name component ".." as referring to the File names starting with a slash are "absolute", and are relative to
parent directory, and "." as referring to the current directory. If the the root of the file system. Names starting with any other character
server implementation limits access to certain parts of the file system, are relative to the user's default directory (home directory). Note
that identifying the user is assumed to take place outside of this
protocol.
it must be extra careful in parsing file names when enforcing such Servers SHOULD interpret a path name component ".." as referring to
restrictions. There have been numerous reported security bugs where a the parent directory, and "." as referring to the current directory.
".." in a path name has allowed access outside the intended area. If the server implementation limits access to certain parts of the
file system, it must be extra careful in parsing file names when
enforcing such restrictions. There have been numerous reported
security bugs where a ".." in a path name has allowed access outside
the intended area.
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 splice Clients should not make any other assumptions; however, they can
path name components returned by SSH_FXP_READDIR together using a slash splice path name components returned by SSH_FXP_READDIR together
('/') as the separator, and that will work as expected. using a slash ('/') as the separator, and that will work as expected.
It is understood that the lack of well-defined semantics for file names It is understood that the lack of well-defined semantics for file
may cause interoperability problems between clients and servers using names may cause interoperability problems between clients and servers
radically different operating systems. However, this approach is known using radically different operating systems. However, this approach
to work acceptably with most systems, and alternative approaches that is known to work acceptably with most systems, and alternative
e.g. treat file names as sequences of structured components are quite approaches that e.g. treat file names as sequences of structured
complicated. components are quite complicated.
7.3. Opening, Creating, and Closing Files 6.3 Opening, Creating, and Closing Files
Files are opened and created using the SSH_FXP_OPEN message, whose data Files are opened and created using the SSH_FXP_OPEN message, whose
part is as follows: data part is as follows:
uint32 id uint32 id
string filename string filename
uint32 pflags uint32 pflags
ATTRS attrs ATTRS attrs
The `id' field is the request identifier as for all requests. The `id' field is the request identifier as for all requests.
The `filename' field specifies the file name. See Section ``File 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 defined. The `pflags' field is a bitmask. The following bits have been
defined.
#define SSH_FXF_READ 0x00000001 #define SSH_FXF_READ 0x00000001
#define SSH_FXF_WRITE 0x00000002 #define SSH_FXF_WRITE 0x00000002
#define SSH_FXF_APPEND 0x00000004 #define SSH_FXF_APPEND 0x00000004
#define SSH_FXF_CREAT 0x00000008 #define SSH_FXF_CREAT 0x00000008
#define SSH_FXF_TRUNC 0x00000010 #define SSH_FXF_TRUNC 0x00000010
#define SSH_FXF_EXCL 0x00000020 #define SSH_FXF_EXCL 0x00000020
These have the following meanings: These have the following meanings:
skipping to change at page 12, line 8 skipping to change at page 12, line 29
SSH_FXF_WRITE SSH_FXF_WRITE
Open the file for writing. If both this and SSH_FXF_READ are Open the file for writing. If both this and SSH_FXF_READ are
specified, the file is opened for both reading and writing. specified, the file is opened for both reading and writing.
SSH_FXF_APPEND SSH_FXF_APPEND
Force all writes to append data at the end of the file. Force all writes to append data at the end of the file.
SSH_FXF_CREAT SSH_FXF_CREAT
If this flag is specified, then a new file will be created if one If this flag is specified, then a new file will be created if one
does not alread exist (if O_TRUNC is specified, the new file will does not already exist (if O_TRUNC is specified, the new file will
be truncated to zero length if it previously exists). be truncated to zero length if it previously exists).
SSH_FXF_TRUNC SSH_FXF_TRUNC
Forces an existing file with the same name to be truncated to zero Forces an existing file with the same name to be truncated to zero
length when creating a file by specifying SSH_FXF_CREAT. length when creating a file by specifying SSH_FXF_CREAT.
SSH_FXF_CREAT MUST also be specified if this flag is used. SSH_FXF_CREAT MUST also be specified if this flag is used.
SSH_FXF_EXCL SSH_FXF_EXCL
Causes the request to fail if the named file already exists. Causes the request to fail if the named file already exists.
SSH_FXF_CREAT MUST also be specified if this flag is used. SSH_FXF_CREAT MUST also be specified if this flag is used.
The `attrs' field specifies the initial attributes for the file. The `attrs' field specifies the initial attributes for the file.
Default values will be used for those attributes that are not specified. Default values will be used for those attributes that are not
See Section ``File Attributes'' for more information. specified. See Section ``File Attributes'' for more information.
Regardless the server operating system, the file will always be opened Regardless the server operating system, the file will always be
in "binary" mode (i.e., no translations between different character sets opened in "binary" mode (i.e., no translations between different
and newline encodings). character sets and newline encodings).
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 has A file is closed by using the SSH_FXP_CLOSE request. Its data field
the following format: has the following format:
uint32 id uint32 id
string handle string handle
where `id' is the request identifier, and `handle' is a handle previ- where `id' is the request identifier, and `handle' is a handle
ously returned in the response to SSH_FXP_OPEN or SSH_FXP_OPENDIR. The previously returned in the response to SSH_FXP_OPEN or
handle becomes invalid immediately after this request has been sent. SSH_FXP_OPENDIR. The handle becomes invalid immediately after this
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. One
should note that on some server platforms even a close can fail. This should note that on some server platforms even a close can fail.
can happen e.g. if the server operating system caches writes, and an This can happen e.g. if the server operating system caches writes,
error occurs while flushing cached writes during the close. and an error occurs while flushing cached writes during the close.
7.4. Reading and Writing 6.4 Reading and Writing
Once a file has been opened, it can be read using the SSH_FXP_READ Once a file has been opened, it can be read using the SSH_FXP_READ
message, which has the following format: message, which has the following format:
uint32 id uint32 id
string handle string handle
uint64 offset uint64 offset
uint32 len uint32 len
where `id' is the request identifier, `handle' is an open file handle where `id' is the request identifier, `handle' is an open file handle
returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative
returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative to to the beginning of the file from where to start reading, and `len'
the beginning of the file from where to start reading, and `len' is the is the maximum number of bytes to read.
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 `len'), 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. For normal disk data, the server will respond with SSH_FXP_STATUS. For normal disk
files, it is guaranteed that this will read the specified number of files, it is guaranteed that this will read the specified number of
bytes, or up to end of file. For e.g. device files this may return bytes, or up to end of file. For e.g. device files this may return
fewer bytes than requested. fewer bytes than requested.
Writing to a file is achieved using the SSH_FXP_WRITE message, which has Writing to a file is achieved using the SSH_FXP_WRITE message, which
the following format: has the following format:
uint32 id uint32 id
string handle string handle
uint64 offset uint64 offset
string data string data
where `id' is a request identifier, `handle' is a file handle returned where `id' is a request identifier, `handle' is a file handle
by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the beginning of returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the
the file where to start writing, and `data' is the data to be written. beginning of the file where to start writing, and `data' is the data
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 are It is legal to write way beyond the end of the file; the semantics
to write zeroes from the end of the file to the specified offset and are to write zeroes from the end of the file to the specified offset
then the data. On most operating systems, such writes do not allocate and then the data. On most operating systems, such writes do not
disk space but instead leave "holes" in the file. allocate disk space but instead leave "holes" in the 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.
7.5. Removing and Renaming Files 6.5 Removing and Renaming Files
Files can be removed using the SSH_FXP_REMOVE message. It has the Files can be removed using the SSH_FXP_REMOVE message. It has the
following format: following format:
uint32 id uint32 id
string filename string filename
where `id' is the request identifier and `filename' is the name of the where `id' is the request identifier and `filename' is the name of
file to be removed. See Section ``File Names'' for more information. the file to be removed. See Section ``File Names'' for more
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 message. The server will respond to this request with a SSH_FXP_STATUS
message.
Files (and directories) can be renamed using the SSH_FXP_RENAME message. Files (and directories) can be renamed using the SSH_FXP_RENAME
Its data is as follows: message. Its data is as follows:
uint32 id uint32 id
string oldpath string oldpath
string newpath string newpath
where `id' is the request identifier, `oldpath' is the name of an exist- where `id' is the request identifier, `oldpath' is the name of an
ing file or directory, and `newpath' is the new name for the file or existing file or directory, and `newpath' is the new name for the
directory. It is an error if there already exists a file with the name file or directory. It is an error if there already exists a file
specified by newpath. The server may also fail rename requests in other with the name specified by newpath. The server may also fail rename
situations, for example if `oldpath' and `newpath' point to different requests in other situations, for example if `oldpath' and `newpath'
file systems on the server. point to different file systems on the server.
The server will respond to this request with a SSH_FXP_STATUS message. The server will respond to this request with a SSH_FXP_STATUS
message.
7.6. Creating and Deleting Directories 6.6 Creating and Deleting Directories
New directories can be created using the SSH_FXP_MKDIR request. It has New directories can be created using the SSH_FXP_MKDIR request. It
the following format: has the following format:
uint32 id uint32 id
string path string path
ATTRS attrs ATTRS attrs
where `id' is the request identifier, `path'and `attrs' specifies the where `id' is the request identifier, `path' and `attrs' specifies
modifications to be made to its attributes. See Section ``File Names'' the modifications to be made to its attributes. See Section ``File
for more information on file names. Attributes are discussed in more Names'' for more information on file names. Attributes are discussed
detail in Section ``File Attributes''. specifies the directory to be in more detail in Section ``File Attributes''. specifies the
created. An error will be returned if a file or directory with the directory to be created. An error will be returned if a file or
specified path already exists. The server will respond to this request directory with the specified path already exists. The server will
with a SSH_FXP_STATUS message. respond to this request with a SSH_FXP_STATUS message.
Directories can be removed using the SSH_FXP_RMDIR request, which has Directories can be removed using the SSH_FXP_RMDIR request, which
the following format: has the following format:
uint32 id uint32 id
string path string path
where `id' is the request identifier, and `path' specifies the directory where `id' is the request identifier, and `path' specifies the
to be removed. See Section ``File Names'' for more information on file directory to be removed. See Section ``File Names'' for more
names. An error will be returned if no directory with the specified information on file names. An error will be returned if no directory
path exists, or if the specified directory is not empty, or if the path with the specified path exists, or if the specified directory is not
specified a file system object other than a directory. The server empty, or if the path specified a file system object other than a
responds to this request with a SSH_FXP_STATUS message. directory. The server responds to this request with a SSH_FXP_STATUS
message.
7.7. Scanning Directories 6.7 Scanning Directories
The files in a directory can be listed using the SSH_FXP_OPENDIR and 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 SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one
more file names with full file attributes for each file. The client or more file names with full file attributes for each file. The
should call SSH_FXP_READDIR repeatedly until it has found the file it is client should call SSH_FXP_READDIR repeatedly until it has found the
looking for or until the server responds with a SSH_FXP_STATUS message file it is looking for or until the server responds with a
indicating an error (normally SSH_FX_EOF if there are no more files in SSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF if
the directory). The client should then close the handle using the there are no more files in the directory). The client should then
SSH_FXP_CLOSE request. close the handle using the SSH_FXP_CLOSE request.
The SSH_FXP_OPENDIR opens a directory for reading. It has the following The SSH_FXP_OPENDIR opens a directory for reading. It has the
format: following format:
uint32 id uint32 id
string path string path
where `id' is the request identifier and `path' is the path name of the where `id' is the request identifier and `path' is the path name of
directory to be listed (without any trailing slash). See Section ``File the directory to be listed (without any trailing slash). See Section
Names'' for more information on file names. This will return an error ``File Names'' for more information on file names. This will return
if the path does not specify a directory or if the directory is not an error if the path does not specify a directory or if the directory
readable. The server will respond to this request with either a is not readable. The server will respond to this request with either
SSH_FXP_HANDLE or a SSH_FXP_STATUS message. a SSH_FXP_HANDLE or a SSH_FXP_STATUS message.
Once the directory has been successfully opened, files (and directories) Once the directory has been successfully opened, files (and
contained in it can be listed using SSH_FXP_READDIR requests. These are directories) contained in it can be listed using SSH_FXP_READDIR
of the format requests. These are of the format
uint32 id uint32 id
string handle string handle
where `id' is the request identifier, and `handle' is a handle returned where `id' is the request identifier, and `handle' is a handle
by SSH_FXP_OPENDIR. (It is a protocol error to attempt to use an ordi- returned by SSH_FXP_OPENDIR. (It is a protocol error to attempt to
nary file handle returned by SSH_FXP_OPEN.) use an ordinary file handle returned by SSH_FXP_OPEN.)
The server responds to this request with either a SSH_FXP_NAME or a 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. 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 Full status information is returned for each name in order to speed
typical directory listings. up typical directory listings.
When the client no longer wishes to read more names from the directory, When the client no longer wishes to read more names from the
it SHOULD call SSH_FXP_CLOSE for the handle. The handle should be directory, it SHOULD call SSH_FXP_CLOSE for the handle. The handle
closed regardless of whether an error has occurred or not. should be closed regardless of whether an error has occurred or not.
7.8. Retrieving File Attributes 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 follows SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT
symbolic links on the server, whereas SSH_FXP_LSTAT does not follow follows symbolic links on the server, whereas SSH_FXP_LSTAT does not
symbolic links. Both have the same format: follow symbolic links. Both have the same format:
uint32 id uint32 id
string path string path
where `id' is the request identifier, and `path' spefifies the file sys- where `id' is the request identifier, and `path' specifies the file
tem object for which status is to be returned. The server responds to system object for which status is to be returned. The server
this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS. responds to this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS.
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). Its
format is as follows: format is as follows:
uint32 id uint32 id
string handle string handle
where `id' is the request identifier and `handle' is a file handle where `id' is the request identifier and `handle' is a file handle
returned by SSH_FXP_OPEN. The server responds to this request with returned by SSH_FXP_OPEN. The server responds to this request with
SSH_FXP_ATTRS or SSH_FXP_STATUS. SSH_FXP_ATTRS or SSH_FXP_STATUS.
7.9. Setting File Attributes 6.9 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 such SSH_FXP_FSETSTAT requests. These requests are used for operations
as changing the ownership, permissions or access times, as well as for such as changing the ownership, permissions or access times, as well
truncating a file. as for truncating a file.
The SSH_FXP_SETSTAT request is of the following format: The SSH_FXP_SETSTAT request is of the following format:
uint32 id uint32 id
string path string path
ATTRS attrs ATTRS attrs
where `id' is the request identifier, `path' specifies the file system where `id' is the request identifier, `path' specifies the file
object (e.g. file or directory) whose attributes are to be modified, and system object (e.g. file or directory) whose attributes are to be
`attrs' specifies the modifications to be made to its attributes. modified, and `attrs' specifies the modifications to be made to its
Attributes are discussed in more detail in Section ``File Attributes''. attributes. Attributes are discussed in more detail in Section
``File Attributes''.
An error will be returned if the specified file system object does not An error will be returned if the specified file system object does
exist or the user does not have sufficient rights to modify the not exist or the user does not have sufficient rights to modify the
specified attributes. The server responds to this request with a specified attributes. The server responds to this request with a
SSH_FXP_STATUS message. SSH_FXP_STATUS message.
The SSH_FXP_FSETSTAT request modifies the attributes of a file which is The SSH_FXP_FSETSTAT request modifies the attributes of a file which
already open. It has the following format: is already open. It has the following format:
uint32 id uint32 id
string handle string handle
ATTRS attrs ATTRS attrs
where `id' is the request identifier, `handle' (MUST be returned by where `id' is the request identifier, `handle' (MUST be returned by
SSH_FXP_OPEN) identifies the file whose attributes are to be modified, SSH_FXP_OPEN) identifies the file whose attributes are to be
and `attrs' specifies the modifications to be made to its attributes. modified, and `attrs' specifies the modifications to be made to its
Attributes are discussed in more detail in Section ``File Attributes''. attributes. Attributes are discussed in more detail in Section
The server will respond to this request with SSH_FXP_STATUS. ``File Attributes''. The server will respond to this request with
SSH_FXP_STATUS.
7.10. Dealing with Symbolic links 6.10 Dealing with Symbolic links
The SSH_FXP_READLINK request may be used to read the target of a The SSH_FXP_READLINK request may be used to read the target of a
symbolic link. It would have a data part as follows: symbolic link. It would have a data part as follows:
uint32 id uint32 id
string path string path
where `id' is the request identifier and `path' specifies the path name where `id' is the request identifier and `path' specifies the path
of the symlink to be read. name of the symlink to be read.
The server will respond with a SSH_FXP_NAME packet containing only one The server will respond with a SSH_FXP_NAME packet containing only
name and a dummy attributes value. The name in the returned packet one name and a dummy attributes value. The name in the returned
contains the target of the link. If an error occurs, the server may packet contains the target of the link. If an error occurs, the
respond with SSH_FXP_STATUS. server may respond with SSH_FXP_STATUS.
The SSH_FXP_SYMLINK request will create a symbolic link on the server. The SSH_FXP_SYMLINK request will create a symbolic link on the
It is of the following format server. It is of the following format
uint32 id uint32 id
string linkpath string linkpath
string targetpath string targetpath
where `id' is the request identifier, `linkpath' specifies the path name where `id' is the request identifier, `linkpath' specifies the path
of the symlink to be created and `targetpath' specifies the target of name of the symlink to be created and `targetpath' specifies the
the symlink. The server shall respond with a SSH_FXP_STATUS indicating target of the symlink. The server shall respond with a
either success (SSH_FX_OK) or an error condition. SSH_FXP_STATUS indicating either success (SSH_FX_OK) or an error
condition.
7.11. Canonicalizing the Server-Side Path Name 6.11 Canonicalizing the Server-Side Path Name
The SSH_FXP_REALPATH request can be used to have the server canonicalize The SSH_FXP_REALPATH request can be used to have the server
any given path name to an absolute path. This is useful for converting canonicalize any given path name to an absolute path. This is useful
path names containing ".." components or relative pathnames without a for converting path names containing ".." components or relative
leading slash into absolute paths. The format of the request is as pathnames without a leading slash into absolute paths. The format of
follows: the request is as follows:
uint32 id uint32 id
string path string path
where `id' is the request identifier and `path' specifies the path name where `id' is the request identifier and `path' specifies the path
to be canonicalized. The server will respond with a SSH_FXP_NAME packet name to be canonicalized. The server will respond with a
containing only one name and a dummy attributes value. The name is the SSH_FXP_NAME packet containing only one name and a dummy attributes
returned packet will be in canonical form. If an error occurs, the value. The name is the returned packet will be in canonical form.
server may also respond with SSH_FXP_STATUS.
If an error occurs, the server may also respond with SSH_FXP_STATUS.
7. Responses from the Server to the Client
The server responds to the client using one of a few response
packets. All requests can return a SSH_FXP_STATUS response upon
failure. When the operation is successful, any of the responses may
be returned (depending on the operation). If no data needs to be
returned to the client, the SSH_FXP_STATUS response with SSH_FX_OK
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
response packet contains a request identifier which can be used to
match each response with the corresponding request. Note that it is
legal to have several requests outstanding simultaneously, and the
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
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).
Response packets are of the same general format as request packets.
Each response packet begins with the request identifier.
The format of the data portion of the SSH_FXP_STATUS response is as
follows:
uint32 id
uint32 error/status code
string error message (ISO-10646 UTF-8 [RFC-2279])
string language tag (as defined in [RFC-1766])
where `id' is the request identifier, and `error/status code'
indicates the result of the requested operation. The value SSH_FX_OK
indicates success, and all other values indicate failure.
Currently, the following values are defined (other values may be
defined by future versions of this protocol):
#define SSH_FX_OK 0
#define SSH_FX_EOF 1
#define SSH_FX_NO_SUCH_FILE 2
#define SSH_FX_PERMISSION_DENIED 3
#define SSH_FX_FAILURE 4
#define SSH_FX_BAD_MESSAGE 5
#define SSH_FX_NO_CONNECTION 6
#define SSH_FX_CONNECTION_LOST 7
#define SSH_FX_OP_UNSUPPORTED 8
SSH_FX_OK
Indicates successful completion of the operation.
SSH_FX_EOF
indicates end-of-file condition; for SSH_FX_READ it means that no
more data is available in the file, and for SSH_FX_READDIR it
indicates that no more files are contained in the directory.
SSH_FX_NO_SUCH_FILE
is returned when a reference is made to a file which should exist
but doesn't.
SSH_FX_PERMISSION_DENIED
is returned when the authenticated user does not have sufficient
permissions to perform the operation.
SSH_FX_FAILURE
is a generic catch-all error message; it should be returned if an
error occurs for which there is no more specific error code
defined.
SSH_FX_BAD_MESSAGE
may be returned if a badly formatted packet or protocol
incompatibility is detected.
SSH_FX_NO_CONNECTION
is a pseudo-error which indicates that the client has no
connection to the server (it can only be generated locally by the
client, and MUST NOT be returned by servers).
SSH_FX_CONNECTION_LOST
is a pseudo-error which indicates that the connection to the
server has been lost (it can only be generated locally by the
client, and MUST NOT be returned by servers).
SSH_FX_OP_UNSUPPORTED
indicates that an attempt was made to perform an operation which
is not supported for the server (it may be generated locally by
the client if e.g. the version number exchange indicates that a
required feature is not supported by the server, or it may be
returned by the server if the server does not implement an
operation).
The SSH_FXP_HANDLE response has the following format:
uint32 id
string handle
where `id' is the request identifier, and `handle' is an arbitrary
string that identifies an open file or directory on the server. The
handle is opaque to the client; the client MUST NOT attempt to
interpret or modify it in any way. The length of the handle string
MUST NOT exceed 256 data bytes.
The SSH_FXP_DATA response has the following format:
uint32 id
string data
where `id' is the request identifier, and `data' is an arbitrary byte
string containing the requested data. The data string may be at most
the number of bytes requested in a SSH_FXP_READ request, but may also
be shorter if end of file is reached or if the read is from something
other than a regular file.
The SSH_FXP_NAME response has the following format:
uint32 id
uint32 count
repeats count times:
string filename
string longname
ATTRS attrs
where `id' is the request identifier, `count' is the number of names
returned in this response, and the remaining fields repeat `count'
times (so that all three fields are first included for the first
file, then for the second file, etc). In the repeated part,
`filename' is a file name being returned (for SSH_FXP_READDIR, it
will be a relative name within the directory, without any path
components; for SSH_FXP_REALPATH it will be an absolute path name),
`longname' is an expanded format for the file name, similar to what
is returned by "ls -l" on Unix systems, and `attrs' is the attributes
of the file as described in Section ``File Attributes''.
The format of the `longname' field is unspecified by this protocol.
It MUST be suitable for use in the output of a directory listing
command (in fact, the recommended operation for a directory listing
command is to simply display this data). However, clients SHOULD NOT
attempt to parse the longname field for file attributes; they SHOULD
use the attrs field instead.
The recommended format for the longname field is as follows:
-rwxr-xr-x 1 mjos staff 348911 Mar 25 14:29 t-filexfer
1234567890 123 12345678 12345678 12345678 123456789012
Here, the first line is sample output, and the second field indicates
widths of the various fields. Fields are separated by spaces. The
first field lists file permissions for user, group, and others; the
second field is link count; the third field is the name of the user
who owns the file; the fourth field is the name of the group that
owns the file; the fifth field is the size of the file in bytes; the
sixth field (which actually may contain spaces, but is fixed to 12
characters) is the file modification time, and the seventh field is
the file name. Each field is specified to be a minimum of certain
number of character positions (indicated by the second line above),
but may also be longer if the data does not fit in the specified
length.
The SSH_FXP_ATTRS response has the following format:
uint32 id
ATTRS attrs
where `id' is the request identifier, and `attrs' is the returned
file attributes as described in Section ``File Attributes''.
8. Vendor-Specific Extensions 8. Vendor-Specific Extensions
The SSH_FXP_EXTENDED request provides a generic extension mechanism for The SSH_FXP_EXTENDED request provides a generic extension mechanism
adding vendor-specific commands. The request has the following format: for adding vendor-specific commands. The request has the following
format:
uint32 id uint32 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 string where `id' is the request identifier, and `extended-request' is a
of the format "name@domain", where domain is an internet domain name of string of the format "name@domain", where domain is an internet
the vendor defining the request. The rest of the request is completely domain name of the vendor defining the request. The rest of the
vendor-specific, and servers should only attempt to interpret it if they request is completely vendor-specific, and servers should only
recognize the `extended-request' name. 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 Client''. packets defined in Section ``Responses from the Server to the
Additionally, the server may also respond with a SSH_FXP_EXTENDED_REPLY Client''. Additionally, the server may also respond with a
packet, as defined below. If the server does not recognize the SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does
not recognize the `extended-request' name, then the server MUST
`extended-request' name, then the server MUST respond with respond with SSH_FXP_STATUS with error/status set to
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 uint32 id
... any request-specific data ... ... any request-specific data ...
9. Security Considerations 9. Security Considerations
This protocol assumes that it is run over a secure channel and that the This protocol assumes that it is run over a secure channel and that
endpoints of the channel have been authenticated. Thus, this protocol the endpoints of the channel have been authenticated. Thus, this
assumes that it is externally protected from network-level attacks. protocol assumes that it is externally protected from network-level
attacks.
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 Secure Shell User Authentication Protocol protocol, typically using the SSH User Authentication Protocol [6].
[SECSH-USERAUTH].
Care must be taken in the server implementation to check the validity of Care must be taken in the server implementation to check the validity
received file handle strings. The server should not rely on them of received file handle strings. The server should not rely on them
directly; it MUST check the validity of each handle before relying on directly; it MUST check the validity of each handle before relying on
it. it.
10. Changes from previous protocol versions 10. Changes from previous protocol versions
The Secure Shell File Transfer Protocol has changed over time, before The SSH File Transfer Protocol has changed over time, before it's
it's standardization. The following is a description of the standardization. The following is a description of the incompatible
incompatible changes between different versions. changes between different versions.
10.1. Changes between versions 3 and 2 10.1 Changes between versions 3 and 2
o The SSH_FXP_READLINK and SSH_FXP_SYMLINK mesages 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 added. o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were
added.
o The SSH_FXP_STATUS message was changed to include fields `error o The SSH_FXP_STATUS message was changed to include fields `error
message' and `language tag'. message' and `language tag'.
10.2. Changes between versions 2 and 1 10.2 Changes between versions 2 and 1
o The SSH_FXP_RENAME message was added. o The SSH_FXP_RENAME message was added.
10.3. Changes between versions 1 and 0 10.3 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 in "ssh" is a registered trademark of SSH Communications Security Corp
the United States and/or other countries. in the United States and/or other countries.
12. References References
[RFC-2246] Dierks, T. and Allen, C.: "The TLS Protocol Version 1.0", [1] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
January 1999 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999.
[POSIX] ISO/IEC Std 9945-1, ANSI/IEEE Std 1003.1 Information technology [2] Institute of Electrical and Electronics Engineers, "Information
Application Program Interface (API) [C Language], July 1996. Technology - Portable Operating System Interface (POSIX) - Part
1: System Application Program Interface (API) [C Language]",
IEEE Standard 1003.2, 1996.
[SECSH-ARCH] Ylonen, T., et al: "Secure Shell Protocol Architecture", [3] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
Internet-Draft, draft-ietf-secsh-architecture-08.txt Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh-
architecture-09 (work in progress), July 2001.
[SECSH-TRANSPORT] Ylonen, T., et al: "Secure Shell Transport Protocol", [4] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
Internet-Draft, draft-ietf-secsh-transport-10.txt Lehtinen, "SSH Protocol Transport Protocol", draft-ietf-secsh-
architecture-09 (work in progress), July 2001.
[SECSH-USERAUTH] Ylonen, T., et al: "Secure Shell Authentication [5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
Protocol", Internet-Draft, draft-ietf-secsh-userauth-10.txt Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-11
(work in progress), July 2001.
[SECSH-CONNECT] Ylonen, T., et al: "Secure Shell Connection Protocol", [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
Internet-Draft, draft-ietf-secsh-connect-10.txt Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh-
userauth-11 (work in progress), July 2001.
13. Authors' Addresses Authors' Addresses
Tatu Ylonen Tatu Ylonen
SSH Communications Security Corp SSH Communications Security Corp
Fredrikinkatu 42 Fredrikinkatu 42
FIN-00100 HELSINKI HELSINKI FIN-00100
Finland Finland
E-mail: ylo@ssh.com
EMail: ylo@ssh.com
Sami Lehtinen Sami Lehtinen
SSH Communications Security Corp SSH Communications Security Corp
Fredrikinkatu 42 Fredrikinkatu 42
FIN-00100 HELSINKI HELSINKI FIN-00100
Finland Finland
E-mail: sjl@ssh.com
EMail: sjl@ssh.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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