draft-ietf-secsh-filexfer-00.txt | draft-ietf-secsh-filexfer-01.txt | |||
---|---|---|---|---|
Network Working Group T. Ylonen and S. Lehtinen | Network Working Group T. Ylonen and S. Lehtinen | |||
INTERNET-DRAFT SSH Communications Security | INTERNET-DRAFT SSH Communications Security | |||
Expires: 9 July, 2001 | Expires: 2 September, 2001 | |||
SSH File Transfer Protocol | Secure Shell File Transfer Protocol | |||
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 all provisions of Section 10 of RFC2026. | with 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-Drafts. | Internet-Drafts. | |||
skipping to change at page 1, line 33 | skipping to change at page 1, line 33 | |||
"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://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
Abstract | Abstract | |||
The SSH File Transfer Protocol provides secure file transfer functional- | The Secure Shell File Transfer Protocol provides secure file transfer | |||
ity over any reliable data stream. It is the standard file transfer | functionality over any reliable data stream. It is the standard file | |||
protocol for use with the SSH2 protocol. This document describes the | transfer protocol for use with the Secure Shell Remote Login Protocol. | |||
file transfer protocol and its interface to the SSH2 protocol suite. | This document describes the file transfer protocol and its interface to | |||
the Secure Shell protocol suite. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Use with the SSH Connection Protocol . . . . . . . . . . . . . . 3 | 2. Use with the Secure Shell Connection Protocol . . . . . . . . . 3 | |||
3. General Packet Format . . . . . . . . . . . . . . . . . . . . . 3 | 3. General Packet Format . . . . . . . . . . . . . . . . . . . . . 3 | |||
4. Protocol Initialization . . . . . . . . . . . . . . . . . . . . 4 | 4. Protocol Initialization . . . . . . . . . . . . . . . . . . . . 4 | |||
5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . . 5 | 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
6. Requests From the Client to the Server . . . . . . . . . . . . . 6 | 6. Responses from the Server to the Client . . . . . . . . . . . . 6 | |||
6.1. Request Synchronization and Reordering . . . . . . . . . . . 7 | 7. Requests From the Client to the Server . . . . . . . . . . . . . 9 | |||
6.2. File Names . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 7.1. Request Synchronization and Reordering . . . . . . . . . . . 10 | |||
6.3. Opening, Creating, and Closing Files . . . . . . . . . . . . 8 | 7.2. File Names . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
6.4. Reading and Writing . . . . . . . . . . . . . . . . . . . . 9 | 7.3. Opening, Creating, and Closing Files . . . . . . . . . . . . 11 | |||
6.5. Removing and Renaming Files . . . . . . . . . . . . . . . . 10 | 7.4. Reading and Writing . . . . . . . . . . . . . . . . . . . . 12 | |||
6.6. Creating and Deleting Directories . . . . . . . . . . . . . 10 | 7.5. Removing and Renaming Files . . . . . . . . . . . . . . . . 13 | |||
6.7. Scanning Directories . . . . . . . . . . . . . . . . . . . . 11 | 7.6. Creating and Deleting Directories . . . . . . . . . . . . . 14 | |||
6.8. Retrieving File Attributes . . . . . . . . . . . . . . . . . 12 | 7.7. Scanning Directories . . . . . . . . . . . . . . . . . . . . 14 | |||
6.9. Setting File Attributes . . . . . . . . . . . . . . . . . . 12 | 7.8. Retrieving File Attributes . . . . . . . . . . . . . . . . . 15 | |||
6.10. Canonicalizing the Server-Side Path Name . . . . . . . . . 13 | 7.9. Setting File Attributes . . . . . . . . . . . . . . . . . . 16 | |||
7. Responses from the Server to the Client . . . . . . . . . . . . 13 | 7.10. Dealing with Symbolic links . . . . . . . . . . . . . . . . 16 | |||
8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . . . 16 | 7.11. Canonicalizing the Server-Side Path Name . . . . . . . . . 17 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 17 | 8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . . . 17 | |||
10. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 17 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 18 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 10. Changes from previous protocol versions . . . . . . . . . . . . 18 | |||
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 | 10.1. Changes between versions 3 and 2 . . . . . . . . . . . . . 18 | |||
10.2. Changes between versions 2 and 1 . . . . . . . . . . . . . 18 | ||||
10.3. Changes between versions 1 and 0 . . . . . . . . . . . . . 18 | ||||
11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 18 | ||||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | ||||
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 | ||||
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 SSH2 protocol [SSH-ARCH]. | channel in the Secure Shell Remote Login Protocol [SECSH-ARCH]. | |||
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 secure | |||
remote file system service, as well as a secure file transfer service. | 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 the | |||
server has already authenticated the user at the client end, and that | server has already authenticated the user at the client end, and that | |||
the identity of the client user is externally available to the server | the identity of the client user is externally available to the server | |||
implementation. | implementation. | |||
In general, this protocol follows a simple request-response model. Each | In general, this protocol follows a simple request-response model. Each | |||
request and response contains a sequence number and multiple requests | request and response contains a sequence number and multiple requests | |||
may be pending simultaneously. There are a relatively large number of | may be pending simultaneously. There are a relatively large number of | |||
different request messages, but a small number of possible response | different request messages, but a small number of possible response | |||
messages. Each request has one or more response messages that may be | messages. Each request has one or more response messages that may be | |||
returned in result (e.g., a read either returns data or reports error | returned in result (e.g., a read either returns data or reports error | |||
status). | status). | |||
The packet format descriptions in this specification follow the notation | The packet format descriptions in this specification follow the notation | |||
presented in [SSH-ARCH]. | presented in [SECSH-ARCH]. | |||
Even though this protocol is described in the context of the SSH2 | ||||
protocol, this protocol is general and independent of the rest of the | Even though this protocol is described in the context of the Secure | |||
SSH2 protocol suite. It could be used in a number of different | Shell Remote Login Protocol, this protocol is general and independent of | |||
applications, such as secure file transfer over TLS [RFC-2246] and | the rest of the Secure Shell protocol suite. It could be used in a | |||
transfer of management information in VPN applications. | number of different applications, such as secure file transfer over TLS | |||
[RFC-2246] and transfer of management information in VPN applications. | ||||
2. Use with the SSH Connection Protocol | 2. Use with the Secure Shell Connection Protocol | |||
When used with the SSH2 Protocol suite, this protocol is intended to be | When used with the Secure Shell protocol suite, this protocol is | |||
used from the SSH Connection Protocol as a subsystem, as described in | intended to be used from the Secure Shell Connection Protocol as a | |||
[SSH-CONN], Section ``Starting a Shell or a Command''. The subsystem | subsystem, as described in [SECSH-CONN], Section ``Starting a Shell or a | |||
name used with this protocol is "sftp". | Command''. The 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 following | |||
format: | format: | |||
uint32 length | uint32 length | |||
byte type | byte type | |||
byte[length - 1] data payload | byte[length - 1] data payload | |||
skipping to change at page 4, line 18 | skipping to change at page 4, line 23 | |||
#define SSH_FXP_SETSTAT 9 | #define SSH_FXP_SETSTAT 9 | |||
#define SSH_FXP_FSETSTAT 10 | #define SSH_FXP_FSETSTAT 10 | |||
#define SSH_FXP_OPENDIR 11 | #define SSH_FXP_OPENDIR 11 | |||
#define SSH_FXP_READDIR 12 | #define SSH_FXP_READDIR 12 | |||
#define SSH_FXP_REMOVE 13 | #define SSH_FXP_REMOVE 13 | |||
#define SSH_FXP_MKDIR 14 | #define SSH_FXP_MKDIR 14 | |||
#define SSH_FXP_RMDIR 15 | #define SSH_FXP_RMDIR 15 | |||
#define SSH_FXP_REALPATH 16 | #define SSH_FXP_REALPATH 16 | |||
#define SSH_FXP_STAT 17 | #define SSH_FXP_STAT 17 | |||
#define SSH_FXP_RENAME 18 | #define SSH_FXP_RENAME 18 | |||
#define SSH_FXP_READLINK 19 | ||||
#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 version | |||
number (see Section ``Protocol Initialization'') is incremented, and | number (see Section ``Protocol Initialization'') is incremented, and | |||
skipping to change at page 5, line 53 | skipping to change at page 6, line 4 | |||
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 for | |||
which the corresponding flag is not set are not present (not included in | which the corresponding flag is not set are not present (not included in | |||
the packet). New flags can only be added by incrementing the protocol | the packet). New flags can only be added by incrementing the protocol | |||
version number (or by using the extension mechanism described below). | version number (or by using the extension mechanism 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]. | |||
The `atime' and `mtime' contain the access and modification times of the | The `atime' and `mtime' contain the access and modification times of the | |||
files, respectively. They are represented as seconds from Jan 1, 1970. | files, respectively. They are represented as seconds from Jan 1, 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 of | |||
extended_type-extended_data pairs that follow. Each of these pairs | extended_type-extended_data pairs that follow. Each of these pairs | |||
specifies an extended attribute. For each of the attributes, the | specifies an extended attribute. For each of the attributes, the | |||
extended_type field should be a string of the format "name@domain", | extended_type field should be a string of the format "name@domain", | |||
where "domain" is a valid, registered domain name and "name" identifies | where "domain" is a valid, registered domain name and "name" identifies | |||
the method. The IETF may later standardize certain names that deviate | the method. The IETF may later standardize certain names that deviate | |||
from this format (e.g., that do not contain the "@" sign). The | from this format (e.g., that do not contain the "@" sign). The | |||
skipping to change at page 6, line 42 | skipping to change at page 6, line 48 | |||
if a packet with unsupported protocol bits is received. | 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. Requests From the Client to the Server | 6. 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 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 | 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 | operations. Each request begins with an `id' field, which is a 32-bit | |||
identifier identifying the request (selected by the client). The same | identifier identifying the request (selected by the client). The same | |||
identifier will be returned in the response to the request. One | identifier will be returned in the response to the request. One | |||
possible implementation of it is a monotonically increasing request | possible implementation of it is a monotonically increasing request | |||
sequence number (modulo 2^32). | 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 SSH_FXP_OPEN | |||
request can return a file handle (which is an opaque variable-length | 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 | 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 | operation). The client MUST NOT send requests the server with bogus or | |||
skipping to change at page 7, line 13 | skipping to change at page 10, line 26 | |||
handle in order to avoid security risks due to fabricated handles. | 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 implementation, | |||
as well as an implementation which caches state between requests but may | 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 | 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 the server and its design. The client should not modify or attempt | |||
to interpret the file handle strings. | 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. | |||
6.1. Request Synchronization and Reordering | 7.1. Request Synchronization and Reordering | |||
The protocol and implementations MUST process requests relating to the | The protocol and implementations MUST process requests relating to the | |||
same file in the order in which they are received. In other words, if | 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 | 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 | 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 | 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 | may process non-overlapping read/write requests to the same file in | |||
parallel, but overlapping reads and writes cannot be reordered or | parallel, but overlapping reads and writes cannot be reordered or | |||
parallelized. However, there are no ordering restrictions on the server | parallelized. However, there are no ordering restrictions on the server | |||
for processing requests from two different file transfer connections. | for processing requests from two different file transfer connections. | |||
The server may interleave and parallelize them at will. | The server may interleave and parallelize them at will. | |||
There are no restrictions on the order in which responses to outstanding | There are no restrictions on the order in which responses to outstanding | |||
requests are delivered to the client, except that the server must ensure | requests are delivered to the client, except that the server must ensure | |||
fairness in the sense that processing of no request will be indefinitely | 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 | delayed even if the client is sending other requests so that there are | |||
multiple outstanding requests all the time. | multiple outstanding requests all the time. | |||
6.2. File Names | 7.2. File Names | |||
This protocol represents file names as strings. File names are assumed | This protocol represents file names as strings. File names are assumed | |||
to use the slash ('/') character as a directory separator. | to use the slash ('/') character as a directory separator. | |||
File names starting with a slash are "absolute", and are relative to the | File names starting with a slash are "absolute", and are relative to the | |||
root of the file system. Names starting with any other character are | root of the file system. Names starting with any other character are | |||
relative to the user's default directory (home directory). Note that | relative to the user's default directory (home directory). Note that | |||
identifying the user is assumed to take place outside of this protocol. | identifying the user is assumed to take place outside of this protocol. | |||
Servers SHOULD interpret a path name component ".." as referring to the | Servers SHOULD interpret a path name component ".." as referring to the | |||
skipping to change at page 8, line 4 | skipping to change at page 11, line 18 | |||
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 splice | |||
path name components returned by SSH_FXP_READDIR together using a slash | path name components returned by SSH_FXP_READDIR together using a slash | |||
('/') as the separator, and that will work as expected. | ('/') 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 names | |||
may cause interoperability problems between clients and servers using | may cause interoperability problems between clients and servers using | |||
radically different operating systems. However, this approach is known | radically different operating systems. However, this approach is known | |||
to work acceptably with most systems, and alternative approaches that | to work acceptably with most systems, and alternative approaches that | |||
e.g. treat file names as sequences of structured components are quite | e.g. treat file names as sequences of structured components are quite | |||
complicated. | complicated. | |||
6.3. Opening, Creating, and Closing Files | 7.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 data | |||
part is as follows: | 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. | |||
skipping to change at page 9, line 27 | skipping to change at page 12, line 40 | |||
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 has | |||
the following format: | 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 previ- | |||
ously returned in the response to SSH_FXP_OPEN or SSH_FXP_OPENDIR. The | ously returned in the response to SSH_FXP_OPEN or SSH_FXP_OPENDIR. The | |||
handle becomes invalid immediately after this request has been sent. | 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. This | |||
can happen e.g. if the server operating system caches writes, and an | can happen e.g. if the server operating system caches writes, and an | |||
error occurs while flushing cached writes during the close. | error occurs while flushing cached writes during the close. | |||
6.4. Reading and Writing | 7.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 | |||
skipping to change at page 10, line 22 | skipping to change at page 13, line 37 | |||
the file where to start writing, and `data' is the data to be written. | 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 are | |||
to write zeroes from the end of the file to the specified offset and | to write zeroes from the end of the file to the specified offset and | |||
then the data. On most operating systems, such writes do not allocate | then the data. On most operating systems, such writes do not allocate | |||
disk space but instead leave "holes" in the file. | 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. | |||
6.5. Removing and Renaming Files | 7.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 the | |||
file to be removed. See Section ``File Names'' for more information. | file to be removed. See Section ``File Names'' for more information. | |||
This request cannot be used to remove directories. | This request cannot be used to remove directories. | |||
skipping to change at page 10, line 52 | skipping to change at page 14, line 14 | |||
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 exist- | |||
ing file or directory, and `newpath' is the new name for the file or | ing file or directory, and `newpath' is the new name for the file or | |||
directory. It is an error if there already exists a file with the name | directory. It is an error if there already exists a file with the name | |||
specified by newpath. The server may also fail rename requests in other | specified by newpath. The server may also fail rename requests in other | |||
situations, for example if `oldpath' and `newpath' point to different | situations, for example if `oldpath' and `newpath' point to different | |||
file systems on the server. | 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. | |||
6.6. Creating and Deleting Directories | 7.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 has | |||
the following format: | the following format: | |||
uint32 id | uint32 id | |||
string path | string path | |||
ATTRS attrs | ||||
where `id' is the request identifier and `path' specifies the directory | where `id' is the request identifier, `path'and `attrs' specifies the | |||
to be created. See Section ``File Names'' for more information on file | modifications to be made to its attributes. See Section ``File Names'' | |||
names. An error will be returned if a file or directory with the speci- | for more information on file names. Attributes are discussed in more | |||
fied path already exists. The server will respond to this request with | detail in Section ``File Attributes''. specifies the directory to be | |||
a SSH_FXP_STATUS message. | created. An error will be returned if a file or directory with the | |||
specified path already exists. The server will respond to this request | ||||
with a SSH_FXP_STATUS message. | ||||
Directories can be removed using the SSH_FXP_RMDIR request, which has | Directories can be removed using the SSH_FXP_RMDIR request, which has | |||
the following format: | 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 directory | |||
to be removed. See Section ``File Names'' for more information on file | to be removed. See Section ``File Names'' for more information on file | |||
names. An error will be returned if no directory with the specified | names. An error will be returned if no directory with the specified | |||
path exists, or if the specified directory is not empty, or if the path | path exists, or if the specified directory is not empty, or if the path | |||
specified a file system object other than a directory. The server | specified a file system object other than a directory. The server | |||
responds to this request with a SSH_FXP_STATUS message. | responds to this request with a SSH_FXP_STATUS message. | |||
6.7. Scanning Directories | 7.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 or | |||
more file names with full file attributes for each file. The client | 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 | 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 | 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 | 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 | the directory). The client should then close the handle using the | |||
SSH_FXP_CLOSE request. | SSH_FXP_CLOSE request. | |||
skipping to change at page 12, line 17 | skipping to change at page 15, line 35 | |||
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 up | |||
typical directory listings. | 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 directory, | |||
it SHOULD call SSH_FXP_CLOSE for the handle. The handle should be | it SHOULD call SSH_FXP_CLOSE for the handle. The handle should be | |||
closed regardless of whether an error has occurred or not. | closed regardless of whether an error has occurred or not. | |||
6.8. Retrieving File Attributes | 7.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 follows | |||
symbolic links on the server, whereas SSH_FXP_LSTAT does not follow | symbolic links on the server, whereas SSH_FXP_LSTAT does not follow | |||
symbolic links. Both have the same format: | symbolic links. Both have the same format: | |||
skipping to change at page 12, line 46 | skipping to change at page 16, line 10 | |||
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. | |||
6.9. Setting File Attributes | 7.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 such | |||
as changing the ownership, permissions or access times, as well as for | as changing the ownership, permissions or access times, as well as for | |||
truncating a file. | 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 | |||
skipping to change at page 13, line 28 | skipping to change at page 16, line 46 | |||
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 modified, | |||
and `attrs' specifies the modifications to be made to its attributes. | and `attrs' specifies the modifications to be made to its attributes. | |||
Attributes are discussed in more detail in Section ``File Attributes''. | Attributes are discussed in more detail in Section ``File Attributes''. | |||
The server will respond to this request with SSH_FXP_STATUS. | The server will respond to this request with SSH_FXP_STATUS. | |||
6.10. Canonicalizing the Server-Side Path Name | 7.10. Dealing with Symbolic links | |||
The SSH_FXP_REALPATH request can be used to have the server canonicalize | The SSH_FXP_READLINK request may be used to read the target of a | |||
any given path name to an absolute path. This is useful for converting | symbolic link. It would have a data part as follows: | |||
path names containing ".." components or relative pathnames without a | ||||
leading slash into absolute paths. The format of 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 name | |||
to be canonicalized. The server will respond with a SSH_FXP_NAME packet | of the symlink to be read. | |||
containing only one name and a dummy attributes value. The name is the | ||||
returned packet will be in canonical form. 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 | ||||
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 | The server will respond with a SSH_FXP_NAME packet containing only one | |||
string containing the requested data. The data string may be at most | name and a dummy attributes value. The name in the returned packet | |||
the number of bytes requested in a SSH_FXP_READ request, but may also be | contains the target of the link. If an error occurs, the server may | |||
shorter if end of file is reached or if the read is from something other | respond with SSH_FXP_STATUS. | |||
than a regular file. | ||||
The SSH_FXP_NAME response has the following format: | The SSH_FXP_SYMLINK request will create a symbolic link on the server. | |||
It is of the following format | ||||
uint32 id | uint32 id | |||
uint32 count | string linkpath | |||
repeats count times: | string targetpath | |||
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 | where `id' is the request identifier, `linkpath' specifies the path name | |||
1234567890 123 12345678 12345678 12345678 123456789012 | of the symlink to be created and `targetpath' specifies the target of | |||
the symlink. The server shall respond with a SSH_FXP_STATUS indicating | ||||
either success (SSH_FX_OK) or an error condition. | ||||
Here, the first line is sample output, and the second field indicates | 7.11. Canonicalizing the Server-Side Path Name | |||
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 file 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: | The SSH_FXP_REALPATH request can be used to have the server canonicalize | |||
any given path name to an absolute path. This is useful for converting | ||||
path names containing ".." components or relative pathnames without a | ||||
leading slash into absolute paths. The format of the request is as | ||||
follows: | ||||
uint32 id | uint32 id | |||
ATTRS attrs | string path | |||
where `id' is the request identifier, and `attrs' is the returned file | where `id' is the request identifier and `path' specifies the path name | |||
attributes as described in Section ``File Attributes''. | to be canonicalized. The server will respond with a SSH_FXP_NAME packet | |||
containing only one name and a dummy attributes value. The name is the | ||||
returned packet will be in canonical form. If an error occurs, the | ||||
server may also respond with SSH_FXP_STATUS. | ||||
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 for | |||
adding vendor-specific commands. The request has the following format: | 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 ... | |||
skipping to change at page 17, line 35 | skipping to change at page 18, line 26 | |||
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 the | |||
endpoints of the channel have been authenticated. Thus, this protocol | endpoints of the channel have been authenticated. Thus, this protocol | |||
assumes that it is externally protected from network-level attacks. | 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 SSH User Authentication Protocol [SSH- | protocol, typically using the Secure Shell User Authentication Protocol | |||
USERAUTH]. | [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 of | |||
received file handle strings. The server should not rely on them | 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. Trademark Issues | 10. Changes from previous protocol versions | |||
SSH is a registered trademark and Secure Shell is a trademark of SSH | The Secure Shell File Transfer Protocol has changed over time, before | |||
Communications Security Corp. SSH Communications Security Corp permits | it's standardization. The following is a description of the | |||
the use of these trademarks as the name of this standard and protocol, | incompatible changes between different versions. | |||
and permits their use to describe that a product conforms to this | ||||
standard, provided that the following acknowledgement is included where | ||||
the trademarks are used: ``SSH is a registered trademark and Secure | ||||
Shell is a trademark of SSH Communications Security Corp | ||||
(www.ssh.com)''. These trademarks may not be used as part of a product | ||||
name or in otherwise confusing manner without prior written permission | ||||
of SSH Communications Security Corp. | ||||
11. References | 10.1. Changes between versions 3 and 2 | |||
o The SSH_FXP_READLINK and SSH_FXP_SYMLINK mesages were added. | ||||
o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were added. | ||||
o The SSH_FXP_STATUS message was changed to include fields `error | ||||
message' and `language tag'. | ||||
10.2. Changes between versions 2 and 1 | ||||
o The SSH_FXP_RENAME message was added. | ||||
10.3. Changes between versions 1 and 0 | ||||
o Implementation changes, no actual protocol changes. | ||||
11. Trademark Issues | ||||
"ssh" is a registered trademark of SSH Communications Security Corp in | ||||
the United States and/or other countries. | ||||
12. References | ||||
[RFC-2246] Dierks, T. and Allen, C.: "The TLS Protocol Version 1.0", | [RFC-2246] Dierks, T. and Allen, C.: "The TLS Protocol Version 1.0", | |||
January 1999 | January 1999 | |||
[POSIX] ISO/IEC Std 9945-1, ANSI/IEEE Std 1003.1 Information technology | [POSIX] ISO/IEC Std 9945-1, ANSI/IEEE Std 1003.1 Information technology | |||
-- Portable Operating System Interface (POSIX)-Part 1: System | -- Portable Operating System Interface (POSIX)-Part 1: System | |||
Application Program Interface (API) [C Language], July 1996. | Application Program Interface (API) [C Language], July 1996. | |||
[SSH-ARCH] Ylonen, T., et al: "SSH Protocol Architecture", Internet- | [SECSH-ARCH] Ylonen, T., et al: "Secure Shell Protocol Architecture", | |||
Draft, draft-ietf-secsh-architecture-07.txt | Internet-Draft, draft-ietf-secsh-architecture-08.txt | |||
[SSH-TRANSPORT] Ylonen, T., et al: "SSH Transport Protocol", Internet- | [SECSH-TRANSPORT] Ylonen, T., et al: "Secure Shell Transport Protocol", | |||
Draft, draft-ietf-secsh-transport-09.txt | Internet-Draft, draft-ietf-secsh-transport-10.txt | |||
[SSH-USERAUTH] Ylonen, T., et al: "SSH Authentication Protocol", | [SECSH-USERAUTH] Ylonen, T., et al: "Secure Shell Authentication | |||
Internet-Draft, draft-ietf-secsh-userauth-09.txt | Protocol", Internet-Draft, draft-ietf-secsh-userauth-10.txt | |||
[SSH-CONNECT] Ylonen, T., et al: "SSH Connection Protocol", Internet- | [SECSH-CONNECT] Ylonen, T., et al: "Secure Shell Connection Protocol", | |||
Draft, draft-ietf-secsh-connect-09.txt | Internet-Draft, draft-ietf-secsh-connect-10.txt | |||
12. Authors' Addresses | 13. Authors' Addresses | |||
Tatu Ylonen | Tatu Ylonen | |||
SSH Communications Security Corp | SSH Communications Security Corp | |||
Fredrikinkatu 42 | Fredrikinkatu 42 | |||
FIN-00100 HELSINKI | FIN-00100 HELSINKI | |||
Finland | Finland | |||
E-mail: ylo@ssh.com | E-mail: ylo@ssh.com | |||
Sami Lehtinen | Sami Lehtinen | |||
SSH Communications Security Corp | SSH Communications Security Corp | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |