draft-ietf-secsh-filexfer-02.txt | draft-ietf-secsh-filexfer-03.txt | |||
---|---|---|---|---|
Network Working Group T. Ylonen | Secure Shell Working Group J. Galbraith | |||
Internet-Draft S. Lehtinen | Internet-Draft VanDyke Software | |||
Expires: April 1, 2002 SSH Communications Security Corp | Expires: April 16, 2003 T. Ylonen | |||
October 2001 | S. Lehtinen | |||
SSH Communications Security Corp | ||||
October 16, 2002 | ||||
SSH File Transfer Protocol | SSH File Transfer Protocol | |||
draft-ietf-secsh-filexfer-02.txt | draft-ietf-secsh-filexfer-03.txt | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
skipping to change at page 1, line 32 | skipping to change at page 1, line 34 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at http:// | The list of current Internet-Drafts can be accessed at http:// | |||
www.ietf.org/ietf/1id-abstracts.txt. | www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on April 1, 2002. | This Internet-Draft will expire on April 16, 2003. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2001). All Rights Reserved. | Copyright (C) The Internet Society (2002). All Rights Reserved. | |||
Abstract | Abstract | |||
The SSH File Transfer Protocol provides secure file transfer | The SSH File Transfer Protocol provides secure file transfer | |||
functionality over any reliable data stream. It is the standard file | functionality over any reliable data stream. It is the standard file | |||
transfer protocol for use with the SSH2 protocol. This document | transfer protocol for use with the SSH2 protocol. This document | |||
describes the file transfer protocol and its interface to the SSH2 | describes the file transfer protocol and its interface to the SSH2 | |||
protocol suite. | protocol suite. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Use with the SSH Connection Protocol . . . . . . . . . . . . 4 | 2. Use with the SSH Connection Protocol . . . . . . . . . . . 4 | |||
3. General Packet Format . . . . . . . . . . . . . . . . . . . 5 | 3. General Packet Format . . . . . . . . . . . . . . . . . . 5 | |||
4. Protocol Initialization . . . . . . . . . . . . . . . . . . 7 | 4. Protocol Initialization . . . . . . . . . . . . . . . . . 7 | |||
5. File Attributes . . . . . . . . . . . . . . . . . . . . . . 8 | 4.1 Client Initialization . . . . . . . . . . . . . . . . . . 7 | |||
6. Requests From the Client to the Server . . . . . . . . . . . 10 | 4.2 Server Initialization . . . . . . . . . . . . . . . . . . 7 | |||
6.1 Request Synchronization and Reordering . . . . . . . . . . . 10 | 4.3 Determining Server Newline Convention . . . . . . . . . . 8 | |||
6.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 5. File Attributes . . . . . . . . . . . . . . . . . . . . . 9 | |||
6.3 Opening, Creating, and Closing Files . . . . . . . . . . . . 11 | 5.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
6.4 Reading and Writing . . . . . . . . . . . . . . . . . . . . 13 | 5.2 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
6.5 Removing and Renaming Files . . . . . . . . . . . . . . . . 14 | 5.3 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
6.6 Creating and Deleting Directories . . . . . . . . . . . . . 15 | 5.4 Owner and Group . . . . . . . . . . . . . . . . . . . . . 10 | |||
6.7 Scanning Directories . . . . . . . . . . . . . . . . . . . . 15 | 5.5 Permissions . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
6.8 Retrieving File Attributes . . . . . . . . . . . . . . . . . 16 | 5.6 Times . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
6.9 Setting File Attributes . . . . . . . . . . . . . . . . . . 17 | 5.7 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
6.10 Dealing with Symbolic links . . . . . . . . . . . . . . . . 18 | 5.8 Extended attributes . . . . . . . . . . . . . . . . . . . 12 | |||
6.11 Canonicalizing the Server-Side Path Name . . . . . . . . . . 18 | 6. Requests From the Client to the Server . . . . . . . . . . 13 | |||
7. Responses from the Server to the Client . . . . . . . . . . 20 | 6.1 Request Synchronization and Reordering . . . . . . . . . . 13 | |||
8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . 24 | 6.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . 25 | 6.3 Opening, Creating, and Closing Files . . . . . . . . . . . 14 | |||
10. Changes from previous protocol versions . . . . . . . . . . 26 | 6.4 Reading and Writing . . . . . . . . . . . . . . . . . . . 17 | |||
10.1 Changes between versions 3 and 2 . . . . . . . . . . . . . . 26 | 6.5 Removing and Renaming Files . . . . . . . . . . . . . . . 18 | |||
10.2 Changes between versions 2 and 1 . . . . . . . . . . . . . . 26 | 6.6 Creating and Deleting Directories . . . . . . . . . . . . 19 | |||
10.3 Changes between versions 1 and 0 . . . . . . . . . . . . . . 26 | 6.7 Scanning Directories . . . . . . . . . . . . . . . . . . . 19 | |||
11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . 27 | 6.8 Retrieving File Attributes . . . . . . . . . . . . . . . . 20 | |||
References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 6.9 Setting File Attributes . . . . . . . . . . . . . . . . . 21 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 | 6.10 Dealing with Symbolic links . . . . . . . . . . . . . . . 22 | |||
Full Copyright Statement . . . . . . . . . . . . . . . . . . 29 | 6.11 Canonicalizing the Server-Side Path Name . . . . . . . . . 23 | |||
6.11.1 Best practice for dealing with paths . . . . . . . . . . . 23 | ||||
7. Responses from the Server to the Client . . . . . . . . . 24 | ||||
8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . 28 | ||||
9. Security Considerations . . . . . . . . . . . . . . . . . 29 | ||||
10. Changes from previous protocol versions . . . . . . . . . 30 | ||||
10.1 Changes between versions 4 and 3 . . . . . . . . . . . . . 30 | ||||
10.2 Changes between versions 3 and 2 . . . . . . . . . . . . . 31 | ||||
10.3 Changes between versions 2 and 1 . . . . . . . . . . . . . 31 | ||||
10.4 Changes between versions 1 and 0 . . . . . . . . . . . . . 31 | ||||
11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . 32 | ||||
References . . . . . . . . . . . . . . . . . . . . . . . . 33 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 33 | ||||
Full Copyright Statement . . . . . . . . . . . . . . . . . 35 | ||||
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 [3]. | channel in the SSH2 protocol [5]. | |||
This protocol is designed so that it could be used to implement a | 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 | secure remote file system service, as well as a secure file transfer | |||
service. | service. | |||
This protocol assumes that it runs over a secure channel, and that | This protocol assumes that it runs over a secure channel, and that | |||
the server has already authenticated the user at the client end, and | the server has already authenticated the user at the client end, and | |||
that the identity of the client user is externally available to the | that the identity of the client user is externally available to the | |||
server implementation. | server implementation. | |||
In general, this protocol follows a simple request-response model. | In general, this protocol follows a simple request-response model. | |||
Each request and response contains a sequence number and multiple | Each request and response contains a sequence number and multiple | |||
requests may be pending simultaneously. There are a relatively large | requests may be pending simultaneously. There are a relatively large | |||
number of different request messages, but a small number of possible | number of different request messages, but a small number of possible | |||
response messages. Each request has one or more response messages | response messages. Each request has one or more response messages | |||
that may be returned in result (e.g., a read either returns data or | that may be returned in result (e.g., a read either returns data or | |||
reports error status). | reports error status). | |||
The packet format descriptions in this specification follow the | The packet format descriptions in this specification follow the | |||
notation presented in the secsh architecture draft.[3]. | notation presented in the secsh architecture draft. [5] | |||
Even though this protocol is described in the context of the SSH2 | Even though this protocol is described in the context of the SSH2 | |||
protocol, this protocol is general and independent of the rest of the | protocol, this protocol is general and independent of the rest of the | |||
SSH2 protocol suite. It could be used in a number of different | SSH2 protocol suite. It could be used in a number of different | |||
applications, such as secure file transfer over TLS RFC 2246 [1] and | applications, such as secure file transfer over TLS RFC 2246 [1] and | |||
transfer of management information in VPN applications. | transfer of management information in VPN applications. | |||
2. Use with the SSH Connection Protocol | 2. Use with the SSH Connection Protocol | |||
When used with the SSH2 Protocol suite, this protocol is intended to | When used with the SSH2 Protocol suite, this protocol is intended to | |||
be used from the SSH Connection Protocol [5] as a subsystem, as | be used from the SSH Connection Protocol [7] as a subsystem, as | |||
described in section ``Starting a Shell or a Command''. The | described in section ``Starting a Shell or a Command''. The | |||
subsystem 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 | All packets transmitted over the secure connection are of the | |||
following format: | following format: | |||
uint32 length | uint32 length | |||
byte type | byte type | |||
skipping to change at page 6, line 27 | skipping to change at page 6, line 25 | |||
#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_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 | |||
RESERVED_FOR_EXTENSIONS 210-255 | ||||
Additional packet types should only be defined if the protocol | Additional packet types should only be defined if the protocol | |||
version number (see Section ``Protocol Initialization'') is | version number (see Section ``Protocol Initialization'') is | |||
incremented, and their use MUST be negotiated using the version | incremented, and their use MUST be negotiated using the version | |||
number. However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY | number. However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY | |||
packets can be used to implement vendor-specific extensions. See | packets can be used to implement vendor-specific extensions. See | |||
Section ``Vendor-Specific-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, the client first sends a | |||
(including its version number) packet to the server. The server | SSH_FXP_INIT (including its version number) packet to the server. | |||
responds with a SSH_FXP_VERSION packet, supplying the lowest of its | The server responds with a SSH_FXP_VERSION packet, supplying the | |||
own and the client's version number. Both parties should from then | lowest of its own and the client's version number. Both parties | |||
on adhere to particular version of the protocol. | should from then on adhere to particular version of the protocol. | |||
The version number of the protocol specified in this document is 4. | ||||
The version number should be incremented for each incompatible | ||||
revision of this protocol. | ||||
4.1 Client Initialization | ||||
The SSH_FXP_INIT packet (from client to server) has the following | The SSH_FXP_INIT packet (from client to server) has the following | |||
data: | data: | |||
uint32 version | uint32 version | |||
<extension data> | ||||
Version 3 of this protocol allowed clients to include extensions in | ||||
the SSH_FXP_INIT packet; however, this can cause interoperability | ||||
problems with version 1 and version 2 servers because the client must | ||||
send this packet before knowing the servers version. | ||||
In this version of the protocol, clients MUST use the | ||||
SSH_FXP_EXTENDED packet to send extensions to the server after | ||||
version exchange has completed. Clients MUST NOT include extensions | ||||
in the version packet. This will prevent interoperability problems | ||||
with older servers | ||||
4.2 Server Initialization | ||||
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. | 'version' is the lower of the protocol version supported by the | |||
The version number should be incremented for each incompatible | server and the version number received from the client. | |||
revision of this protocol. | ||||
The extension data in the above packets may be empty, or may be a | The extension data 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 | pairs (both strings MUST always be present if one is, but the | |||
`extension_data' string may be of zero length). If present, these | `extension_data' string may be of zero length). If present, these | |||
strings indicate extensions to the baseline protocol. The | strings indicate extensions to the baseline protocol. The | |||
`extension_name' field(s) identify the name of the extension. The | `extension_name' field(s) identify the name of the extension. The | |||
name should be of the form "name@domain", where the domain is the DNS | name should be of the form "name@domain", where the domain is the DNS | |||
domain name of the organization defining the extension. Additional | domain name of the organization defining the extension. Additional | |||
names that are not of this format may be defined later by the IETF. | names that are not of this format may be defined later by the IETF. | |||
Implementations MUST silently ignore any extensions whose name they | Implementations MUST silently ignore any extensions whose name they | |||
do not recognize. | do not recognize. | |||
5. File Attributes | 4.3 Determining Server Newline Convention | |||
A new compound data type is defined for encoding file attributes. It | In order to correctly process text files in a cross platform | |||
is basically just a combination of elementary types, but is defined | compatible way, the newline convention must be converted from that of | |||
once because of the non-trivial description of the fields and to | the server to that of the client, or, during an upload, from that of | |||
ensure maintainability. | the client to that of the server. | |||
Versions 3 and prior of this protocol made no provisions for | ||||
processing text files. Many clients implemented some sort of | ||||
conversion algorithm, but without either a 'canonical' on the wire | ||||
format or knowledge of the servers newline convention, correct | ||||
conversion was not always possible. | ||||
Starting with Version 4, the SSH_FXF_TEXT file open flag (Section | ||||
6.3) makes it possible to request that the server translate a file to | ||||
a 'canonical' on the wire format. This format uses \r\n as the line | ||||
separator. | ||||
Servers for systems using multiple newline characters (for example, | ||||
Mac OS X or VMS) or systems using counted records, MUST translate to | ||||
the canonical form. | ||||
However, to ease the burden of implementation on servers that use a | ||||
single, simple separator sequence, the following extension allows the | ||||
canonical format to be changed. | ||||
string "newline" | ||||
string new-canonical-separator (usually "\r" or "\n" or "\r\n") | ||||
All clients MUST support this extension. | ||||
When processing text files, clients SHOULD NOT translate any | ||||
character or sequence that is not an exact match of the servers | ||||
newline separator. | ||||
In particular, if the newline sequence being used is the canonical | ||||
"\r\n" sequence, a lone \r or a lone \n SHOULD be written through | ||||
without change. | ||||
5. File Attributes | ||||
A new compound data type is defined for encoding file attributes. | ||||
The same encoding is used both when returning file attributes from | The same encoding is used both when returning file attributes from | |||
the server and when sending file attributes to the server. When | the server and when sending file attributes to the server. When | |||
sending it to the server, the flags field specifies which attributes | sending it to the server, the flags field specifies which attributes | |||
are included, and the server will use default values for the | are included, and the server will use default values for the | |||
remaining attributes (or will not modify the values of remaining | remaining attributes (or will not modify the values of remaining | |||
attributes). When receiving attributes from the server, the flags | attributes). When receiving attributes from the server, the flags | |||
specify which attributes are included in the returned data. The | specify which attributes are included in the returned data. The | |||
server normally returns all attributes it knows about. | server normally returns all attributes it knows about. | |||
uint32 flags | uint32 flags | |||
byte type always present | ||||
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 | string owner present only if flag SSH_FILEXFER_ATTR_OWNERGROUP | |||
uint32 gid present only if flag SSH_FILEXFER_ATTR_UIDGID | string group present only if flag SSH_FILEXFER_ATTR_OWNERGROUP | |||
uint32 permissions present only if flag SSH_FILEXFER_ATTR_PERMISSIONS | uint32 permissions present only if flag SSH_FILEXFER_ATTR_PERMISSIONS | |||
uint32 atime present only if flag SSH_FILEXFER_ACMODTIME | uint32 atime present only if flag SSH_FILEXFER_ATTR_ACCESSTIME | |||
uint32 mtime present only if flag SSH_FILEXFER_ACMODTIME | uint32 createtime present only if flag SSH_FILEXFER_ATTR_CREATETIME | |||
uint32 mtime present only if flag SSH_FILEXFER_ATTR_MODIFYTIME | ||||
string acl present only if flag SSH_FILEXFER_ATTR_ACL | ||||
uint32 extended_count present only if flag SSH_FILEXFER_ATTR_EXTENDED | uint32 extended_count present only if flag 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 | |||
5.1 Flags | ||||
The `flags' specify which of the fields are present. Those fields | The `flags' specify which of the fields are present. Those fields | |||
for which the corresponding flag is not set are not present (not | for which the corresponding flag is not set are not present (not | |||
included in the packet). New flags can only be added by incrementing | included in the packet). New flags can only be added by incrementing | |||
the protocol version number (or by using the extension mechanism | the protocol version number (or by using the extension mechanism | |||
described below). | described below). | |||
The `size' field specifies the size of the file in bytes. | The flags bits are defined to have the following values: | |||
The `uid' and `gid' fields contain numeric Unix-like user and group | #define SSH_FILEXFER_ATTR_SIZE 0x00000001 | |||
identifiers, respectively. | #define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004 | |||
#define SSH_FILEXFER_ATTR_ACCESSTIME 0x00000008 | ||||
#define SSH_FILEXFER_ATTR_CREATETIME 0x00000010 | ||||
#define SSH_FILEXFER_ATTR_MODIFYTIME 0x00000020 | ||||
#define SSH_FILEXFER_ATTR_ACL 0x00000040 | ||||
#define SSH_FILEXFER_ATTR_OWNERGROUP 0x00000080 | ||||
#define SSH_FILEXFER_ATTR_EXTENDED 0x80000000 | ||||
In previous versions of this protocol flags value 0x00000002 was | ||||
SSH_FILEXFER_ATTR_UIDGID. This value is now unused, and OWNERGROUP | ||||
was given a new value in order to ease implementation burden. | ||||
0x00000002 MUST NOT appear in the mask. Some future version of this | ||||
protocol may reuse flag 0x00000002. | ||||
5.2 Type | ||||
The type field is always present. The following types are defined: | ||||
#define SSH_FILEXFER_TYPE_REGULAR 1 | ||||
#define SSH_FILEXFER_TYPE_DIRECTORY 2 | ||||
#define SSH_FILEXFER_TYPE_SYMLINK 3 | ||||
#define SSH_FILEXFER_TYPE_SPECIAL 4 | ||||
#define SSH_FILEXFER_TYPE_UNKNOWN 5 | ||||
On a POSIX system, these values would be derived from the permission | ||||
field. | ||||
5.3 Size | ||||
The `size' field specifies the size of the file on disk, in bytes. | ||||
If it is present during file creation, it should be considered a hint | ||||
as to the files eventual size. | ||||
Files opened with the SSH_FXF_TEXT flag may have a size that is | ||||
greater or less than the value of the size field. | ||||
5.4 Owner and Group | ||||
The `owner' and `group' fields are represented as UTF-8 strings; this | ||||
is the form used by NFS v4. See NFS version 4 Protocol. [3] The | ||||
following text is selected quotations from section 5.6. | ||||
To avoid a representation that is tied to a particular underlying | ||||
implementation at the client or server, the use of UTF-8 strings has | ||||
been chosen. The string should be of the form user@dns_domain". | ||||
This will allow for a client and server that do not use the same | ||||
local representation the ability to translate to a common syntax that | ||||
can be interpreted by both. In the case where there is no | ||||
translation available to the client or server, the attribute value | ||||
must be constructed without the "@". Therefore, the absence of the @ | ||||
from the owner or owner_group attribute signifies that no translation | ||||
was available and the receiver of the attribute should not place any | ||||
special meaning with the attribute value. Even though the attribute | ||||
value can not be translated, it may still be useful. In the case of | ||||
a client, the attribute string may be used for local display of | ||||
ownership. | ||||
5.5 Permissions | ||||
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 [1]. | defined by POSIX [1]. | |||
The `atime' and `mtime' contain the access and modification times of | 5.6 Times | |||
the files, respectively. They are represented as seconds from Jan 1, | ||||
1970 in UTC. | The 'atime', 'createtime', and 'mtime' contain the access, creation, | |||
and modification times of the files, respectively. They are | ||||
represented as seconds from Jan 1, 1970 in UTC. | ||||
5.7 ACL | ||||
The 'ACL' field contains an ACL similar to that defined in section | ||||
5.9 of NFS version 4 Protocol [3]. | ||||
uint32 ace-count | ||||
repeated ace-count time: | ||||
uint32 ace-type | ||||
uint32 ace-flag | ||||
uint32 ace-mask | ||||
string who [UTF-8] | ||||
ace-type is one of the following four values (taken from NFS Version | ||||
4 Protocol [3]: | ||||
const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000; | ||||
const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001; | ||||
const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002; | ||||
const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003; | ||||
ace-flag is a combination of the following flag values. See NFS | ||||
Version 4 Protocol [3] section 5.9.2: | ||||
const ACE4_FILE_INHERIT_ACE = 0x00000001; | ||||
const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002; | ||||
const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004; | ||||
const ACE4_INHERIT_ONLY_ACE = 0x00000008; | ||||
const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010; | ||||
const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020; | ||||
const ACE4_IDENTIFIER_GROUP = 0x00000040; | ||||
ace-mask is any combination of the following flags (taken from NFS | ||||
Version 4 Protocol [3] section 5.9.3: | ||||
const ACE4_READ_DATA = 0x00000001; | ||||
const ACE4_LIST_DIRECTORY = 0x00000001; | ||||
const ACE4_WRITE_DATA = 0x00000002; | ||||
const ACE4_ADD_FILE = 0x00000002; | ||||
const ACE4_APPEND_DATA = 0x00000004; | ||||
const ACE4_ADD_SUBDIRECTORY = 0x00000004; | ||||
const ACE4_READ_NAMED_ATTRS = 0x00000008; | ||||
const ACE4_WRITE_NAMED_ATTRS = 0x00000010; | ||||
const ACE4_EXECUTE = 0x00000020; | ||||
const ACE4_DELETE_CHILD = 0x00000040; | ||||
const ACE4_READ_ATTRIBUTES = 0x00000080; | ||||
const ACE4_WRITE_ATTRIBUTES = 0x00000100; | ||||
const ACE4_DELETE = 0x00010000; | ||||
const ACE4_READ_ACL = 0x00020000; | ||||
const ACE4_WRITE_ACL = 0x00040000; | ||||
const ACE4_WRITE_OWNER = 0x00080000; | ||||
const ACE4_SYNCHRONIZE = 0x00100000; | ||||
who is a UTF-8 string of the form described in 'Owner and Group' | ||||
(Section 5.4) | ||||
5.8 Extended attributes | ||||
The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension | The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension | |||
mechanism for vendor-specific extensions. If the flag is specified, | mechanism for vendor-specific extensions. If the flag is specified, | |||
then the `extended_count' field is present. It specifies the number | then the `extended_count' field is present. It specifies the number | |||
of extended_type-extended_data pairs that follow. Each of these | of extended_type-extended_data pairs that follow. Each of these | |||
pairs specifies an extended attribute. For each of the attributes, | pairs specifies an extended attribute. For each of the attributes, | |||
the extended_type field should be a string of the format | the extended_type field should be a string of the format | |||
"name@domain", where "domain" is a valid, registered domain name and | "name@domain", where "domain" is a valid, registered domain name and | |||
"name" identifies the method. The IETF may later standardize certain | "name" identifies the method. The IETF may later standardize certain | |||
names that deviate from this format (e.g., that do not contain the | names that deviate from this format (e.g., that do not contain the | |||
skipping to change at page 9, line 26 | skipping to change at page 13, line 5 | |||
Additional fields can be added to the attributes by either defining | Additional fields can be added to the attributes by either defining | |||
additional bits to the flags field to indicate their presence, or by | additional bits to the flags field to indicate their presence, or by | |||
defining extended attributes for them. The extended attributes | defining extended attributes for them. The extended attributes | |||
mechanism is recommended for most purposes; additional flags bits | mechanism is recommended for most purposes; additional flags bits | |||
should only be defined by an IETF standards action that also | should only be defined by an IETF standards action that also | |||
increments the protocol version number. The use of such new fields | increments the protocol version number. The use of such new fields | |||
MUST be negotiated by the version number in the protocol exchange. | MUST be negotiated by the version number in the protocol exchange. | |||
It is a protocol error if a packet with unsupported protocol bits is | It is a protocol error if a packet with unsupported protocol bits is | |||
received. | received. | |||
The flags bits are defined to have the following values: | ||||
#define SSH_FILEXFER_ATTR_SIZE 0x00000001 | ||||
#define SSH_FILEXFER_ATTR_UIDGID 0x00000002 | ||||
#define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004 | ||||
#define SSH_FILEXFER_ATTR_ACMODTIME 0x00000008 | ||||
#define SSH_FILEXFER_ATTR_EXTENDED 0x80000000 | ||||
6. Requests From the Client to the Server | 6. Requests From the Client to the Server | |||
Requests from the client to the server represent the various file | Requests from the client to the server represent the various file | |||
system operations. Each request begins with an `id' field, which is | system operations. Each request begins with an `id' field, which is | |||
a 32-bit identifier identifying the request (selected by the client). | a 32-bit identifier identifying the request (selected by the client). | |||
The same identifier will be returned in the response to the request. | The same identifier will be returned in the response to the request. | |||
One possible implementation of it is a monotonically increasing | One possible implementation is a monotonically increasing request | |||
request sequence number (modulo 2^32). | sequence number (modulo 2^32). | |||
Many operations in the protocol operate on open files. The | Many operations in the protocol operate on open files. The | |||
SSH_FXP_OPEN request can return a file handle (which is an opaque | SSH_FXP_OPEN request can return a file handle (which is an opaque | |||
variable-length string) which may be used to access the file later | variable-length string) which may be used to access the file later | |||
(e.g. in a read operation). The client MUST NOT send requests the | (e.g. in a read operation). The client MUST NOT send requests the | |||
server with bogus or closed handles. However, the server MUST | server with bogus or closed handles. However, the server MUST | |||
perform adequate checks on the handle in order to avoid security | perform adequate checks on the handle in order to avoid security | |||
risks due to fabricated handles. | risks due to fabricated handles. | |||
This design allows either stateful and stateless server | This design allows either stateful and stateless server | |||
skipping to change at page 11, line 32 | skipping to change at page 14, line 32 | |||
the intended area. | 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 | Clients should not make any other assumptions; however, they can | |||
splice path name components returned by SSH_FXP_READDIR together | splice path name components returned by SSH_FXP_READDIR together | |||
using a slash ('/') as the separator, and that will work as expected. | using a slash ('/') as the separator, and that will work as expected. | |||
In order to comply with IETF Policy on Character Sets and Languages | ||||
[2], all filenames are to be encoded in UTF-8. The shortest valid | ||||
UTF-8 encoding of the UNICODE data MUST be used. The server is | ||||
responsible for converting the UNICODE data to whatever canonical | ||||
form it requires. | ||||
For example, if the server requires that precomposed characters | ||||
always be used, the server MUST NOT assume the filename as sent by | ||||
the client has this attribute, but must do this normalization itself. | ||||
It is understood that the lack of well-defined semantics for file | It is understood that the lack of well-defined semantics for file | |||
names may cause interoperability problems between clients and servers | names may cause interoperability problems between clients and servers | |||
using radically different operating systems. However, this approach | using radically different operating systems. However, this approach | |||
is known to work acceptably with most systems, and alternative | is known to work acceptably with most systems, and alternative | |||
approaches that e.g. treat file names as sequences of structured | approaches that e.g. treat file names as sequences of structured | |||
components are quite complicated. | components are quite complicated. | |||
6.3 Opening, Creating, and Closing Files | 6.3 Opening, Creating, and Closing Files | |||
Files are opened and created using the SSH_FXP_OPEN message, whose | Files are opened and created using the SSH_FXP_OPEN message, whose | |||
data part is as follows: | data part is as follows: | |||
uint32 id | uint32 id | |||
string filename | string filename [UTF-8] | |||
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 | The `pflags' field is a bitmask. The following bits have been | |||
defined. | 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 | |||
#define SSH_FXF_TEXT 0x00000040 | ||||
These have the following meanings: | These have the following meanings: | |||
SSH_FXF_READ | SSH_FXF_READ | |||
Open the file for reading. | Open the file for reading. | |||
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. The | |||
offset parameter to write will be ignored. | ||||
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 already 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. | |||
SSH_FXF_TEXT | ||||
Indicates that the server should treat the file as text and | ||||
convert it to the canonical newline convention in use. (See | ||||
Determining Server Newline Convention. (Section 4.3) | ||||
When a file is opened with the FXF_TEXT flag, the offset field in | ||||
both the read and write function are ignored. | ||||
Servers MUST correctly process multiple parallel reads and writes | ||||
correctly in this mode. Naturally, it is permissible for them to | ||||
do this by serializing the requests. It would not be possible for | ||||
a client to reliably detect a server that does not implement | ||||
parallel writes in time to prevent damage. | ||||
Clients SHOULD use the SSH_FXF_APPEND flag to append data to a | ||||
text file rather then using write with a calculated offset. | ||||
To support seeks on text file the following SSH_FXP_EXTENDED | ||||
packet is defined. | ||||
string "text-seek" | ||||
string file-handle | ||||
uint64 line-number | ||||
line-number is the index of the line number to seek to, where byte | ||||
0 in the file is line number 0, and the byte directly following | ||||
the first newline sequence in the file is line number 1 and so on. | ||||
The response to a "text-seek" request is an SSH_FXP_STATUS | ||||
message. | ||||
An attempt to seek past the end-of-file should result in a | ||||
SSH_FX_EOF status. | ||||
Servers SHOULD support at least one "text-seek" in order to | ||||
support resume. However, a client MUST be prepared to receive | ||||
SSH_FX_OP_UNSUPPORTED when attempting a "text-seek" operation. | ||||
The client can then try a fall-back strategy, if it has one. | ||||
Clients MUST be prepared to handle SSH_FX_OP_UNSUPPORTED returned | ||||
for read or write operations that are not sequential. | ||||
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 | Default values will be used for those attributes that are not | |||
specified. 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 in "binary" mode (i.e., no translations between different | ||||
character sets and newline encodings). | ||||
The response to this message will be either SSH_FXP_HANDLE (if the | 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 | A file is closed by using the SSH_FXP_CLOSE request. Its data field | |||
has 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 | where `id' is the request identifier, and `handle' is a handle | |||
skipping to change at page 14, line 22 | skipping to change at page 18, line 29 | |||
allocate 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. | |||
6.5 Removing and Renaming Files | 6.5 Removing and Renaming Files | |||
Files can be removed using the SSH_FXP_REMOVE message. It has the | 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 [UTF-8] | |||
where `id' is the request identifier and `filename' is the name of | where `id' is the request identifier and `filename' is the name of | |||
the file to be removed. See Section ``File Names'' for more | the file to be removed. See Section ``File Names'' for more | |||
information. This request cannot be used to remove directories. | information. This request cannot be used to remove directories. | |||
The server will respond to this request with a SSH_FXP_STATUS | The server will respond to this request with a SSH_FXP_STATUS | |||
message. | message. | |||
Files (and directories) can be renamed using the SSH_FXP_RENAME | Files (and directories) can be renamed using the SSH_FXP_RENAME | |||
message. Its data is as follows: | message. Its data is as follows: | |||
uint32 id | uint32 id | |||
string oldpath | string oldpath [UTF-8] | |||
string newpath | string newpath [UTF-8] | |||
where `id' is the request identifier, `oldpath' is the name of an | where `id' is the request identifier, `oldpath' is the name of an | |||
existing file or directory, and `newpath' is the new name for the | existing file or directory, and `newpath' is the new name for the | |||
file or directory. It is an error if there already exists a file | file or directory. It is an error if there already exists a file | |||
with the name specified by newpath. The server may also fail rename | with the name specified by newpath. The server may also fail rename | |||
requests in other situations, for example if `oldpath' and `newpath' | requests in other situations, for example if `oldpath' and `newpath' | |||
point to different 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 | The server will respond to this request with a SSH_FXP_STATUS | |||
message. | message. | |||
6.6 Creating and Deleting Directories | 6.6 Creating and Deleting Directories | |||
New directories can be created using the SSH_FXP_MKDIR request. It | New directories can be created using the SSH_FXP_MKDIR request. It | |||
has the following format: | has the following format: | |||
uint32 id | uint32 id | |||
string path | string path [UTF-8] | |||
ATTRS attrs | ATTRS attrs | |||
where `id' is the request identifier, `path' and `attrs' specifies | where `id' is the request identifier. | |||
the modifications to be made to its attributes. See Section ``File | ||||
Names'' for more information on file names. Attributes are discussed | ||||
in more detail in Section ``File Attributes''. specifies the | ||||
directory to be created. An error will be returned if a file or | ||||
directory with the specified path already exists. The server will | ||||
respond to this request with a SSH_FXP_STATUS message. | ||||
Directories can be removed using the SSH_FXP_RMDIR request, which | `path' specifies the directory to be created. See Section ``File | |||
has the following format: | Names'' for more information on file names. | |||
`attrs' specifies the attributes that should be applied to it upon | ||||
creation. Attributes are discussed in more detail in Section ``File | ||||
Attributes''. | ||||
The server will respond to this request with a SSH_FXP_STATUS | ||||
message. If a file or directory with the specified path already | ||||
exists, an error will be returned. | ||||
Directories can be removed using the SSH_FXP_RMDIR request, which has | ||||
the following format: | ||||
uint32 id | uint32 id | |||
string path | string path [UTF-8] | |||
where `id' is the request identifier, and `path' specifies the | where `id' is the request identifier, and `path' specifies the | |||
directory to be removed. See Section ``File Names'' for more | directory to be removed. See Section ``File Names'' for more | |||
information on file names. An error will be returned if no directory | information on file names. | |||
with the specified path exists, or if the specified directory is not | ||||
empty, or if the path specified a file system object other than a | The server responds to this request with a SSH_FXP_STATUS message. | |||
directory. The server responds to this request with a SSH_FXP_STATUS | Errors may be returned from this operation for various reasons, | |||
message. | including, but not limited to, the path does not exist, the path does | |||
not refer to a directory object, the directory is not empty, or the | ||||
user has insufficient access or permission to perform the requested | ||||
operation. | ||||
6.7 Scanning Directories | 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 | SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one | |||
or more file names with full file attributes for each file. The | or more file names with full file attributes for each file. The | |||
client should call SSH_FXP_READDIR repeatedly until it has found the | client should call SSH_FXP_READDIR repeatedly until it has found the | |||
file it is looking for or until the server responds with a | file it is looking for or until the server responds with a | |||
SSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF if | SSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF if | |||
there are no more files in the directory). The client should then | there are no more files in the directory). The client should then | |||
close the handle using the 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 | The SSH_FXP_OPENDIR opens a directory for reading. It has the | |||
following format: | following format: | |||
uint32 id | uint32 id | |||
string path | string path [UTF-8] | |||
where `id' is the request identifier and `path' is the path name of | where `id' is the request identifier and `path' is the path name of | |||
the directory to be listed (without any trailing slash). See Section | the directory to be listed (without any trailing slash). See Section | |||
``File Names'' for more information on file names. This will return | ``File Names'' for more information on file names. This will return | |||
an error if the path does not specify a directory or if the directory | an error if the path does not specify a directory or if the directory | |||
is not readable. The server will respond to this request with either | is not readable. The server will respond to this request with either | |||
a 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 | Once the directory has been successfully opened, files (and | |||
directories) contained in it can be listed using SSH_FXP_READDIR | directories) contained in it can be listed using SSH_FXP_READDIR | |||
skipping to change at page 16, line 34 | skipping to change at page 20, line 37 | |||
where `id' is the request identifier, and `handle' is a handle | where `id' is the request identifier, and `handle' is a handle | |||
returned by SSH_FXP_OPENDIR. (It is a protocol error to attempt to | returned by SSH_FXP_OPENDIR. (It is a protocol error to attempt to | |||
use an ordinary 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 | Full status information is returned for each name in order to speed | |||
up typical directory listings. | up typical directory listings. | |||
If there are no more names available to be read, the server MUST | ||||
respond with a SSH_FXP_STATUS message with error code of SSH_FX_EOF. | ||||
When the client no longer wishes to read more names from the | When the client no longer wishes to read more names from the | |||
directory, it SHOULD call SSH_FXP_CLOSE for the handle. The handle | directory, it SHOULD call SSH_FXP_CLOSE for the handle. The handle | |||
should be closed regardless of whether an error has occurred or not. | should be closed regardless of whether an error has occurred or not. | |||
6.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 | SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT | |||
follows symbolic links on the server, whereas SSH_FXP_LSTAT does not | follows symbolic links on the server, whereas SSH_FXP_LSTAT does not | |||
follow symbolic links. Both have the same format: | follow symbolic links. Both have the same format: | |||
uint32 id | uint32 id | |||
string path | string path [UTF-8] | |||
uint32 flags | ||||
where `id' is the request identifier, and `path' specifies the file | where `id' is the request identifier, and `path' specifies the file | |||
system object for which status is to be returned. The server | system object for which status is to be returned. The server | |||
responds to this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS. | responds to this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS. | |||
The flags field specify the attribute flags in which the client has | ||||
particular interest. This is a hint to the server. For example, | ||||
because retrieving owner / group and acl information can be an | ||||
expensive operation under some operating systems, the server may | ||||
choose not to retrieve this information unless the client expresses a | ||||
specific interest in it. | ||||
The client has no guarantee the server will provide all the fields | ||||
that it has expressed an interest in. | ||||
SSH_FXP_FSTAT differs from the others in that it returns status | SSH_FXP_FSTAT differs from the others in that it returns status | |||
information for an open file (identified by the file handle). Its | information for an open file (identified by the file handle). Its | |||
format is as follows: | format is as follows: | |||
uint32 id | uint32 id | |||
string handle | string handle | |||
uint32 flags | ||||
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 | 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 | SSH_FXP_FSETSTAT requests. These requests are used for operations | |||
such as changing the ownership, permissions or access times, as well | such as changing the ownership, permissions or access times, as well | |||
as for 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 [UTF-8] | |||
ATTRS attrs | ATTRS attrs | |||
where `id' is the request identifier, `path' specifies the file | where `id' is the request identifier, `path' specifies the file | |||
system object (e.g. file or directory) whose attributes are to be | system object (e.g. file or directory) whose attributes are to be | |||
modified, and `attrs' specifies the modifications to be made to its | modified, and `attrs' specifies the modifications to be made to its | |||
attributes. Attributes are discussed in more detail in Section | attributes. Attributes are discussed in more detail in Section | |||
``File Attributes''. | ``File Attributes''. | |||
An error will be returned if the specified file system object does | An error will be returned if the specified file system object does | |||
not 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 | |||
skipping to change at page 18, line 14 | skipping to change at page 22, line 33 | |||
attributes. Attributes are discussed in more detail in Section | attributes. Attributes are discussed in more detail in Section | |||
``File Attributes''. The server will respond to this request with | ``File Attributes''. The server will respond to this request with | |||
SSH_FXP_STATUS. | SSH_FXP_STATUS. | |||
6.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 [UTF-8] | |||
where `id' is the request identifier and `path' specifies the path | where `id' is the request identifier and `path' specifies the path | |||
name 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 | The server will respond with a SSH_FXP_NAME packet containing only | |||
one name and a dummy attributes value. The name in the returned | one name and a dummy attributes value. The name in the returned | |||
packet contains the target of the link. If an error occurs, the | packet contains the target of the link. If an error occurs, the | |||
server may respond with SSH_FXP_STATUS. | server may respond with SSH_FXP_STATUS. | |||
The SSH_FXP_SYMLINK request will create a symbolic link on the | The SSH_FXP_SYMLINK request will create a symbolic link on the | |||
server. It is of the following format | server. It is of the following format | |||
uint32 id | uint32 id | |||
string linkpath | string linkpath [UTF-8] | |||
string targetpath | string targetpath [UTF-8] | |||
where `id' is the request identifier, `linkpath' specifies the path | where `id' is the request identifier, `linkpath' specifies the path | |||
name of the symlink to be created and `targetpath' specifies the | name of the symlink to be created and `targetpath' specifies the | |||
target of the symlink. The server shall respond with a | target of the symlink. The server shall respond with a | |||
SSH_FXP_STATUS indicating either success (SSH_FX_OK) or an error | SSH_FXP_STATUS indicating either success (SSH_FX_OK) or an error | |||
condition. | condition. | |||
6.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 | The SSH_FXP_REALPATH request can be used to have the server | |||
canonicalize any given path name to an absolute path. This is useful | canonicalize any given path name to an absolute path. This is useful | |||
for converting path names containing ".." components or relative | for converting path names containing ".." components or relative | |||
pathnames without a leading slash into absolute paths. The format of | pathnames without a leading slash into absolute paths. The format of | |||
the request is as follows: | the request is as follows: | |||
uint32 id | uint32 id | |||
string path | string path [UTF-8] | |||
where `id' is the request identifier and `path' specifies the path | where `id' is the request identifier and `path' specifies the path | |||
name to be canonicalized. The server will respond with a | name to be canonicalized. The server will respond with a | |||
SSH_FXP_NAME packet containing only one name and a dummy attributes | SSH_FXP_NAME packet containing the name in canonical form and a dummy | |||
value. The name is the returned packet will be in canonical form. | attributes value. If an error occurs, the server may also respond | |||
with SSH_FXP_STATUS. | ||||
If an error occurs, the server may also respond with SSH_FXP_STATUS. | 6.11.1 Best practice for dealing with paths | |||
The client SHOULD treat the results of SSH_FXP_REALPATH as a | ||||
canonical absolute path, even if the path does not appear to be | ||||
absolute. A client that use REALPATH(".") and treats the result as | ||||
absolute, even if there is no leading slash, will continue to | ||||
function correctly, even when talking to a Windows NT or VMS style | ||||
system, where absolute paths may not begin with a slash. | ||||
For example, if the client wishes to change directory up, and the | ||||
server has returned "c:/x/y/z" from REALPATH, the client SHOULD use | ||||
"c:/x/y/z/..". | ||||
As a second example, if the client wishes to open the file "x.txt" in | ||||
the current directory, and server has returned "dka100:/x/y/z" as the | ||||
canonical path of the directory, the client SHOULD open "dka100:/x/y/ | ||||
z/x.txt" | ||||
7. Responses from the Server to the Client | 7. Responses from the Server to the Client | |||
The server responds to the client using one of a few response | The server responds to the client using one of a few response | |||
packets. All requests can return a SSH_FXP_STATUS response upon | packets. All requests can return a SSH_FXP_STATUS response upon | |||
failure. When the operation is successful, any of the responses may | failure. When the operation is successful, any of the responses may | |||
be returned (depending on the operation). If no data needs to be | 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 | returned to the client, the SSH_FXP_STATUS response with SSH_FX_OK | |||
status is appropriate. Otherwise, the SSH_FXP_HANDLE message is used | status is appropriate. Otherwise, the SSH_FXP_HANDLE message is used | |||
to return a file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR | to return a file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR | |||
skipping to change at page 21, line 17 | skipping to change at page 25, line 14 | |||
#define SSH_FX_OK 0 | #define SSH_FX_OK 0 | |||
#define SSH_FX_EOF 1 | #define SSH_FX_EOF 1 | |||
#define SSH_FX_NO_SUCH_FILE 2 | #define SSH_FX_NO_SUCH_FILE 2 | |||
#define SSH_FX_PERMISSION_DENIED 3 | #define SSH_FX_PERMISSION_DENIED 3 | |||
#define SSH_FX_FAILURE 4 | #define SSH_FX_FAILURE 4 | |||
#define SSH_FX_BAD_MESSAGE 5 | #define SSH_FX_BAD_MESSAGE 5 | |||
#define SSH_FX_NO_CONNECTION 6 | #define SSH_FX_NO_CONNECTION 6 | |||
#define SSH_FX_CONNECTION_LOST 7 | #define SSH_FX_CONNECTION_LOST 7 | |||
#define SSH_FX_OP_UNSUPPORTED 8 | #define SSH_FX_OP_UNSUPPORTED 8 | |||
#define SSH_FX_INVALID_HANDLE 9 | ||||
#define SSH_FX_NO_SUCH_PATH 10 | ||||
#define SSH_FX_FILE_ALREADY_EXISTS 11 | ||||
#define SSH_FX_WRITE_PROTECT 12 | ||||
SSH_FX_OK | SSH_FX_OK | |||
Indicates successful completion of the operation. | Indicates successful completion of the operation. | |||
SSH_FX_EOF | SSH_FX_EOF | |||
indicates end-of-file condition; for SSH_FX_READ it means that no | 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 | more data is available in the file, and for SSH_FX_READDIR it | |||
indicates that no more files are contained in the directory. | indicates that no more files are contained in the directory. | |||
SSH_FX_NO_SUCH_FILE | SSH_FX_NO_SUCH_FILE | |||
is returned when a reference is made to a file which should exist | is returned when a reference is made to a file which does not | |||
but doesn't. | exist. | |||
SSH_FX_PERMISSION_DENIED | SSH_FX_PERMISSION_DENIED | |||
is returned when the authenticated user does not have sufficient | is returned when the authenticated user does not have sufficient | |||
permissions to perform the operation. | permissions to perform the operation. | |||
SSH_FX_FAILURE | SSH_FX_FAILURE | |||
is a generic catch-all error message; it should be returned if an | is a generic catch-all error message; it should be returned if an | |||
error occurs for which there is no more specific error code | error occurs for which there is no more specific error code | |||
defined. | defined. | |||
skipping to change at page 22, line 13 | skipping to change at page 26, line 13 | |||
client, and MUST NOT be returned by servers). | client, and MUST NOT be returned by servers). | |||
SSH_FX_OP_UNSUPPORTED | SSH_FX_OP_UNSUPPORTED | |||
indicates that an attempt was made to perform an operation which | indicates that an attempt was made to perform an operation which | |||
is not supported for the server (it may be generated locally by | is not supported for the server (it may be generated locally by | |||
the client if e.g. the version number exchange indicates that a | the client if e.g. the version number exchange indicates that a | |||
required feature is not supported by the server, or it may be | required feature is not supported by the server, or it may be | |||
returned by the server if the server does not implement an | returned by the server if the server does not implement an | |||
operation). | operation). | |||
SSH_FX_INVALID_HANDLE | ||||
The handle value was invalid. | ||||
SSH_FX_NO_SUCH_PATH | ||||
The file path does not exist or is invalid. | ||||
SSH_FX_FILE_ALREADY_EXISTS | ||||
The file already exists. | ||||
SSH_FX_WRITE_PROTECT | ||||
The file is on read only media, or the media is write protected. | ||||
The SSH_FXP_HANDLE response has the following format: | The SSH_FXP_HANDLE response has the following format: | |||
uint32 id | uint32 id | |||
string handle | string handle | |||
where `id' is the request identifier, and `handle' is an arbitrary | where `id' is the request identifier, and `handle' is an arbitrary | |||
string that identifies an open file or directory on the server. The | string that identifies an open file or directory on the server. The | |||
handle is opaque to the client; the client MUST NOT attempt to | 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 | interpret or modify it in any way. The length of the handle string | |||
MUST NOT exceed 256 data bytes. | MUST NOT exceed 256 data bytes. | |||
skipping to change at page 22, line 40 | skipping to change at page 27, line 8 | |||
string containing the requested data. The data string may be at most | 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 | 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 | be shorter if end of file is reached or if the read is from something | |||
other than a regular file. | other than a regular file. | |||
The SSH_FXP_NAME response has the following format: | The SSH_FXP_NAME response has the following format: | |||
uint32 id | uint32 id | |||
uint32 count | uint32 count | |||
repeats count times: | repeats count times: | |||
string filename | string filename [UTF-8] | |||
string longname | ||||
ATTRS attrs | ATTRS attrs | |||
where `id' is the request identifier, `count' is the number of names | where `id' is the request identifier, `count' is the number of names | |||
returned in this response, and the remaining fields repeat `count' | returned in this response, and the remaining fields repeat `count' | |||
times (so that all three fields are first included for the first | times (so that all three fields are first included for the first | |||
file, then for the second file, etc). In the repeated part, | file, then for the second file, etc). In the repeated part, | |||
`filename' is a file name being returned (for SSH_FXP_READDIR, it | `filename' is a file name being returned (for SSH_FXP_READDIR, it | |||
will be a relative name within the directory, without any path | will be a relative name within the directory, without any path | |||
components; for SSH_FXP_REALPATH it will be an absolute path name), | components; for SSH_FXP_REALPATH it will be an absolute path name), | |||
`longname' is an expanded format for the file name, similar to what | and `attrs' is the attributes of the file as described in Section | |||
is returned by "ls -l" on Unix systems, and `attrs' is the attributes | ``File 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: | The SSH_FXP_ATTRS response has the following format: | |||
uint32 id | uint32 id | |||
ATTRS attrs | ATTRS attrs | |||
where `id' is the request identifier, and `attrs' is the returned | where `id' is the request identifier, and `attrs' is the returned | |||
file attributes as described in Section ``File Attributes''. | file attributes as described in Section ``File Attributes''. | |||
8. Vendor-Specific Extensions | 8. Vendor-Specific Extensions | |||
skipping to change at page 25, line 5 | skipping to change at page 28, line 37 | |||
respond with SSH_FXP_STATUS with error/status set to | respond with SSH_FXP_STATUS with error/status set to | |||
SSH_FX_OP_UNSUPPORTED. | SSH_FX_OP_UNSUPPORTED. | |||
The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary | The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary | |||
extension-specific data from the server to the client. It is of the | extension-specific data from the server to the client. It is of the | |||
following format: | following format: | |||
uint32 id | uint32 id | |||
... any request-specific data ... | ... any request-specific data ... | |||
There is a range of packet types reserved for use by extensions. In | ||||
order to avoid collision, extensions that turn on the use of | ||||
additional packet types should determine those numbers dynamically. | ||||
The suggested way of doing this is have an extension request from the | ||||
client to the server that enables the extension; the extension | ||||
response from the server to the client would specify the actual type | ||||
values to use, in additional to any other data. | ||||
Extension authors should be mindful of the limited range of packet | ||||
types available (there are only 45 values available) and avoid | ||||
requiring a new packet type where possible. | ||||
9. Security Considerations | 9. Security Considerations | |||
This protocol assumes that it is run over a secure channel and that | This protocol assumes that it is run over a secure channel and that | |||
the endpoints of the channel have been authenticated. Thus, this | the endpoints of the channel have been authenticated. Thus, this | |||
protocol assumes that it is externally protected from network-level | protocol assumes that it is externally protected from network-level | |||
attacks. | 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 [6]. | protocol, typically using the SSH User Authentication Protocol [8]. | |||
Care must be taken in the server implementation to check the validity | Care must be taken in the server implementation to check the validity | |||
of 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 SSH File Transfer Protocol has changed over time, before it's | The SSH File Transfer Protocol has changed over time, before it's | |||
standardization. The following is a description of the incompatible | standardization. The following is a description of the incompatible | |||
changes between different versions. | changes between different versions. | |||
10.1 Changes between versions 3 and 2 | 10.1 Changes between versions 4 and 3 | |||
Many of the changes between version 4 and version 3 are to the | ||||
attribute structure to make it more flexible for non-unix platforms. | ||||
o Make all filenames UTF-8. | ||||
o Added 'newline' extension. | ||||
o Made file attribute owner and group strings so they can actually | ||||
be used on disparate systems. | ||||
o Added createtime field, and added separate flags for atime, | ||||
createtime, and mtime so they can be set separately. | ||||
o Split the file type out of the permissions field and into it's own | ||||
field (which is always present.) | ||||
o Added acl attribute. | ||||
o Added SSH_FXF_TEXT file open flag. | ||||
o Added flags field to the get stat commands so that the client can | ||||
specifically request information the server might not normally | ||||
included for performance reasons. | ||||
o Removed the long filename from the names structure-- it can now be | ||||
built from information available in the attrs structure. | ||||
o Added reserved range of packet numbers for extensions. | ||||
o Added several additional error codes. | ||||
o Change the way version negotiate works slightly. Previously, if | ||||
the client version were higher than the server version, the server | ||||
was supposed to 'echo back' the clients version. The server now | ||||
sends it's own version and the lower of the two is considered to | ||||
be the one in use. | ||||
10.2 Changes between versions 3 and 2 | ||||
o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added. | o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added. | |||
o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were | o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were | |||
added. | added. | |||
o The SSH_FXP_STATUS message was changed to include fields `error | o The SSH_FXP_STATUS message was changed to include fields `error | |||
message' and `language tag'. | message' and `language tag'. | |||
10.2 Changes between versions 2 and 1 | 10.3 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.4 Changes between versions 1 and 0 | |||
o Implementation changes, no actual protocol changes. | o Implementation changes, no actual protocol changes. | |||
11. Trademark Issues | 11. Trademark Issues | |||
"ssh" is a registered trademark of SSH Communications Security Corp | "ssh" is a registered trademark of SSH Communications Security Corp | |||
in the United States and/or other countries. | in the United States and/or other countries. | |||
References | References | |||
[1] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and | [1] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and | |||
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January | P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January | |||
1999. | 1999. | |||
[2] Institute of Electrical and Electronics Engineers, "Information | [2] Alvestrand, H., "IETF Policy on Character Sets and Languages", | |||
BCP 18, RFC 2277, January 1998. | ||||
[3] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, | ||||
C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC | ||||
3010, December 2000. | ||||
[4] Institute of Electrical and Electronics Engineers, "Information | ||||
Technology - Portable Operating System Interface (POSIX) - Part | Technology - Portable Operating System Interface (POSIX) - Part | |||
1: System Application Program Interface (API) [C Language]", | 1: System Application Program Interface (API) [C Language]", | |||
IEEE Standard 1003.2, 1996. | IEEE Standard 1003.2, 1996. | |||
[3] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | [5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | |||
Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh- | Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh- | |||
architecture-09 (work in progress), July 2001. | architecture-13 (work in progress), September 2002. | |||
[4] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | |||
Lehtinen, "SSH Protocol Transport Protocol", draft-ietf-secsh- | Lehtinen, "SSH Protocol Transport Protocol", draft-ietf-secsh- | |||
architecture-09 (work in progress), July 2001. | transport-15 (work in progress), September 2002. | |||
[5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | [7] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | |||
Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-11 | Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-16 | |||
(work in progress), July 2001. | (work in progress), September 2002. | |||
[6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | [8] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | |||
Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh- | Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh- | |||
userauth-11 (work in progress), July 2001. | userauth-16 (work in progress), September 2002. | |||
Authors' Addresses | Authors' Addresses | |||
Joseph Galbraith | ||||
VanDyke Software | ||||
4848 Tramway Ridge Blvd | ||||
Suite 101 | ||||
Albuquerque, NM 87111 | ||||
US | ||||
Phone: +1 505 332 5700 | ||||
EMail: galb-list@vandyke.com | ||||
Tatu Ylonen | Tatu Ylonen | |||
SSH Communications Security Corp | SSH Communications Security Corp | |||
Fredrikinkatu 42 | Fredrikinkatu 42 | |||
HELSINKI FIN-00100 | HELSINKI FIN-00100 | |||
Finland | Finland | |||
EMail: ylo@ssh.com | EMail: ylo@ssh.com | |||
Sami Lehtinen | Sami Lehtinen | |||
SSH Communications Security Corp | SSH Communications Security Corp | |||
Fredrikinkatu 42 | Fredrikinkatu 42 | |||
HELSINKI FIN-00100 | HELSINKI FIN-00100 | |||
Finland | Finland | |||
EMail: sjl@ssh.com | EMail: sjl@ssh.com | |||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The Internet Society (2001). All Rights Reserved. | Copyright (C) The Internet Society (2002). All Rights Reserved. | |||
This document and translations of it may be copied and furnished to | This document and translations of it may be copied and furnished to | |||
others, and derivative works that comment on or otherwise explain it | others, and derivative works that comment on or otherwise explain it | |||
or assist in its implementation may be prepared, copied, published | or assist in its implementation may be prepared, copied, published | |||
and distributed, in whole or in part, without restriction of any | and distributed, in whole or in part, without restriction of any | |||
kind, provided that the above copyright notice and this paragraph are | kind, provided that the above copyright notice and this paragraph are | |||
included on all such copies and derivative works. However, this | included on all such copies and derivative works. However, this | |||
document itself may not be modified in any way, such as by removing | document itself may not be modified in any way, such as by removing | |||
the copyright notice or references to the Internet Society or other | the copyright notice or references to the Internet Society or other | |||
Internet organizations, except as needed for the purpose of | Internet organizations, except as needed for the purpose of | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |