Network Working Group T. Ylonen and S. Lehtinen INTERNET-DRAFT SSH Communications Security Expires:9 July,2 September, 2001SSHSecure 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. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "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 TheSSHSecure Shell File Transfer Protocol provides secure file transferfunctional- ityfunctionality over any reliable data stream. It is the standard file transfer protocol for use with theSSH2 protocol.Secure Shell Remote Login Protocol. This document describes the file transfer protocol and its interface to theSSH2Secure Shell protocol suite. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Use with theSSHSecure Shell Connection Protocol . . . . . . . . .. . . . .3 3. General Packet Format . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Initialization . . . . . . . . . . . . . . . . . . . . 4 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Responses from the Server to the Client . . . . . . . . . . . . 6 7. Requests From the Client to the Server . . . . . . . . . . . . .6 6.1.9 7.1. Request Synchronization and Reordering . . . . . . . . . . .7 6.2.10 7.2. File Names . . . . . . . . . . . . . . . . . . . . . . . . .7 6.3.10 7.3. Opening, Creating, and Closing Files . . . . . . . . . . . .8 6.4.11 7.4. Reading and Writing . . . . . . . . . . . . . . . . . . . .9 6.5.12 7.5. Removing and Renaming Files . . . . . . . . . . . . . . . .10 6.6.13 7.6. Creating and Deleting Directories . . . . . . . . . . . . .10 6.7.14 7.7. Scanning Directories . . . . . . . . . . . . . . . . . . . .11 6.8.14 7.8. Retrieving File Attributes . . . . . . . . . . . . . . . . .12 6.9.15 7.9. Setting File Attributes . . . . . . . . . . . . . . . . . .12 6.10. Canonicalizing the Server-Side Path Name16 7.10. Dealing with Symbolic links . . . . . . . . . .13 7. Responses from the Server to the Client. . . . . . 16 7.11. Canonicalizing the Server-Side Path Name . . . . . .13. . . 17 8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . . .1617 9. Security Considerations . . . . . . . . . . . . . . . . . . . .1718 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 . . . . . . . . . . . . . . . . . . . . . . .17 11.18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . .17 12.19 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .1819 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 theSSH2 protocol [SSH-ARCH].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].[SECSH-ARCH]. Even though this protocol is described in the context of theSSH2 protocol,Secure Shell Remote Login Protocol, this protocol is general and independent of the rest of theSSH2Secure 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 theSSHSecure Shell Connection Protocol When used with theSSH2 ProtocolSecure Shell protocol suite, this protocol is intended to be used from theSSHSecure Shell Connection Protocol as a subsystem, as described in[SSH-CONN],[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 That is, they are just data preceded by 32-bit length and 8-bit type fields. The `length' is the length of the data area, and does not include the `length' field itself. The format and interpretation of the data area depends on the packet type. All packet descriptions below only specify the packet type and the data that goes into the data field. Thus, they should be prefixed by the `length' and `type' fields. The maximum size of a packet is in practise determined by the client (the maximum size of read or write requests that it sends, plus a few bytes of packet overhead). All servers SHOULD support packets of at least 34000 bytes (where the packet size refers to the full length, including the header above). This should allow for reads and writes of at most 32768 bytes. There is no limit on the number of outstanding (non-acknowledged) requests that the client may send to the server. In practise this is limited by the buffering available on the data stream and the queuing performed by the server. If the server's queues are full, it should not read any more data from the stream, and flow control will prevent the client from sending more requests. Note, however, that while there is no restriction on the protocol level, the client's API may provide a limit in order to prevent infinite queueing of outgoing requests at the client. The following values are defined for packet types. #define SSH_FXP_INIT 1 #define SSH_FXP_VERSION 2 #define SSH_FXP_OPEN 3 #define SSH_FXP_CLOSE 4 #define SSH_FXP_READ 5 #define SSH_FXP_WRITE 6 #define SSH_FXP_LSTAT 7 #define SSH_FXP_FSTAT 8 #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 their use MUST be negotiated using the version number. However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY packets can be used to implement vendor-specific extensions. See Section ``Vendor-Specific Extensions'' for more details. 4. Protocol Initialization When the file transfer protocol starts, it first sends a SSH_FXP_INIT (including its version number) packet to the server. The server responds with a SSH_FXP_VERSION packet, supplying the lowest of its own and the client's version number. Both parties should from then on adhere to particular version of the protocol. The SSH_FXP_INIT packet (from client to server) has the following data: uint32 version <extension data> The SSH_FXP_VERSION packet (from server to client) has the following data: uint32 version <extension data> The version number of the protocol specified in this document is 3. The version number should be incremented for each incompatible revision of this protocol. The extension data in the above packets may be empty, or may be a sequence of string extension_name string extension_data pairs (both strings MUST always be present if one is, but the `exten- sion_data' string may be of zero length). If present, these strings indicate extensions to the baseline protocol. 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 domain name of the orga- nization defining the extension. Additional names that are not of this format may be defined later by the IETF. Implementations MUST silently ignore any extensions whose name they do not recognize. 5. File Attributes A new compound data type is defined for encoding file attributes. It is basically just a combination of elementary types, but is defined once because of the non-trivial description of the fields and to ensure maintainability. The same encoding is used both when returning file attributes from the server and when sending file attributes to the server. When sending it to the server, the flags field specifies which attributes are included, and the server will use default values for the remaining attributes (or will not modify the values of remaining attributes). When receiving attributes from the server, the flags specify which attributes are included in the returned data. The server normally returns all attributes it knows about. uint32 flags uint64 size present only if flag SSH_FILEXFER_ATTR_SIZE uint32 uid present only if flag SSH_FILEXFER_ATTR_UIDGID uint32 gid present only if flag SSH_FILEXFER_ATTR_UIDGID uint32 permissions present only if flag SSH_FILEXFER_ATTR_PERMISSIONS uint32 atime present only if flag SSH_FILEXFER_ACMODTIME uint32 mtime present only if flag SSH_FILEXFER_ACMODTIME 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.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 interpretation of `extended_data' depends on the type. Implementations SHOULD ignore extended data fields that they do not understand. Additional fields can be added to the attributes by either defining additional bits to the flags field to indicate their presence, or by defining extended attributes for them. The extended attributes mechanism is recommended for most purposes; additional flags bits should only be defined by an IETF standards action that also increments the protocol version number. The use of such new fields MUST be negotiated by the version number in the protocol exchange. It is a protocol error 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 RequestsResponses from theclientServer to theserver 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).Client Thesame identifier will be returned in the responseserver responds to therequest. One possible implementationclient using one ofit isamonotonically increasing request sequence number (modulo 2^32). Many operations in the protocol operate on open files. The SSH_FXP_OPEN requestfew response packets. All requests can return afile handle (whichSSH_FXP_STATUS response upon failure. When the operation isan opaque variable-length string) whichsuccessful, any of the responses may beused to accessreturned (depending on thefile later (e.g. in a readoperation).The client MUST NOT send requestsIf no data needs to be returned to theserver with bogus or closed handles. However,client, theserver MUST perform adequate checks onSSH_FXP_STATUS response with SSH_FX_OK status is appropriate. Otherwise, thehandle in order to avoid security risks dueSSH_FXP_HANDLE message is used tofabricated 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 thereturn a file handlestring are entirely up to the server(for SSH_FXP_OPEN andits design. The client should not modify or attemptSSH_FXP_OPENDIR requests), SSH_FXP_DATA is used tointerpret the file handle strings. Thereturn data from SSH_FXP_READ, SSH_FXP_NAME is used to return one or more filehandle strings MUST NOT be longer than 256 bytes. 6.1. Request Synchronization and Reordering The protocolnames from a SSH_FXP_READDIR or SSH_FXP_REALPATH request, andimplementations MUST process requests relatingSSH_FXP_ATTRS is used tothe samereturn filein the order inattributes 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 whichthey are received. In other words, if an application submits multiple requestscan be used to match each response with theserver,corresponding request. Note that it is legal to have several requests outstanding simultaneously, and theresultsserver is allowed to send responses to them in a different order from theresponses will beorder in which thesamerequests were sent (the result of their execution, however, is guaranteed to be as ifitthey hadsent the requestsbeen processed one at a timeand waited for the response in each case. For example, the server may process non-overlapping read/write requests to the same fileinparallel, 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 onthe order in whichresponses to outstandingthe requests were sent). Response packets aredelivered toof theclient, except thatsame general format as request packets. Each response packet begins with theserver must ensure fairness inrequest identifier. The format of thesense that processingdata portion ofno request will be indefinitely delayed even iftheclientSSH_FXP_STATUS response issending other requests so that there are multiple outstanding requests all the time. 6.2. File Names This protocol represents file namesasstrings. File names are assumed to usefollows: 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 theslash ('/') character as a directory separator. File names starting with a slash are "absolute",request identifier, andare relative to`error/status code' indicates therootresult of thefile system. Names starting with anyrequested operation. The value SSH_FX_OK indicates success, and all othercharacter are relative to the user's defaultvalues 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(home directory). Noteon 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 thatidentifyingall three fields are first included for theuserfirst file, then for the second file, etc). In the repeated part, `filename' isassumeda 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 totake place outsidewhat 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.Servers SHOULD interpretIt MUST be suitable for use in the output of apath name component ".." as referringdirectory 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 theparent directory,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"." as referring toothers; thecurrent directory. Ifsec- ond field is link count; theserver implementation limits access to certain parts ofthird field is thefile system, it must be extra careful in parsing file names when enforcing such restrictions. There have been numerous reported security bugs where a ".." in a pathnamehas allowed access outsideof theintended area. An empty path name is valid, and it refers touser who owns theuser's default directory (usuallyfile; theuser's home directory). Otherwise, no syntaxfourth field isdefined for file names by this specification. Clients should not make any other assumptions; however, they can splice paththe namecomponents returned by SSH_FXP_READDIR together using a slash ('/') asof theseparator, andgroup thatwill work as expected. Itowns the file; the fifth field isunderstood thatthelacksize ofwell-defined semantics forthe filenamesin bytes; the sixth field (which actually maycause interoperability problems between clients and servers using radically different operating systems. However, this approachcontain spaces, but isknownfixed towork acceptably with most systems,12 characters) is the file modification time, andalternative approaches that e.g. treatthe seventh field is the filenames as sequencesname. Each field is specified to be a minimum ofstructured components are quite complicated. 6.3. Opening, Creating, and Closing Files Files are opened and created usingcertain number of character positions (indicated by the second line above), but may also be longer if theSSH_FXP_OPEN message, whosedatapart is as follows:does not fit in the specified length. The SSH_FXP_ATTRS response has the following format: uint32 idstring filename uint32 pflagsATTRS attrsThewhere `id'fieldis the requestidentifier as for all requests. The `filename' field specifiesidentifier, and `attrs' is the returned filename. Seeattributes as described in Section ``FileNames'' for more information. The `pflags' field is a bitmask. The following bits have been defined. #define SSH_FXF_READ 0x00000001 #define SSH_FXF_WRITE 0x00000002 #define SSH_FXF_APPEND 0x00000004 #define SSH_FXF_CREAT 0x00000008 #define SSH_FXF_TRUNC 0x00000010 #define SSH_FXF_EXCL 0x00000020 These haveAttributes''. 7. Requests From thefollowing meanings: SSH_FXF_READ OpenClient to thefile for reading. SSH_FXF_WRITE OpenServer Requests from thefile for writing. If both this and SSH_FXF_READ are specified,client to the server represent the various file system operations. Each request begins with an `id' field, which isopened for both reading and writing. SSH_FXF_APPEND Force all writesa 32-bit identifier identifying the request (selected by the client). The same identifier will be returned in the response toappend data attheendrequest. One possible implementation ofthe file. SSH_FXF_CREAT If this flagit isspecified, thenanewmonotonically increasing request sequence number (modulo 2^32). Many operations in the protocol operate on open files. The SSH_FXP_OPEN request can return a filewill be created if one does not alread exist (if O_TRUNChandle (which isspecified,an opaque variable-length string) which may be used to access the file later (e.g. in a read operation). The client MUST NOT send requests the server with bogus or closed handles. However, the server MUST perform adequate checks on the handle in order to avoid security risks due to fabricated handles. This design allows either stateful and stateless server implementation, as well as an implementation which caches state between requests but may also flush it. The contents of thenewfilewill be truncatedhandle string are entirely up tozero length if it previously exists). SSH_FXF_TRUNC Forces an existing file withthesame name to be truncatedserver and its design. The client should not modify or attempt tozero length when creating ainterpret the fileby specifying SSH_FXF_CREAT. SSH_FXF_CREAThandle strings. The file handle strings MUSTalsoNOT bespecified if this flag is used. SSH_FXF_EXCL Causes the requestlonger than 256 bytes. 7.1. Request Synchronization and Reordering The protocol and implementations MUST process requests relating tofail ifthenamedsame filealready exists. SSH_FXF_CREAT MUST also be specifiedin the order in which they are received. In other words, ifthis flag is used. The `attrs' field specifiesan application submits multiple requests to theinitial attributes forserver, thefile. Default valuesresults in the responses will beused for those attributes that are not specified. See Section ``File Attributes'' for more information. Regardlesstheserver operating system,same as if it had sent thefile will always be opened in "binary" mode (i.e., no translations between different character setsrequests one at a time andnewline encodings). Thewaited for the responseto this message will be either SSH_FXP_HANDLE (ifin each case. For example, theoperation is successful) or SSH_FXP_STATUS (ifserver may process non-overlapping read/write requests to theoperation fails). Asame fileis closed by using the SSH_FXP_CLOSE request. Its data field has the following format: uint32 id string handle where `id' isin parallel, but overlapping reads and writes cannot be reordered or parallelized. However, there are no ordering restrictions on therequest identifier,server for processing requests from two different file transfer connections. The server may interleave and`handle' is a handle previ- ously returned inparallelize them at will. There are no restrictions on theresponseorder in which responses toSSH_FXP_OPEN or SSH_FXP_OPENDIR. The handle becomes invalid immediately after this request has been sent. The responseoutstanding requests are delivered tothisthe client, except that the server must ensure fairness in the sense that processing of no request will bea SSH_FXP_STATUS message. One should note that on some server platformsindefinitely delayed evena close can fail. This can happen e.g.if theserver operating system caches writes, and an error occurs while flushing cached writes duringclient is sending other requests so that there are multiple outstanding requests all theclose. 6.4. Reading and Writing Once atime. 7.2. File Names This protocol represents filehas been opened, it can be read usingnames as strings. File names are assumed to use theSSH_FXP_READ message, which hasslash ('/') character as a directory separator. File names starting with a slash are "absolute", and are relative to thefollowing format: uint32 id string handle uint64 offset uint32 len where `id' isroot of therequest identifier, `handle' is an openfilehandle returned by SSH_FXP_OPEN, `offset' is the offset (in bytes)system. Names starting with any other character are relative to thebeginning of the file from where to start reading,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 parent directory, and`len' is the maximum number of bytes to read. In response"." as referring tothis request,the current directory. If the serverwill read as many bytes as it can fromimplementation limits access to certain parts of the file(up to `len'), and return themsystem, it must be extra careful in parsing file names when enforcing such restrictions. There have been numerous reported security bugs where a ".." in aSSH_FXP_DATA message. If an error occurs or EOF is encountered before reading any data,path name has allowed access outside theserver will respond with SSH_FXP_STATUS. For normal disk files, itintended area. An empty path name isguaranteed that this will read the specified number of bytes, or up to end of file. For e.g. device files this may return fewer bytes than requested. Writingvalid, and it refers toa file is achieved usingtheSSH_FXP_WRITE message, which hasuser's default directory (usually thefollowing format: uint32 id string handle uint64 offset string data where `id' is a request identifier, `handle'user's home directory). Otherwise, no syntax isadefined for filehandlenames by this specification. Clients should not make any other assumptions; however, they can splice path name components returned bySSH_FXP_OPEN, `offset' is the offset (in bytes) from the beginning ofSSH_FXP_READDIR together using a slash ('/') as thefile where to start writing,separator, and`data' is the data to be written. The writethat willextend the file if writing beyond the end of the file. It is legal to write way beyondwork as expected. It is understood that theendlack ofthe file; thewell-defined semanticsare to write zeroes from the end of thefor fileto the specified offsetnames may cause interoperability problems between clients andthen the data. On mostservers using radically different operatingsystems, such writes do not allocate disk space but instead leave "holes" in the file. The server respondssystems. However, this approach is known toa write requestwork acceptably witha SSH_FXP_STATUS message. 6.5. Removingmost systems, andRenamingalternative approaches that e.g. treat file names as sequences of structured components are quite complicated. 7.3. Opening, Creating, and Closing Files Filescan be removedare opened and created using theSSH_FXP_REMOVE message. It has the following format:SSH_FXP_OPEN message, whose data part is as follows: uint32 id string filenamewhereuint32 pflags ATTRS attrs The `id' field is the request identifierandas for all requests. The `filename'is the name offield specifies the fileto be removed.name. See Section ``File Names'' for more information.This request cannot be used to remove directories.Theserver will respond to this request with a SSH_FXP_STATUS message. Files (and directories) can be renamed using the SSH_FXP_RENAME message. Its data is as follows: uint32 id string oldpath string newpath where `id'`pflags' field is a bitmask. The following bits have been defined. #define SSH_FXF_READ 0x00000001 #define SSH_FXF_WRITE 0x00000002 #define SSH_FXF_APPEND 0x00000004 #define SSH_FXF_CREAT 0x00000008 #define SSH_FXF_TRUNC 0x00000010 #define SSH_FXF_EXCL 0x00000020 These have therequest identifier, `oldpath' isfollowing meanings: SSH_FXF_READ Open thename of an exist- ingfileor directory, and `newpath' is the new namefor reading. SSH_FXF_WRITE Open the fileor directory. It is an error if there already exists a file withfor writing. If both this and SSH_FXF_READ are specified, thename specified by newpath. The server may also fail rename requests in other situations,file is opened forexample if `oldpath'both reading and`newpath' pointwriting. SSH_FXF_APPEND Force all writes todifferent file systems onappend data at theserver. The server will respond toend of the file. SSH_FXF_CREAT If thisrequest withflag is specified, then aSSH_FXP_STATUS message. 6.6. Creating and Deleting Directories New directories cannew file will be createdusing the SSH_FXP_MKDIR request. It has the following format: uint32 id string path where `id'if one does not alread exist (if O_TRUNC is specified, therequest identifier and `path' specifies the directory to be created. See Section ``File Names'' for more information onnew filenames. An errorwill bereturnedtruncated to zero length ifait previously exists). SSH_FXF_TRUNC Forces an existing fileor directorywith thespeci- fied path already exists. The server will respondsame name tothis request withbe truncated to zero length when creating aSSH_FXP_STATUS message. Directories canfile by specifying SSH_FXF_CREAT. SSH_FXF_CREAT MUST also beremoved using the SSH_FXP_RMDIR request, which has the following format: uint32 id string path where `id'specified if this flag is used. SSH_FXF_EXCL Causes the requestidentifier, and `path'to fail if the named file already exists. SSH_FXF_CREAT MUST also be specified if this flag is used. The `attrs' field specifies thedirectory toinitial attributes for the file. Default values will beremoved.used for those attributes that are not specified. See Section ``FileNames''Attributes'' for moreinformation 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 ifinformation. Regardless the server operating system, thepath specified afilesystem object other than a directory.will always be opened in "binary" mode (i.e., no translations between different character sets and newline encodings). Theserver respondsresponse to thisrequest with a SSH_FXP_STATUS message. 6.7. Scanning Directories The files in a directory canmessage will belisted 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 foundeither SSH_FXP_HANDLE (if thefile itoperation islooking forsuccessful) oruntil the server responds with aSSH_FXP_STATUSmessage indicating an error (normally SSH_FX_EOF if there are no more files in the directory). The client should then close(if thehandleoperation fails). A file is closed by using the SSH_FXP_CLOSE request.The SSH_FXP_OPENDIR opens a directory for reading. ItIts data field has the following format: uint32 id stringpathhandle where `id' is the requestidentifieridentifier, and`path'`handle' is a handle previ- ously returned in thepath name of the directoryresponse tobe listed (without any trailing slash). See Section ``File Names'' for more information on file names. This will return an error if the path does not specify a directorySSH_FXP_OPEN orif the directory is not readable.SSH_FXP_OPENDIR. Theserver will respondhandle becomes invalid immediately after this request has been sent. The response to this requestwith either a SSH_FXP_HANDLE orwill be a SSH_FXP_STATUS message.OnceOne should note that on some server platforms even a close can fail. This can happen e.g. if thedirectoryserver operating system caches writes, and an error occurs while flushing cached writes during the close. 7.4. Reading and Writing Once a file has beensuccessfullyopened,files (and directories) contained init can belistedread usingSSH_FXP_READDIR requests. These are oftheformatSSH_FXP_READ message, which has the following format: uint32 id string handle uint64 offset uint32 len where `id' is the request identifier,and`handle' isa handle returned by SSH_FXP_OPENDIR. (It is a protocol error to attempt to useanordi- naryopen file handle returned bySSH_FXP_OPEN.) The server responds to this request with either a SSH_FXP_NAME or a SSH_FXP_STATUS message. One or more names may be returned at a time. Full status informationSSH_FXP_OPEN, `offset' isreturned for each name in order to speed up typical directory listings. Whentheclient no longer wishesoffset (in bytes) relative toread more names from the directory, it SHOULD call SSH_FXP_CLOSE forthehandle. The handle should be closed regardlessbeginning ofwhether an error has occurred or not. 6.8. Retrieving File Attributes Very often,the fileattributes are automatically returned by SSH_FXP_READDIR. However, sometimes therefrom where to start reading, and `len' isneedthe maximum number of bytes tospecifically retrieveread. In response to this request, theattributes for a named file. Thisserver will read as many bytes as it canbe done usingfrom theSSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests. SSH_FXP_STATfile (up to `len'), andSSH_FXP_LSTAT only differreturn them in a SSH_FXP_DATA message. If an error occurs or EOF is encountered before reading any data, the server will respond with SSH_FXP_STATUS. For normal disk files, it is guaranteed thatSSH_FXP_STAT follows symbolic links onthis will read theserver, whereas SSH_FXP_LSTAT does not follow symbolic links. Both havespecified number of bytes, or up to end of file. For e.g. device files this may return fewer bytes than requested. Writing to a file is achieved using thesameSSH_FXP_WRITE message, which has the following format: uint32 id stringpathhandle uint64 offset string data where `id' isthea request identifier,and `path' spefifies`handle' is a file handle returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the beginning of the filesys- tem object for which statuswhere to start writing, and `data' is the data to bereturned.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 tothisa write request witheither SSH_FXP_ATTRS or SSH_FXP_STATUS. SSH_FXP_FSTAT differs froma SSH_FXP_STATUS message. 7.5. Removing and Renaming Files Files can be removed using theothers in that it returns status information for an open file (identified bySSH_FXP_REMOVE message. It has thefile handle). Its format is as follows:following format: uint32 id stringhandlefilename where `id' is the request identifier and`handle'`filename' isathe name of the filehandle returned by SSH_FXP_OPEN.to be removed. See Section ``File Names'' for more information. This request cannot be used to remove directories. The serverrespondswill respond to this request withSSH_FXP_ATTRS or SSH_FXP_STATUS. 6.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 truncatingafile. The SSH_FXP_SETSTAT request is ofSSH_FXP_STATUS message. Files (and directories) can be renamed using thefollowing format:SSH_FXP_RENAME message. Its data is as follows: uint32 id stringpath ATTRS attrsoldpath string newpath where `id' is the request identifier,`path' specifies`oldpath' is thefile system object (e.g.name of an exist- ing file ordirectory) whose attributes are to be modified,directory, and`attrs' specifies`newpath' is themodifications to be made to its attributes. Attributes are discussed in more detail in Section ``File Attributes''. An error will be returned ifnew name for thespecifiedfilesystem object does not existor directory. It is an error if there already exists a file with theuser does not have sufficient rightsname specified by newpath. The server may also fail rename requests in other situations, for example if `oldpath' and `newpath' point tomodifydifferent file systems on thespecified attributes.server. The serverrespondswill respond to this request with a SSH_FXP_STATUS message.The SSH_FXP_FSETSTAT request modifies7.6. Creating and Deleting Directories New directories can be created using theattributes of a file which is already open.SSH_FXP_MKDIR request. It has the following format: uint32 id stringhandlepath 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`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 withSSH_FXP_STATUS. 6.10. Canonicalizing the Server-Side Path Name The SSH_FXP_REALPATH requesta SSH_FXP_STATUS message. Directories can beused 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 ofremoved using therequest is as follows:SSH_FXP_RMDIR request, which has the following format: uint32 id string path where `id' is the requestidentifieridentifier, and `path' specifies thepath namedirectory to becanonicalized. The server will respond with a SSH_FXP_NAME packet containing only one name and a dummy attributes value. The name is the returned packetremoved. See Section ``File Names'' for more information on file names. An error will bein canonical form. If an error occurs, the server may also respondreturned if no directory withSSH_FXP_STATUS. 7. Responses fromtheServer tospecified path exists, or if theClientspecified directory is not empty, or if the path specified a file system object other than a directory. The server responds tothe client using one of a few response packets. All requests can returnthis request with a SSH_FXP_STATUSresponse upon failure. When the operation is successful, any of the responses may be returned (depending on the operation). If no data needs tomessage. 7.7. Scanning Directories The files in a directory can bereturned to the client, the SSH_FXP_STATUS response with SSH_FX_OK status is appropriate. Otherwise,listed using theSSH_FXP_HANDLE message is used to return a file handle (for SSH_FXP_OPEN andSSH_FXP_OPENDIRrequests), SSH_FXP_DATA is used to return data from SSH_FXP_READ, SSH_FXP_NAME is used to returnand SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one or more file namesfrom a SSH_FXP_READDIR or SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is used to returnwith full file attributesfrom SSH_FXP_STAT, SSH_FXP_LSTAT, and SSH_FXP_FSTAT requests. Exactly one response will be returnedfor eachrequest. Each response packet contains a request identifier which can be used to match each response withfile. The client should call SSH_FXP_READDIR repeatedly until it has found thecorresponding request. Note thatfile it islegal to have several requests outstanding simultaneously, andlooking for or until the serveris allowed to send responses to them inresponds with adifferent order from the order in which the requests were sent (the result of their execution, however, is guaranteed to be asSSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF ifthey had been processed one at a time in the orderthere are no more files inwhichtherequests were sent). Response packets are ofdirectory). The client should then close thesame general format as request packets. Each response packet begins withhandle using therequest identifier.SSH_FXP_CLOSE request. Theformat of the data portion ofSSH_FXP_OPENDIR opens a directory for reading. It has theSSH_FXP_STATUS response is as follows:following format: uint32 iduint32 error/status codestring path where `id' is the requestidentifier,identifier and`error/status code' indicates`path' is theresultpath name of therequested operation.directory to be listed (without any trailing slash). See Section ``File Names'' for more information on file names. This will return an error if the path does not specify a directory or if the directory is not readable. Thevalue SSH_FX_OK indicates success, and all other values indicate failure. Currently,server will respond to this request with either a SSH_FXP_HANDLE or a SSH_FXP_STATUS message. Once thefollow- ing values are defined (other values maydirectory has been successfully opened, files (and directories) contained in it can bedefined 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 completionlisted using SSH_FXP_READDIR requests. These are of theoperation. SSH_FX_EOF indicates end-of-file condition; for SSH_FX_READ it means that no more dataformat uint32 id string handle where `id' isavailable inthefile,request identifier, andfor SSH_FX_READDIR it indicates that no more files are contained in the directory. SSH_FX_NO_SUCH_FILE`handle' isreturned whenareferencehandle returned by SSH_FXP_OPENDIR. (It ismade toa protocol error to attempt to use an ordi- nary filewhich should exist but doesn't. SSH_FX_PERMISSION_DENIED ishandle returnedwhen the authenticated user does not have sufficient permissionsby SSH_FXP_OPEN.) The server responds toperform the operation. SSH_FX_FAILURE isthis request with either ageneric catch-all error message; it should be returned if an error occurs for which there is noSSH_FXP_NAME or a SSH_FXP_STATUS message. One or morespecific error code defined. SSH_FX_BAD_MESSAGEnames may be returnedifat abadly formatted packet or protocol incompatibility is detected. SSH_FX_NO_CONNECTIONtime. Full status information isa pseudo-error which indicates thatreturned for each name in order to speed up typical directory listings. When the clienthasnoconnectionlonger wishes to read more names from theserver (it can only be generated locally bydirectory, it SHOULD call SSH_FXP_CLOSE for theclient, and MUST NOThandle. The handle should bereturned by servers). SSH_FX_CONNECTION_LOST is a pseudo-error which indicates that the connection to the serverclosed regardless of whether an error hasbeen lost (it can only be generated locally by the client, and MUST NOT beoccurred or not. 7.8. Retrieving File Attributes Very often, file attributes are automatically returned byservers). 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 featureSSH_FXP_READDIR. However, sometimes there isnot supported byneed to specifically retrieve theserver, or it mayattributes for a named file. This can bereturned bydone using theserver ifSSH_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 theserverserver, whereas SSH_FXP_LSTAT does notimplement an operation). The SSH_FXP_HANDLE response hasfollow symbolic links. Both have thefollowingsame format: uint32 id stringhandlepath where `id' is the request identifier, and`handle' is an arbitrary string that identifies an open file or directory on`path' spefifies theserver. The handlefile sys- tem object for which status isopaquetothe client; the client MUST NOT attemptbe returned. The server responds tointerpretthis request with either SSH_FXP_ATTRS ormodify it in any way. The length ofSSH_FXP_STATUS. SSH_FXP_FSTAT differs from thehandle string MUST NOT exceed 256 data bytes. The SSH_FXP_DATA response hasothers in that it returns status information for an open file (identified by thefollowing format:file handle). Its format is as follows: uint32 id stringdatahandle where `id' is the requestidentifier,identifier and`data'`handle' isan arbitrary byte string containing the requested data.a file handle returned by SSH_FXP_OPEN. Thedata stringserver responds to this request with SSH_FXP_ATTRS or SSH_FXP_STATUS. 7.9. Setting File Attributes File attributes may beat mostmodified using thenumber of bytes requested in a SSH_FXP_READ request, but may also be shorter if end of file is reached or ifSSH_FXP_SETSTAT and SSH_FXP_FSETSTAT requests. These requests are used for operations such as changing theread is from something other thanownership, permissions or access times, as well as for truncating aregularfile. TheSSH_FXP_NAME response hasSSH_FXP_SETSTAT request is of the following format: uint32 iduint32 count repeats count times: string filenamestringlongnamepath ATTRS attrs where `id' is the request identifier,`count' is`path' specifies thenumber of names returned in this response,file system object (e.g. file or directory) whose attributes are to be modified, and `attrs' specifies theremaining fields repeat `count' times (so that all three fieldsmodifications to be made to its attributes. Attributes arefirst included fordiscussed in more detail in Section ``File Attributes''. An error will be returned if thefirst file, then forspecified file system object does not exist or thesecond file, etc). Inuser does not have sufficient rights to modify therepeated part, `filename' is a file name being returned (for SSH_FXP_READDIR, it will bespecified attributes. The server responds to this request with arelative name withinSSH_FXP_STATUS message. The SSH_FXP_FSETSTAT request modifies thedirectory, without any path components; for SSH_FXP_REALPATH it will be an absolute path name), `longname'attributes of a file which isan expanded format foralready open. It has thefile name, similar to whatfollowing format: uint32 id string handle ATTRS attrs where `id' is the request identifier, `handle' (MUST be returned by"ls -l" on Unix systems, and `attrs' is the attributes ofSSH_FXP_OPEN) identifies the fileas described in Section ``File Attributes''. The format ofwhose attributes are to be modified, and `attrs' specifies the`longname' field is unspecified by this protocol. It MUSTmodifications to besuitable for usemade to its attributes. Attributes are discussed inthe output of a directory listing command (in fact, the recommended operation for a directory listing command ismore detail in Section ``File Attributes''. The server will respond tosimply displaythisdata). However, clients SHOULD NOT attempt to parse the longname field for file attributes; they SHOULD use the attrs field instead.request with SSH_FXP_STATUS. 7.10. Dealing with Symbolic links Therecommended format forSSH_FXP_READLINK request may be used to read thelongname field istarget of a symbolic link. It would have a data part as follows:-rwxr-xr-x 1 mjos staff 348911 Mar 25 14:29 t-filexfer 1234567890 123 12345678 12345678 12345678 123456789012 Here, the first lineuint32 id string path where `id' issample output,the request identifier and `path' specifies thesecond field indicates widthspath name of thevarious fields. Fields are separated by spaces.symlink to be read. Thefirst field lists file permissions for user, group,server will respond with a SSH_FXP_NAME packet containing only one name andothers; the sec- ond field is link count; the third field is thea dummy attributes value. The nameof the user who owns the file;in thefourth field isreturned packet contains thenametarget of thegroup that ownslink. If an error occurs, thefile;server may respond with SSH_FXP_STATUS. The SSH_FXP_SYMLINK request will create a symbolic link on thefifth fieldserver. It isthe sizeof thefile in bytes; the sixth field (which actually may contain spaces, but is fixed to 12 characters)following format uint32 id string linkpath string targetpath where `id' is thefile modification time, andrequest identifier, `linkpath' specifies theseventh field ispath name of thefile name. Each file is specifiedsymlink to bea minimum of certain numbercreated and `targetpath' specifies the target ofcharacter positions (indicated bythesecond line above), but may also be longer ifsymlink. The server shall respond with a SSH_FXP_STATUS indicating either success (SSH_FX_OK) or an error condition. 7.11. Canonicalizing thedata does not fit inServer-Side Path Name The SSH_FXP_REALPATH request can be used to have thespecified length.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. TheSSH_FXP_ATTRS response hasformat of thefollowing format:request is as follows: uint32 idATTRS attrsstring path where `id' is the requestidentifier,identifier and`attrs'`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 returnedfile attributes as describedpacket will be inSection ``File Attributes''.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 ... where `id' is the request identifier, and `extended-request' is a string of the format "name@domain", where domain is an internet domain name of the vendor defining the request. The rest of the request is completely vendor-specific, and servers should only attempt to interpret it if they recognize the `extended-request' name. The server may respond to such requests using any of the response packets defined in Section ``Responses from the Server to the Client''. Additionally, the server may also respond with a SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does not recognize the `extended-request' name, then the server MUST respond with SSH_FXP_STATUS with error/status set to SSH_FX_OP_UNSUPPORTED. 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 following format: uint32 id ... any request-specific data ... 9. Security Considerations 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 theSSHSecure Shell User Authentication Protocol[SSH- USERAUTH].[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 SSH is a registered trademark andChanges from previous protocol versions The Secure Shell File Transfer Protocol has changed over time, before it's standardization. The following is atrademark of SSH Communications Security Corp. SSH Communications Security Corp permits the usedescription ofthese trademarks asthename of this standardincompatible changes between different versions. 10.1. Changes between versions 3 andprotocol,2 o The SSH_FXP_READLINK andpermits their use to describe that a product conformsSSH_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 tothis standard, provided that the following acknowledgement is included where the trademarks are used: ``SSH is a registered trademarkinclude fields `error message' andSecure Shell`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(www.ssh.com)''. These trademarks may not be used as part of a product name orinotherwise confusing manner without prior written permission of SSH Communications Security Corp. 11.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][SECSH-ARCH] Ylonen, T., et al:"SSH"Secure Shell Protocol Architecture",Internet- Draft, draft-ietf-secsh-architecture-07.txt [SSH-TRANSPORT]Internet-Draft, draft-ietf-secsh-architecture-08.txt [SECSH-TRANSPORT] Ylonen, T., et al:"SSH"Secure Shell Transport Protocol",Internet- Draft, draft-ietf-secsh-transport-09.txt [SSH-USERAUTH]Internet-Draft, draft-ietf-secsh-transport-10.txt [SECSH-USERAUTH] Ylonen, T., et al:"SSH"Secure Shell Authentication Protocol", Internet-Draft,draft-ietf-secsh-userauth-09.txt [SSH-CONNECT]draft-ietf-secsh-userauth-10.txt [SECSH-CONNECT] Ylonen, T., et al:"SSH"Secure Shell Connection Protocol",Internet- Draft, draft-ietf-secsh-connect-09.txt 12.Internet-Draft, draft-ietf-secsh-connect-10.txt 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 Fredrikinkatu 42 FIN-00100 HELSINKI Finland E-mail: sjl@ssh.com