--- 1/draft-ietf-secsh-filexfer-00.txt 2006-02-05 01:34:07.000000000 +0100 +++ 2/draft-ietf-secsh-filexfer-01.txt 2006-02-05 01:34:07.000000000 +0100 @@ -1,16 +1,16 @@ Network Working Group T. Ylonen and S. Lehtinen 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 This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -22,88 +22,93 @@ "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract -The SSH File Transfer Protocol provides secure file transfer functional- -ity over any reliable data stream. It is the standard file transfer -protocol for use with the SSH2 protocol. This document describes the -file transfer protocol and its interface to the SSH2 protocol suite. +The Secure Shell File Transfer Protocol provides secure file transfer +functionality over any reliable data stream. It is the standard file +transfer protocol for use with the Secure Shell Remote Login Protocol. +This document describes the file transfer protocol and its interface to +the Secure Shell protocol suite. Table of Contents 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 4. Protocol Initialization . . . . . . . . . . . . . . . . . . . . 4 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . . 5 -6. Requests From the Client to the Server . . . . . . . . . . . . . 6 - 6.1. Request Synchronization and Reordering . . . . . . . . . . . 7 - 6.2. File Names . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 6.3. Opening, Creating, and Closing Files . . . . . . . . . . . . 8 - 6.4. Reading and Writing . . . . . . . . . . . . . . . . . . . . 9 - 6.5. Removing and Renaming Files . . . . . . . . . . . . . . . . 10 - 6.6. Creating and Deleting Directories . . . . . . . . . . . . . 10 - 6.7. Scanning Directories . . . . . . . . . . . . . . . . . . . . 11 - 6.8. Retrieving File Attributes . . . . . . . . . . . . . . . . . 12 - 6.9. Setting File Attributes . . . . . . . . . . . . . . . . . . 12 - 6.10. Canonicalizing the Server-Side Path Name . . . . . . . . . 13 -7. Responses from the Server to the Client . . . . . . . . . . . . 13 -8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . . . 16 -9. Security Considerations . . . . . . . . . . . . . . . . . . . . 17 -10. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 17 -11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 -12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 +6. Responses from the Server to the Client . . . . . . . . . . . . 6 +7. Requests From the Client to the Server . . . . . . . . . . . . . 9 + 7.1. Request Synchronization and Reordering . . . . . . . . . . . 10 + 7.2. File Names . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.3. Opening, Creating, and Closing Files . . . . . . . . . . . . 11 + 7.4. Reading and Writing . . . . . . . . . . . . . . . . . . . . 12 + 7.5. Removing and Renaming Files . . . . . . . . . . . . . . . . 13 + 7.6. Creating and Deleting Directories . . . . . . . . . . . . . 14 + 7.7. Scanning Directories . . . . . . . . . . . . . . . . . . . . 14 + 7.8. Retrieving File Attributes . . . . . . . . . . . . . . . . . 15 + 7.9. Setting File Attributes . . . . . . . . . . . . . . . . . . 16 + 7.10. Dealing with Symbolic links . . . . . . . . . . . . . . . . 16 + 7.11. Canonicalizing the Server-Side Path Name . . . . . . . . . 17 +8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . . . 17 +9. Security Considerations . . . . . . . . . . . . . . . . . . . . 18 +10. Changes from previous protocol versions . . . . . . . . . . . . 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 This protocol provides secure file transfer (and more generally file 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 remote file system service, as well as a secure file transfer service. This protocol assumes that it runs over a secure channel, and that the server has already authenticated the user at the client end, and that the identity of the client user is externally available to the server implementation. In general, this protocol follows a simple request-response model. Each request and response contains a sequence number and multiple requests may be pending simultaneously. There are a relatively large number of different request messages, but a small number of possible response messages. Each request has one or more response messages that may be returned in result (e.g., a read either returns data or reports error status). The packet format descriptions in this specification follow the notation -presented in [SSH-ARCH]. - -Even though this protocol is described in the context of the SSH2 +presented in [SECSH-ARCH]. -protocol, this protocol is general and independent of the rest of the -SSH2 protocol suite. It could be used in a number of different -applications, such as secure file transfer over TLS [RFC-2246] and -transfer of management information in VPN applications. +Even though this protocol is described in the context of the Secure +Shell Remote Login Protocol, this protocol is general and independent of +the rest of the Secure Shell protocol suite. It could be used in a +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 -used from the SSH Connection Protocol as a subsystem, as described in -[SSH-CONN], Section ``Starting a Shell or a Command''. The subsystem -name used with this protocol is "sftp". +When used with the Secure Shell protocol suite, this protocol is +intended to be used from the Secure Shell Connection Protocol as a +subsystem, as described in [SECSH-CONN], Section ``Starting a Shell or a +Command''. The subsystem name used with this protocol is "sftp". 3. General Packet Format All packets transmitted over the secure connection are of the following format: uint32 length byte type byte[length - 1] data payload @@ -146,20 +151,22 @@ #define SSH_FXP_SETSTAT 9 #define SSH_FXP_FSETSTAT 10 #define SSH_FXP_OPENDIR 11 #define SSH_FXP_READDIR 12 #define SSH_FXP_REMOVE 13 #define SSH_FXP_MKDIR 14 #define SSH_FXP_RMDIR 15 #define SSH_FXP_REALPATH 16 #define SSH_FXP_STAT 17 #define SSH_FXP_RENAME 18 + #define SSH_FXP_READLINK 19 + #define SSH_FXP_SYMLINK 20 #define SSH_FXP_STATUS 101 #define SSH_FXP_HANDLE 102 #define SSH_FXP_DATA 103 #define SSH_FXP_NAME 104 #define SSH_FXP_ATTRS 105 #define SSH_FXP_EXTENDED 200 #define SSH_FXP_EXTENDED_REPLY 201 Additional packet types should only be defined if the protocol version number (see Section ``Protocol Initialization'') is incremented, and @@ -234,33 +240,34 @@ uint32 extended_count present only if flag SSH_FILEXFER_ATTR_EXTENDED string extended_type string extended_data ... more extended data (extended_type - extended_data pairs), so that number of pairs equals extended_count The `flags' specify which of the fields are present. Those fields for which the corresponding flag is not set are not present (not included in the packet). New flags can only be added by incrementing the protocol + version number (or by using the extension mechanism described below). The `size' field specifies the size of the file in bytes. The `uid' and `gid' fields contain numeric Unix-like user and group - identifiers, respectively. The `permissions' field contains a bit mask of file permissions as defined by [POSIX]. 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 mechanism for vendor-specific extensions. If the flag is specified, then the `extended_count' field is present. It specifies the number of extended_type-extended_data pairs that follow. Each of these pairs specifies an extended attribute. For each of the attributes, the extended_type field should be a string of the format "name@domain", where "domain" is a valid, registered domain name and "name" identifies the method. The IETF may later standardize certain names that deviate from this format (e.g., that do not contain the "@" sign). The @@ -277,23 +284,192 @@ if a packet with unsupported protocol bits is received. The flags bits are defined to have the following values: #define SSH_FILEXFER_ATTR_SIZE 0x00000001 #define SSH_FILEXFER_ATTR_UIDGID 0x00000002 #define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004 #define SSH_FILEXFER_ATTR_ACMODTIME 0x00000008 #define SSH_FILEXFER_ATTR_EXTENDED 0x80000000 -6. 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 + operations. Each request begins with an `id' field, which is a 32-bit identifier identifying the request (selected by the client). The same identifier will be returned in the response to the request. One possible implementation of it is a monotonically increasing request sequence number (modulo 2^32). Many operations in the protocol operate on open files. The SSH_FXP_OPEN request can return a file handle (which is an opaque variable-length string) which may be used to access the file later (e.g. in a read operation). The client MUST NOT send requests the server with bogus or @@ -301,40 +477,40 @@ handle in order to avoid security risks due to fabricated handles. This design allows either stateful and stateless server implementation, as well as an implementation which caches state between requests but may also flush it. The contents of the file handle string are entirely up to the server and its design. The client should not modify or attempt to interpret the file handle strings. The file handle strings MUST NOT be longer than 256 bytes. -6.1. Request Synchronization and Reordering +7.1. Request Synchronization and Reordering The protocol and implementations MUST process requests relating to the same file in the order in which they are received. In other words, if an application submits multiple requests to the server, the results in the responses will be the same as if it had sent the requests one at a time and waited for the response in each case. For example, the server may process non-overlapping read/write requests to the same file in parallel, but overlapping reads and writes cannot be reordered or parallelized. However, there are no ordering restrictions on the server for processing requests from two different file transfer connections. The server may interleave and parallelize them at will. There are no restrictions on the order in which responses to outstanding requests are delivered to the client, except that the server must ensure fairness in the sense that processing of no request will be indefinitely delayed even if the client is sending other requests so that there are multiple outstanding requests all the time. -6.2. File Names +7.2. File Names This protocol represents file names as strings. File names are assumed to use the slash ('/') character as a directory separator. 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 relative to the user's default directory (home directory). Note that identifying the user is assumed to take place outside of this protocol. Servers SHOULD interpret a path name component ".." as referring to the @@ -346,28 +523,27 @@ An empty path name is valid, and it refers to the user's default directory (usually the user's home directory). Otherwise, no syntax is defined for file names by this specification. Clients should not make any other assumptions; however, they can splice path name components returned by SSH_FXP_READDIR together using a slash ('/') as the separator, and that will work as expected. It is understood that the lack of well-defined semantics for file names - may cause interoperability problems between clients and servers using radically different operating systems. However, this approach is known to work acceptably with most systems, and alternative approaches that e.g. treat file names as sequences of structured components are quite 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 part is as follows: uint32 id string filename uint32 pflags ATTRS attrs The `id' field is the request identifier as for all requests. @@ -423,26 +599,27 @@ A file is closed by using the SSH_FXP_CLOSE request. Its data field has the following format: uint32 id string handle 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 handle becomes invalid immediately after this request has been sent. + 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 can happen e.g. if the server operating system caches writes, and an 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 message, which has the following format: uint32 id string handle uint64 offset uint32 len where `id' is the request identifier, `handle' is an open file handle @@ -471,21 +649,21 @@ 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. 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 then the data. On most operating systems, such writes do not allocate disk space but instead leave "holes" in the file. 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 following format: uint32 id string filename where `id' is the request identifier and `filename' is the name of the file to be removed. See Section ``File Names'' for more information. This request cannot be used to remove directories. @@ -501,48 +679,51 @@ 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 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 situations, for example if `oldpath' and `newpath' point to different file systems on the server. The server will respond to this request with a SSH_FXP_STATUS message. -6.6. Creating and Deleting Directories +7.6. Creating and Deleting Directories New directories can be created using the SSH_FXP_MKDIR request. It has the following format: uint32 id string path + ATTRS attrs -where `id' is the request identifier and `path' specifies the directory -to be created. See Section ``File Names'' for more information on file -names. An error will be returned if a file or directory with the speci- -fied path already exists. The server will respond to this request with -a SSH_FXP_STATUS message. +where `id' is the request identifier, `path'and `attrs' specifies the +modifications to be made to its attributes. See Section ``File Names'' +for more information on file names. Attributes are discussed in more +detail in Section ``File Attributes''. specifies 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 has the following format: uint32 id string path where `id' is the request identifier, and `path' specifies the directory to be removed. See Section ``File Names'' for more information on file names. An error will be returned if no directory with the specified path exists, or if the specified directory is not empty, or if the path specified a file system object other than a directory. The server 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 SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one or more file names with full file attributes for each file. The client should call SSH_FXP_READDIR repeatedly until it has found the file it is looking for or until the server responds with a SSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF if there are no more files in the directory). The client should then close the handle using the SSH_FXP_CLOSE request. @@ -573,21 +753,21 @@ The server responds to this request with either a SSH_FXP_NAME or a SSH_FXP_STATUS message. One or more names may be returned at a time. Full status information is returned for each name in order to speed up typical directory listings. When the client no longer wishes to read more names from the directory, it SHOULD call SSH_FXP_CLOSE for the handle. The handle should be closed regardless of whether an error has occurred or not. -6.8. Retrieving File Attributes +7.8. Retrieving File Attributes Very often, file attributes are automatically returned by SSH_FXP_READDIR. However, sometimes there is need to specifically 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 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. Both have the same format: @@ -602,21 +782,21 @@ information for an open file (identified by the file handle). Its format is as follows: uint32 id string 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 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 SSH_FXP_FSETSTAT requests. These requests are used for operations such as changing the ownership, permissions or access times, as well as for truncating a file. The SSH_FXP_SETSTAT request is of the following format: uint32 id string path @@ -638,200 +818,64 @@ uint32 id string handle ATTRS attrs where `id' is the request identifier, `handle' (MUST be returned by SSH_FXP_OPEN) identifies the file whose attributes are to be modified, and `attrs' specifies the modifications to be made to its attributes. Attributes are discussed in more detail in Section ``File Attributes''. 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 -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: +The SSH_FXP_READLINK request may be used to read the target of a +symbolic link. It would have a data part as follows: uint32 id string path where `id' is the request identifier and `path' specifies the path name -to be canonicalized. The server will respond with a SSH_FXP_NAME packet -containing only one name 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 +of the symlink to be read. -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 server will respond with a SSH_FXP_NAME packet containing only one +name and a dummy attributes value. The name in the returned packet +contains the target of the link. If an error occurs, the server may +respond with SSH_FXP_STATUS. -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 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: + string linkpath + string targetpath --rwxr-xr-x 1 mjos staff 348911 Mar 25 14:29 t-filexfer -1234567890 123 12345678 12345678 12345678 123456789012 +where `id' is the request identifier, `linkpath' specifies the path name +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 -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. +7.11. Canonicalizing the Server-Side Path Name -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 - ATTRS attrs + string path -where `id' is the request identifier, and `attrs' is the returned file -attributes as described in Section ``File Attributes''. +where `id' is the request identifier and `path' specifies the path name +to be canonicalized. The server will respond with a SSH_FXP_NAME packet +containing only one name 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 The SSH_FXP_EXTENDED request provides a generic extension mechanism for adding vendor-specific commands. The request has the following format: uint32 id string extended-request ... any request-specific data ... @@ -860,63 +904,78 @@ This protocol assumes that it is run over a secure channel and that the endpoints of the channel have been authenticated. Thus, this protocol assumes that it is externally protected from network-level attacks. This protocol provides file system access to arbitrary files on the server (only constrained by the server implementation). It is the responsibility of the server implementation to enforce any access controls that may be required to limit the access allowed for any particular user (the user being authenticated externally to this -protocol, typically using the SSH User Authentication Protocol [SSH- -USERAUTH]. +protocol, typically using the Secure Shell User Authentication Protocol +[SECSH-USERAUTH]. Care must be taken in the server implementation to check the validity of received file handle strings. The server should not rely on them directly; it MUST check the validity of each handle before relying on it. -10. Trademark Issues +10. Changes from previous protocol versions -SSH is a registered trademark and Secure Shell is a trademark of SSH -Communications Security Corp. SSH Communications Security Corp permits -the use of these trademarks as the name of this standard and protocol, -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. +The Secure Shell File Transfer Protocol has changed over time, before +it's standardization. The following is a description of the +incompatible changes between different versions. -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", January 1999 [POSIX] ISO/IEC Std 9945-1, ANSI/IEEE Std 1003.1 Information technology -- Portable Operating System Interface (POSIX)-Part 1: System Application Program Interface (API) [C Language], July 1996. -[SSH-ARCH] Ylonen, T., et al: "SSH Protocol Architecture", Internet- -Draft, draft-ietf-secsh-architecture-07.txt +[SECSH-ARCH] Ylonen, T., et al: "Secure Shell Protocol Architecture", +Internet-Draft, draft-ietf-secsh-architecture-08.txt -[SSH-TRANSPORT] Ylonen, T., et al: "SSH Transport Protocol", Internet- -Draft, draft-ietf-secsh-transport-09.txt +[SECSH-TRANSPORT] Ylonen, T., et al: "Secure Shell Transport Protocol", +Internet-Draft, draft-ietf-secsh-transport-10.txt -[SSH-USERAUTH] Ylonen, T., et al: "SSH Authentication Protocol", -Internet-Draft, draft-ietf-secsh-userauth-09.txt +[SECSH-USERAUTH] Ylonen, T., et al: "Secure Shell Authentication +Protocol", Internet-Draft, draft-ietf-secsh-userauth-10.txt -[SSH-CONNECT] Ylonen, T., et al: "SSH Connection Protocol", Internet- -Draft, draft-ietf-secsh-connect-09.txt +[SECSH-CONNECT] Ylonen, T., et al: "Secure Shell Connection Protocol", +Internet-Draft, draft-ietf-secsh-connect-10.txt -12. Authors' Addresses +13. Authors' Addresses Tatu Ylonen SSH Communications Security Corp Fredrikinkatu 42 FIN-00100 HELSINKI Finland E-mail: ylo@ssh.com Sami Lehtinen SSH Communications Security Corp