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