You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mina.apache.org by gn...@apache.org on 2013/07/26 15:30:58 UTC
[9/9] git commit: Remove third party documents from scm
Remove third party documents from scm
Project: http://git-wip-us.apache.org/repos/asf/mina-sshd/repo
Commit: http://git-wip-us.apache.org/repos/asf/mina-sshd/commit/46ea0930
Tree: http://git-wip-us.apache.org/repos/asf/mina-sshd/tree/46ea0930
Diff: http://git-wip-us.apache.org/repos/asf/mina-sshd/diff/46ea0930
Branch: refs/heads/master
Commit: 46ea09302ec1556b95474ae36337369e9c973c36
Parents: 5bd7629
Author: Guillaume Nodet <gn...@apache.org>
Authored: Fri Jul 26 15:30:42 2013 +0200
Committer: Guillaume Nodet <gn...@apache.org>
Committed: Fri Jul 26 15:30:42 2013 +0200
----------------------------------------------------------------------
.../src/docs/draft-ietf-secsh-agent-02.txt | 768 ----
.../src/docs/draft-ietf-secsh-filexfer-02.txt | 1626 ---------
.../src/docs/draft-ietf-secsh-filexfer-04.txt | 2130 -----------
.../src/docs/draft-ietf-secsh-filexfer-05.txt | 2802 ---------------
.../src/docs/draft-ietf-secsh-filexfer-13.txt | 3362 ------------------
sshd-core/src/docs/rfc4251.txt | 1683 ---------
sshd-core/src/docs/rfc4252.txt | 955 -----
sshd-core/src/docs/rfc4253.txt | 1795 ----------
sshd-core/src/docs/rfc4254.txt | 1347 -------
sshd-core/src/docs/rfc4255.txt | 507 ---
sshd-core/src/docs/rfc4256.txt | 675 ----
sshd-core/src/docs/rfc4345.txt | 283 --
sshd-core/src/docs/rfc4419.txt | 563 ---
13 files changed, 18496 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/mina-sshd/blob/46ea0930/sshd-core/src/docs/draft-ietf-secsh-agent-02.txt
----------------------------------------------------------------------
diff --git a/sshd-core/src/docs/draft-ietf-secsh-agent-02.txt b/sshd-core/src/docs/draft-ietf-secsh-agent-02.txt
deleted file mode 100644
index 6af78af..0000000
--- a/sshd-core/src/docs/draft-ietf-secsh-agent-02.txt
+++ /dev/null
@@ -1,768 +0,0 @@
-
-
-Network Working Group Tatu Ylonen
-INTERNET-DRAFT Timo J. Rinne
-draft-ietf-secsh-agent-02.txt Sami Lehtinen
-Expires: July 30, 2004 SSH Communications Security
- 30 January, 2004
-
-
-
- Secure Shell Authentication Agent 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
-
-This document describes the Secure Shell authentication agent protocol
-(i.e., the protocol used between a client requesting authentication and
-the authentication agent). This protocol usually runs in a machine-spe-
-cific local channel or over a forwarded authentication channel. It is
-assumed that the channel is trusted, so no protection for the communica-
-tions channel is provided by this protocol.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 1]
-
-INTERNET-DRAFT 30 January, 2004
-
-Table of Contents
-
-1. Authentication Agent Protocol . . . . . . . . . . . . . . . . . 2
- 1.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.2. Forwarding Notices . . . . . . . . . . . . . . . . . . . . . 3
- 1.3. Requesting Version Number . . . . . . . . . . . . . . . . . 4
- 1.4. Adding Keys to the Agent . . . . . . . . . . . . . . . . . . 4
- 1.4.1. Key types . . . . . . . . . . . . . . . . . . . . . . . 5
- 1.4.2. Forwarding constraints . . . . . . . . . . . . . . . . . 5
- 1.5. Deleting Keys from the Agent . . . . . . . . . . . . . . . . 7
- 1.6. Deleting specific key from the Agent . . . . . . . . . . . . 7
- 1.7. Listing the Keys that the Agent Can Use . . . . . . . . . . 7
-2. Performing Private Key Operations . . . . . . . . . . . . . . . 7
- 2.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 2.2. Decrypting . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 2.3. Secure Shell Challenge-Response Authentication . . . . . . . 8
-3. Administrative Messages . . . . . . . . . . . . . . . . . . . . 9
- 3.1. Locking and unlocking the agent . . . . . . . . . . . . . . 9
- 3.2. Miscellaneous Agent Commands . . . . . . . . . . . . . . . . 9
-4. Agent Forwarding With Secure Shell . . . . . . . . . . . . . . . 10
- 4.1. Requesting Agent Forwarding . . . . . . . . . . . . . . . . 10
- 4.2. Agent Forwarding Channels . . . . . . . . . . . . . . . . . 10
-5. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . . . 10
-6. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
-7. Intellectual Property . . . . . . . . . . . . . . . . . . . . . 12
-8. Additional Information . . . . . . . . . . . . . . . . . . . . . 12
-9. Changes from previous versions . . . . . . . . . . . . . . . . . 12
- 9.1. Changes between versions 3 and 2 . . . . . . . . . . . . . . 12
-10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-11. Address of Authors . . . . . . . . . . . . . . . . . . . . . . 13
-
-
-
-1. Authentication Agent Protocol
-
-The authentication agent is a piece of software that runs in a user's
-local workstation, laptop, or other trusted device. It is used to
-implement single sign-on. It holds the user's private keys in its own
-storage, and can perform requested operations using the private key. It
-allows the keys to be kept on a smartcard or other special hardware that
-can perform cryptographic operations.
-
-The authentication agent protocol is used to communicate between the
-authentication agent and clients wanting to authenticate something or
-wanting to perform private key operations.
-
-The actual communication between the client and the agent happens using
-a machine-dependent trusted communications channel. This channel would
-typically be a local socket, named pipe, or some kind of secure
-messaging system that works inside the local machine.
-
-The protocol works by the client sending requests to the agent, and the
-agent responding to these requests.
-
-
-Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 2]
-
-INTERNET-DRAFT 30 January, 2004
-
-1.1. Packet Format
-
-All messages passed to/from the authentication agent have the following
-format:
-
- uint32 length
- byte type
- data[length -1] data payload
-
-The following packet types are currently defined:
-
- /* Messages sent by the client. */
- #define SSH_AGENT_REQUEST_VERSION 1
- #define SSH_AGENT_ADD_KEY 202
- #define SSH_AGENT_DELETE_ALL_KEYS 203
- #define SSH_AGENT_LIST_KEYS 204
- #define SSH_AGENT_PRIVATE_KEY_OP 205
- #define SSH_AGENT_FORWARDING_NOTICE 206
- #define SSH_AGENT_DELETE_KEY 207
- #define SSH_AGENT_LOCK 208
- #define SSH_AGENT_UNLOCK 209
- #define SSH_AGENT_PING 212
- #define SSH_AGENT_RANDOM 213
-
- #define SSH_AGENT_EXTENSION 301
-
- /* Messages sent by the agent. */
- #define SSH_AGENT_SUCCESS 101
- #define SSH_AGENT_FAILURE 102
- #define SSH_AGENT_VERSION_RESPONSE 103
- #define SSH_AGENT_KEY_LIST 104
- #define SSH_AGENT_OPERATION_COMPLETE 105
- #define SSH_AGENT_RANDOM_DATA 106
- #define SSH_AGENT_ALIVE 150
-
-1.2. Forwarding Notices
-
-If the agent connection is forwarded through intermediate hosts (using
-the SSH Connection Protocol agent forwarding feature (described in
-Section ``Agent Forwarding With Secure Shell'' of this document), or
-some other means), each intermediate node (Secure Shell client) should
-insert the following message into the agent channel before forwarding
-any other messages. The real agent will then receive these messages in
-sequence the nearest node first, and can determine whether the
-connection is from a local machine and if not, can log the path where
-the connection came from. These messages must be wrapped in the
-appropriate header.
-
- byte SSH_AGENT_FORWARDING_NOTICE
- string remote host name (as typed by the user, preferably)
- string remote host ip
- uint32 remote host port
-
-
-
-Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 3]
-
-INTERNET-DRAFT 30 January, 2004
-
-1.3. Requesting Version Number
-
-When the client opens a connection, it must send the following message
-to the server. This must be the first message sent. The real agent
-will receive this after zero or more forwarding notice messages.
-
- byte SSH_AGENT_REQUEST_VERSION
- string version string of the application sending the request
- (optional)
-
-If the agent follows this protocol, it will respond with
-
- byte SSH_AGENT_VERSION_RESPONSE
- uint32 version number, 3 for this protocol
- <extension data>
-
-If the version number request is ever sent to the Secure Shell 1.x
-agent, it will interpret it as a request to list identities. It will
-then respond with a message whose first byte is 2. This can be used to
-determine the version of the agent if compatibility with Secure Shell
-1.x is desired.
-
-If the version string query arrives without trailing string identifying
-the client software version, it can be translated list identities
-request sent by Secure Shell 1.x and handled accordingly. If agent
-software does not support the agent protocol of Secure Shell 1.x, it MAY
-also interpret this query as valid SSH_AGENT_REQUEST_VERSION packet.
-
-The extension data in the SSH_AGENT_VERSION_RESPONSE 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.
-
-1.4. Adding Keys to the Agent
-
-The client can add a new private key to the agent with the following
-message. Using this message over the net has security implications, and
-the implementation SHOULD warn the user before decryption or sending the
-private key. (XXX how does ssh-add detect this condition?)
-
- byte SSH_AGENT_ADD_KEY
- string private key encoding
- string private key blob
-
-
-Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 4]
-
-INTERNET-DRAFT 30 January, 2004
-
- string public key encoding
- string public key and/or certificates for it
- string description of the key
- ... 0, 1 or several constraints follow
-
-1.4.1. Key types
-
-Key blobs are preceeded by the encoding field, which defines how the
-blob should be interpreted. Defined values for public key encoding are
-"ssh-dss" and "ssh-rsa". Additional key types may be defined as
-specified in [SECSH-ARCH], under Section IANA Considerations (Section
-8).
-
-"ssh-dss" and "ssh-rsa" public key format encodings are defined in
-[SECSH-TRANS].
-
-The "ssh-dss" private key format has the following specific encoding:
-
- string "ssh-dss"
- mpint p
- mpint q
- mpint g
- mpint y
- mpint x
-
-The "ssh-rsa" private key format has the following specific encoding:
-
- string "ssh-rsa"
- mpint e
- mpint d
- mpint n
- mpint u
- mpint p
- mpint q
-
-XXX Additional key-types (for private keys), for example "ssh-rsa-
-encrypted"?
-
-1.4.2. Forwarding constraints
-
-All constraints are pairs of following format:
-
- byte SSH_AGENT_CONSTRAINT_*
- variable argument for the constraint
-
-The type of the argument is dependent on the constraint type. Following
-constraint types are currently defined:
-
- /* Constraints 50-99 have a uint32 argument */
-
- /* Argument is uint32 defining key expiration time-out in
- seconds. After this timeout expires, the key can't be used.
- 0 == no timeout */
-
-
-Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 5]
-
-INTERNET-DRAFT 30 January, 2004
-
- #define SSH_AGENT_CONSTRAINT_TIMEOUT 50
-
- /* Argument is uint32 defining the number of operations that can
- be performed with this key. 0xffffffff == no limit */
- #define SSH_AGENT_CONSTRAINT_USE_LIMIT 51
-
- /* Argument is uint32 defining the number of forwarding steps that
- this key can be forwarded. 0xffffffff == no limit */
- #define SSH_AGENT_CONSTRAINT_FORWARDING_STEPS 52
-
- /* Constraints 100-149 have a string argument */
-
- /* Argument is string defining the allowed forwarding steps for
- this key. XXX define this. */
- #define SSH_AGENT_CONSTRAINT_FORWARDING_PATH 100
-
- /* Constraints 150-199 have a boolean argument */
-
- /* Argument is a boolean telling whether the key can be used
- in Secure Shell 1.x compatibility operations. */
-
- #define SSH_AGENT_CONSTRAINT_SSH1_COMPAT 150
-
- /* Argument is a boolean telling whether operations performed
- with this key should be confirmed interactively by the user
- or not. */
- #define SSH_AGENT_CONSTRAINT_NEED_USER_VERIFICATION 151
-
-Message can contain zero, one or multiple constraints.
-
-If the operation is successful, the agent will respond with the
-following message.
-
- byte SSH_AGENT_SUCCESS
-
-If the operation fails for some reason, the following message will be
-returned instead.
-
- byte SSH_AGENT_FAILURE
- uint32 error code
- string additional textual information (ISO-10646 UTF-8
- [RFC-2279])
- string language tag (as defined in [RFC-1766])
-
-The last two fields are optional; they don't need to be present in
-SSH_AGENT_FAILURE message. However, both MUST be provided if they are to
-be used. If client is version 2, the agent SHOULD NOT use these fields.
-
-The error code is one of the following:
-
- #define SSH_AGENT_ERROR_TIMEOUT 1
- #define SSH_AGENT_ERROR_KEY_NOT_FOUND 2
- #define SSH_AGENT_ERROR_DECRYPT_FAILED 3
-
-
-Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 6]
-
-INTERNET-DRAFT 30 January, 2004
-
- #define SSH_AGENT_ERROR_SIZE_ERROR 4
- #define SSH_AGENT_ERROR_KEY_NOT_SUITABLE 5
- #define SSH_AGENT_ERROR_DENIED 6
- #define SSH_AGENT_ERROR_FAILURE 7
- #define SSH_AGENT_ERROR_UNSUPPORTED_OP 8
-
-1.5. Deleting Keys from the Agent
-
-All keys that are in possession of the agent can be deleted with the
-following message. (The client is allowed to ignore this for some keys
-if desired.)
-
- byte SSH_AGENT_DELETE_ALL_KEYS
-
-The agent responds with either SSH_AGENT_SUCCESS or SSH_AGENT_FAILURE.
-
-1.6. Deleting specific key from the Agent
-
-The client can delete a specific key with given public key with
-following message.
-
- byte SSH_AGENT_DELETE_KEY
- string public key and/or certificates for it
- string description of the key
-
-The agent responds with either SSH_AGENT_SUCCESS or SSH_AGENT_FAILURE.
-
-1.7. Listing the Keys that the Agent Can Use
-
-The following message requests a list of all keys that the agent can
-use.
-
- byte SSH_AGENT_LIST_KEYS
-
-The agent will respond with the following message.
-
- byte SSH_AGENT_KEY_LIST
- uint32 number_of_keys
- repeats number_of_keys times:
- string public key blob or certificates
- string description
-
-2. Performing Private Key Operations
-
-The real purpose of the agent is to perform private key operations.
-Such operations are performed with the following message.
-
- byte SSH_AGENT_PRIVATE_KEY_OP
- string operation name
- string key or certificates, as returned in SSH_AGENT_KEY_LIST
- ... operation-specific data follows
-
-The operation to be performed is identified by a name (string). Custom
-
-
-Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 7]
-
-INTERNET-DRAFT 30 January, 2004
-
-operations can be added by suffixing the operation name by the fully
-qualified domain name of the person/organization adding the new
-operation.
-
-When the operation is complete, the agent will respond with either
-SSH_AGENT_FAILURE or with the following message if the operation is
-successful:
-
- byte SSH_AGENT_OPERATION_COMPLETE
- string resulting data
-
-If an operation is attempted that is not supported by the agent, the
-agent will respond with SSH_AGENT_FAILURE with error code set to
-SSH_AGENT_ERROR_UNSUPPORTED_OP.
-
-The standard operations are defined below.
-
-2.1. Signing
-
-The agent can be used to create a digital signature using a key held by
-the agent. The operation name is "sign", and data in is a hash
-(suitable for the key) that is to be signed. This normally performs the
-raw private key operation, without hashing data first. The resulting
-data will be a binary representation of the output of the private key
-operation. The exact details of the operations to be performed depend
-on the key being used.
-
-The operation-specific data has the following format:
-
- string data to be signed
-
-Alternatively, it is possible to give the actual data to be signed to
-the agent. This is done using the operation "hash-and-sign". This is
-otherwise equal, but performs key-dependent hashing before signing.
-
-If the requested operation is not legal for the key, SSH_AGENT_FAILURE
-will be returned with error code set to
-SSH_AGENT_ERROR_KEY_NOT_SUITABLE.
-
-2.2. Decrypting
-
-The agent can be used to decrypt a public key encrypted message with the
-operation "decrypt". This takes in raw public-key encrypted data, and
-returns the resulting decrypted data.
-
-This may also fail. If the requested operation is not legal for the
-key, error code is set to SSH_AGENT_ERROR_KEY_NOT_SUITABLE.
-
-The operation-specific data has the following format:
-
- string data to be decrypted
-
-
-
-
-Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 8]
-
-INTERNET-DRAFT 30 January, 2004
-
-2.3. Secure Shell Challenge-Response Authentication
-
-Performs Secure Shell challenge-response authentication. This operation
-has the name "ssh1-challenge-response".
-
-This operation works by first decrypting the challenge, then computing
-MD5 of the concatenation of the decrypted challenge and the session id
-(in this order), and returns the resulting 16 byte hash. The operation-
-specific data is in the following format:
-
- string challenge encrypted using the public key
- string session id
-
-Normally, the length of the challenge before encryption will be 32 bytes
-and the length of the session id 16 bytes. The length of the encrypted
-challenge depends on the key and algorithm used.
-
-3. Administrative Messages
-
-There are also a number of messages that are only used to administer the
-agent. These might e.g. be used by a user interface for the agent. The
-agent should only allow these messages from local connection (i.e., if
-no forwarding notice messages were received before the version number
-request).
-
-3.1. Locking and unlocking the agent
-
-The agent can be temporarily locked by message:
-
- byte SSH_AGENT_LOCK
- string locking password
-
-The agent responds with either SSH_AGENT_SUCCESS or SSH_AGENT_FAILURE.
-Particularily SSH_AGENT_FAILURE is sent, if agent is already locked.
-After this message, agent responds to all commands with
-SSH_AGENT_FAILURE until it receives a following command.
-
- byte SSH_AGENT_UNLOCK
- string locking password
-
-The agent responds with either SSH_AGENT_SUCCESS or SSH_AGENT_FAILURE.
-Particularily SSH_AGENT_FAILURE is sent, if agent is not locked or if
-the submitted password does not match with one given with SSH_AGENT_LOCK
-message.
-
-3.2. Miscellaneous Agent Commands
-
- byte SSH_AGENT_PING
- ... arbitrary padding data
-
-Any agent or client receiving this message, should respond with
-
- byte SSH_AGENT_ALIVE
-
-
-Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 9]
-
-INTERNET-DRAFT 30 January, 2004
-
- ... padding data from the SSH_AGENT_PING request
-
-where the padding data is identical to the data sent with
-SSH_AGENT_PING.
-
- byte SSH_AGENT_RANDOM
- uint32 the length of the requested random buffer
-
-Client can request random data from the agent by this message. Agent
-responds either with SSH_AGENT_RANDOM_DATA or SSH_AGENT_FAILURE message.
-
- byte SSH_AGENT_RANDOM_DATA
- string random data
-
-This message is a successful response to SSH_AGENT_RANDOM message.
-Message contains the random string of requested length.
-
-4. Agent Forwarding With Secure Shell
-
-The agent connection is typically forwarded over a Secure Shell
-connection. This requires small additions to the SSH Connection Protocol
-[SSH-CONN].
-
-4.1. Requesting Agent Forwarding
-
-Agent forwarding may be requested for a session by sending
-
- byte SSH_MSG_CHANNEL_REQUEST
- uint32 recipient channel
- string "auth-agent-req"
- boolean want reply
-
-This will, on success, create an agent listener to the remote end.
-
-4.2. Agent Forwarding Channels
-
-When a connection comes to the forwarded agent listener, a channel is
-opened to forward the connection to the other side.
-
- byte SSH_MSG_CHANNEL_OPEN
- string "auth-agent"
- uint32 sender channel
- uint32 initial window size
- uint32 maximum packet size
-
-Implementations MUST reject these messages unless they have previously
-requested agent forwarding.
-
-Forwarded agent channels are independent of any sessions, and closing a
-session channel does not in any way imply that forwarded connections
-should be closed.
-
-
-
-
-Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 10]
-
-INTERNET-DRAFT 30 January, 2004
-
-5. Vendor-Specific Extensions
-
-The SSH_AGENT_EXTENSION request provides a generic extension mechanism
-for adding vendor-specific commands. The request has the following
-format:
- byte SSH_AGENT_EXTENSION
- string extension_id
- ... extension-specific data follows ...
-
-`extension_id' 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 `extension_id' name.
-
-These messages can be sent to either direction. However, the agent MUST
-send these messages only as responses to the client's requests. As an
-implementation note, the agent should use the standard responses if at
-all possible.
-
-If the agent sees an extension message it doesn't understand, it should
-respond with SSH_AGENT_FAILURE with error
-SSH_AGENT_ERROR_UNSUPPORTED_OP.
-
-6. Security Considerations
-
-The authentication agent is used to control security-sensitive
-operations, and is used to implement single sign-on.
-
-Anyone with access to the authentication agent can perform private key
-operations with the agent. This is a power equivalent to possession of
-the private key as long as the connection to the key is maintained. It
-is not possible to retrieve the key from the agent.
-
-It is recommended that agent implementations allow and perform some form
-of logging and access control. This access control may utilize
-information about the path through which the connection was received (as
-collected with SSH_AGENT_FORWARDING_NOTICE messages; however, the path
-is reliable only up to and including the first unreliable machine.).
-Implementations should also allow restricting the operations that can be
-performed with keys - e.g., limiting them to challenge-response only.
-
-One should note that a local superuser will be able to obtain access to
-agents running on the local machine. This cannot be prevented; in most
-operating systems, a user with sufficient privileges will be able to
-read the keys from the physical memory.
-
-The authentication agent should not be run or forwarded to machine whose
-integrity is not trusted, as security on such machines might be
-compromised and might allow an attacker to obtain unauthorized access to
-the agent.
-
-Adding a key with SSH_AGENT_ADD_KEY over the net (especially over the
-Internet) is generally not recommended, because at present the private
-
-
-Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 11]
-
-INTERNET-DRAFT 30 January, 2004
-
-key has to be moved unencrypted. Implementations SHOULD warn the user of
-the implications. Even moving the key in encrypted form could be
-considered unwise.
-
-7. Intellectual Property
-
-The IETF takes no position regarding the validity or scope of any
-intellectual property or other rights that might be claimed to pertain
-to the implementation or use of the technology described in this
-document or the extent to which any license under such rights might or
-might not be available; neither does it represent that it has made any
-effort to identify any such rights. Information on the IETF's
-procedures with respect to rights in standards-track and standards-
-related documentation can be found in BCP-11. Copies of claims of
-rights made available for publication and any assurances of licenses to
-be made available, or the result of an attempt made to obtain a general
-license or permission for the use of such proprietary rights by
-implementers or users of this specification can be obtained from the
-IETF Secretariat.
-
-The IETF has been notified of intellectual property rights claimed in
-regard to some or all of the specification contained in this document.
-For more information consult the online list of claimed rights.
-
-8. Additional Information
-
-The current document editor is: Sami Lehtinen <sj...@ssh.com>. Comments
-on this Internet-Draft should be sent to the IETF SECSH working group,
-details at: http://ietf.org/html.charters/secsh-charter.html
-
-9. Changes from previous versions
-
-9.1. Changes between versions 3 and 2
-
-o Added error message and language tag to SSH_AGENT_FAILURE.
-
-o Added SSH_AGENT_EXTENSION.
-
-o Added extension data to SSH_AGENT_VERSION_RESPONSE.
-
-o Defined SSH_AGENT_ADD_KEY message better (previous version was
- underspecified).
-
-10. References
-
-Normative:
-
-[SECSH-CONNECT] Ylonen, T., et al: "Secure Shell Connection Protocol",
-Internet-Draft, draft-ietf-secsh-connect-16.txt
-
-[SECSH-TRANS] Ylonen, T., et al: "Secure Shell Transport Layer
-Protocol", Internet-Draft, draft-ietf-secsh-transport-10.txt
-
-
-
-Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 12]
-
-INTERNET-DRAFT 30 January, 2004
-
-[RFC-2279] Yergeau, F: "UTF-8, a transformation format of ISO 10646",
-January 1998.
-
-[RFC-1766] Alvestrand, H: "Tags for the Identification of Languages",
-March 1995.
-
-Informative:
-
-11. Address of Authors
-
- Tatu Ylonen
- SSH Communications Security Corp
- Fredrikinkatu 42
- FIN-00100 HELSINKI
- Finland
- E-mail: ylo@ssh.com
-
- Timo J. Rinne
- SSH Communications Security Corp
- Fredrikinkatu 42
- FIN-00100 HELSINKI
- Finland
- E-mail: tri@ssh.com
-
- Sami Lehtinen
- SSH Communications Security Corp
- Fredrikinkatu 42
- FIN-00100 HELSINKI
- Finland
- E-mail: sjl@ssh.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tatu Ylonen, Timo J. Rinne and Sami Lehtinen [page 13]
-
http://git-wip-us.apache.org/repos/asf/mina-sshd/blob/46ea0930/sshd-core/src/docs/draft-ietf-secsh-filexfer-02.txt
----------------------------------------------------------------------
diff --git a/sshd-core/src/docs/draft-ietf-secsh-filexfer-02.txt b/sshd-core/src/docs/draft-ietf-secsh-filexfer-02.txt
deleted file mode 100644
index 45e979e..0000000
--- a/sshd-core/src/docs/draft-ietf-secsh-filexfer-02.txt
+++ /dev/null
@@ -1,1626 +0,0 @@
-
-
-Network Working Group T. Ylonen
-Internet-Draft S. Lehtinen
-Expires: April 1, 2002 SSH Communications Security Corp
- October 2001
-
-
- SSH File Transfer Protocol
- draft-ietf-secsh-filexfer-02.txt
-
-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.
-
- This Internet-Draft will expire on April 1, 2002.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
-Abstract
-
- The SSH File Transfer Protocol provides secure file transfer
- functionality over any reliable data stream. It is the standard file
- transfer protocol for use with the SSH2 protocol. This document
- describes the file transfer protocol and its interface to the SSH2
- protocol suite.
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 1]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Use with the SSH Connection Protocol . . . . . . . . . . . . 4
- 3. General Packet Format . . . . . . . . . . . . . . . . . . . 5
- 4. Protocol Initialization . . . . . . . . . . . . . . . . . . 7
- 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . 8
- 6. Requests From the Client to the Server . . . . . . . . . . . 10
- 6.1 Request Synchronization and Reordering . . . . . . . . . . . 10
- 6.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . . 11
- 6.3 Opening, Creating, and Closing Files . . . . . . . . . . . . 11
- 6.4 Reading and Writing . . . . . . . . . . . . . . . . . . . . 13
- 6.5 Removing and Renaming Files . . . . . . . . . . . . . . . . 14
- 6.6 Creating and Deleting Directories . . . . . . . . . . . . . 15
- 6.7 Scanning Directories . . . . . . . . . . . . . . . . . . . . 15
- 6.8 Retrieving File Attributes . . . . . . . . . . . . . . . . . 16
- 6.9 Setting File Attributes . . . . . . . . . . . . . . . . . . 17
- 6.10 Dealing with Symbolic links . . . . . . . . . . . . . . . . 18
- 6.11 Canonicalizing the Server-Side Path Name . . . . . . . . . . 18
- 7. Responses from the Server to the Client . . . . . . . . . . 20
- 8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . 24
- 9. Security Considerations . . . . . . . . . . . . . . . . . . 25
- 10. Changes from previous protocol versions . . . . . . . . . . 26
- 10.1 Changes between versions 3 and 2 . . . . . . . . . . . . . . 26
- 10.2 Changes between versions 2 and 1 . . . . . . . . . . . . . . 26
- 10.3 Changes between versions 1 and 0 . . . . . . . . . . . . . . 26
- 11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . 27
- References . . . . . . . . . . . . . . . . . . . . . . . . . 28
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28
- Full Copyright Statement . . . . . . . . . . . . . . . . . . 29
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 2]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-1. Introduction
-
- This protocol provides secure file transfer (and more generally file
- system access) functionality over a reliable data stream, such as a
- channel in the SSH2 protocol [3].
-
- 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 the secsh architecture draft.[3].
-
- Even though this protocol is described in the context of the SSH2
- protocol, this protocol is general and independent of the rest of the
- SSH2 protocol suite. It could be used in a number of different
- applications, such as secure file transfer over TLS RFC 2246 [1] and
- transfer of management information in VPN applications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 3]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-2. Use with the SSH Connection Protocol
-
- When used with the SSH2 Protocol suite, this protocol is intended to
- be used from the SSH Connection Protocol [5] as a subsystem, as
- described in section ``Starting a Shell or a Command''. The
- subsystem name used with this protocol is "sftp".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 4]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-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 practice 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 practice 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 queuing of outgoing
- requests at the client.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 5]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 6]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-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
- `extension_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 organization 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.
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 7]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-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 [1].
-
- The `atime' and `mtime' contain the access and modification times of
- the files, respectively. They are represented as seconds from Jan 1,
- 1970 in UTC.
-
- The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 8]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
- 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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 9]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-6. Requests From the Client to the Server
-
- Requests from the client to the server represent the various file
- system operations. Each request begins with an `id' field, which is
- a 32-bit identifier identifying the request (selected by the client).
- The same identifier will be returned in the response to the request.
- One possible implementation of it is a monotonically increasing
- request sequence number (modulo 2^32).
-
- Many operations in the protocol operate on open files. The
- SSH_FXP_OPEN request can return a file handle (which is an opaque
- variable-length string) which may be used to access the file later
- (e.g. in a read operation). The client MUST NOT send requests the
- server with bogus or 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 the file
- handle string are entirely up to the server and its design. The
- client should not modify or attempt to interpret the file handle
- strings.
-
- The file handle strings MUST NOT be longer than 256 bytes.
-
-6.1 Request Synchronization and Reordering
-
- The protocol and implementations MUST process requests relating to
- the same file in the order in which they are received. In other
- words, if an application submits multiple requests to the server, the
- results in the responses will be the same as if it had sent the
- requests one at a time and waited for the response in each case. For
- example, the server may process non-overlapping read/write requests
- to the same file in parallel, but overlapping reads and writes cannot
- be reordered or parallelized. However, there are no ordering
- restrictions on the server for processing requests from two different
- file transfer connections. The server may interleave and parallelize
- them at will.
-
- There are no restrictions on the order in which responses to
- outstanding requests are delivered to the client, except that the
- server must ensure fairness in the sense that processing of no
- request will be indefinitely delayed even if the client is sending
- other requests so that there are multiple outstanding requests all
- the time.
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 10]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-6.2 File Names
-
- This protocol represents file names as strings. File names are
- assumed to use the slash ('/') character as a directory separator.
-
- File names starting with a slash are "absolute", and are relative to
- the root of the file system. Names starting with any other character
- are relative to the user's default directory (home directory). Note
- that identifying the user is assumed to take place outside of this
- protocol.
-
- Servers SHOULD interpret a path name component ".." as referring to
- the parent directory, and "." as referring to the current directory.
- If the server implementation limits access to certain parts of the
- file 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 path name has allowed access outside
- the intended area.
-
- An empty path name is valid, and it refers to the user's default
- directory (usually the user's home directory).
-
- Otherwise, no syntax is defined for file names by this specification.
- Clients should not make any other assumptions; however, they can
- splice path name components returned by SSH_FXP_READDIR together
- using a slash ('/') as the separator, and that will work as expected.
-
- It is understood that the lack of well-defined semantics for file
- names may cause interoperability problems between clients and servers
- using radically different operating systems. However, this approach
- is known to work acceptably with most systems, and alternative
- approaches that e.g. treat file names as sequences of structured
- components are quite complicated.
-
-6.3 Opening, Creating, and Closing Files
-
- Files are opened and created using the SSH_FXP_OPEN message, whose
- data part is as follows:
-
- uint32 id
- string filename
- uint32 pflags
- ATTRS attrs
-
- The `id' field is the request identifier as for all requests.
-
- The `filename' field specifies the file name. See Section ``File
- Names'' for more information.
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 11]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
- 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 have the following meanings:
-
- SSH_FXF_READ
- Open the file for reading.
-
- SSH_FXF_WRITE
- Open the file for writing. If both this and SSH_FXF_READ are
- specified, the file is opened for both reading and writing.
-
- SSH_FXF_APPEND
- Force all writes to append data at the end of the file.
-
- SSH_FXF_CREAT
- 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
- be truncated to zero length if it previously exists).
-
- SSH_FXF_TRUNC
- Forces an existing file with the same name to be truncated to zero
- length when creating a file by specifying SSH_FXF_CREAT.
- SSH_FXF_CREAT MUST also be specified if this flag is used.
-
- SSH_FXF_EXCL
- Causes the request to fail if the named file already exists.
- SSH_FXF_CREAT MUST also be specified if this flag is used.
-
- The `attrs' field specifies the initial attributes for the file.
- Default values will be used for those attributes that are not
- 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
- operation is successful) or SSH_FXP_STATUS (if the operation fails).
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 12]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
- A file is closed by using the SSH_FXP_CLOSE request. Its data field
- has the following format:
-
- uint32 id
- string handle
-
- where `id' is the request identifier, and `handle' is a handle
- previously returned in the response to SSH_FXP_OPEN or
- SSH_FXP_OPENDIR. The handle becomes invalid immediately after this
- request has been sent.
-
- The response to this request will be a SSH_FXP_STATUS message. One
- should note that on some server platforms even a close can fail.
- This can happen e.g. if the server operating system caches writes,
- and an error occurs while flushing cached writes during the close.
-
-6.4 Reading and Writing
-
- Once a file has been opened, it can be read using the SSH_FXP_READ
- message, which has the following format:
-
- uint32 id
- string handle
- uint64 offset
- uint32 len
-
- where `id' is the request identifier, `handle' is an open file handle
- returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative
- to the beginning of the file from where to start reading, and `len'
- is the maximum number of bytes to read.
-
- In response to this request, the server will read as many bytes as it
- can from the file (up to `len'), and return 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 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.
-
- Writing to a file is achieved using the SSH_FXP_WRITE message, which
- has the following format:
-
- uint32 id
- string handle
- uint64 offset
- string data
-
- where `id' is a request identifier, `handle' is a file handle
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 13]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
- returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the
- beginning of the file where to start writing, and `data' is the data
- to be written.
-
- The write will extend the file if writing beyond the end of the file.
- It is legal to write way beyond the end of the file; the semantics
- are to write zeroes from the end of the file to the specified offset
- and then the data. On most operating systems, such writes do not
- allocate disk space but instead leave "holes" in the file.
-
- The server responds to a write request with a SSH_FXP_STATUS message.
-
-6.5 Removing and Renaming Files
-
- Files can be removed using the SSH_FXP_REMOVE message. It has the
- following format:
-
- uint32 id
- string filename
-
- where `id' is the request identifier and `filename' is the name of
- the file to be removed. See Section ``File Names'' for more
- information. This request cannot be used to remove directories.
-
- The server 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' is the request identifier, `oldpath' is the name of an
- 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
- with the name specified by newpath. The server may also fail rename
- requests in other situations, for example if `oldpath' and `newpath'
- point to different file systems on the server.
-
- The server will respond to this request with a SSH_FXP_STATUS
- message.
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 14]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-6.6 Creating and Deleting Directories
-
- New directories can be created using the SSH_FXP_MKDIR request. It
- has the following format:
-
- uint32 id
- string path
- ATTRS attrs
-
- where `id' is the request identifier, `path' and `attrs' specifies
- the modifications to be made to its attributes. See Section ``File
- Names'' for more information on file names. Attributes are discussed
- in more detail in Section ``File Attributes''. specifies the
- directory to be created. An error will be returned if a file or
- directory with the specified path already exists. The server will
- respond to this request with a SSH_FXP_STATUS message.
-
- Directories can be removed using the SSH_FXP_RMDIR request, which
- has the following format:
-
- uint32 id
- string path
-
- where `id' is the request identifier, and `path' specifies the
- directory to be removed. See Section ``File Names'' for more
- information on file names. An error will be returned if no directory
- with the specified path exists, or if the specified directory is not
- empty, or if the path specified a file system object other than a
- directory. The server responds to this request with a SSH_FXP_STATUS
- message.
-
-6.7 Scanning Directories
-
- The files in a directory can be listed using the SSH_FXP_OPENDIR and
- SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one
- or more file names with full file attributes for each file. The
- client should call SSH_FXP_READDIR repeatedly until it has found the
- file it is looking for or until the server responds with a
- SSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF if
- there are no more files in the directory). The client should then
- close the handle using the SSH_FXP_CLOSE request.
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 15]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
- The SSH_FXP_OPENDIR opens a directory for reading. It has the
- following format:
-
- uint32 id
- string path
-
- where `id' is the request identifier and `path' is the path name of
- the 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. The server will respond to this request with either
- a SSH_FXP_HANDLE or a SSH_FXP_STATUS message.
-
- Once the directory has been successfully opened, files (and
- directories) contained in it can be listed using SSH_FXP_READDIR
- requests. These are of the format
-
- uint32 id
- string 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
- use an ordinary file handle returned by SSH_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 information is returned for each name in order to speed
- up typical directory listings.
-
- When the client no longer wishes to read more names from the
- directory, it SHOULD call SSH_FXP_CLOSE for the handle. The handle
- should be closed regardless of whether an error has occurred or not.
-
-6.8 Retrieving File Attributes
-
- Very often, file attributes are automatically returned by
- SSH_FXP_READDIR. However, sometimes there is need to specifically
- retrieve the attributes for a named file. This can be done using the
- SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests.
-
- SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT
- follows symbolic links on the server, whereas SSH_FXP_LSTAT does not
- follow symbolic links. Both have the same format:
-
- uint32 id
- string path
-
- where `id' is the request identifier, and `path' specifies the file
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 16]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
- system object for which status is to be returned. The server
- responds to this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS.
-
- SSH_FXP_FSTAT differs from the others in that it returns status
- information for an open file (identified by the file handle). Its
- format is as follows:
-
- uint32 id
- string handle
-
- where `id' is the request identifier and `handle' is a file handle
- returned by SSH_FXP_OPEN. The server responds to this request with
- SSH_FXP_ATTRS or SSH_FXP_STATUS.
-
-6.9 Setting File Attributes
-
- File attributes may be modified using the SSH_FXP_SETSTAT and
- SSH_FXP_FSETSTAT requests. These requests are used for operations
- such as changing the ownership, permissions or access times, as well
- as for truncating a file.
-
- The SSH_FXP_SETSTAT request is of the following format:
-
- uint32 id
- string path
- ATTRS attrs
-
- where `id' is the request identifier, `path' specifies the file
- system object (e.g. file or directory) whose attributes are to be
- modified, and `attrs' specifies the modifications to be made to its
- attributes. Attributes are discussed in more detail in Section
- ``File Attributes''.
-
- 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
- specified attributes. The server responds to this request with a
- SSH_FXP_STATUS message.
-
- The SSH_FXP_FSETSTAT request modifies the attributes of a file which
- is already open. It has the following format:
-
- uint32 id
- string handle
- ATTRS attrs
-
- where `id' is the request identifier, `handle' (MUST be returned by
- SSH_FXP_OPEN) identifies the file whose attributes are to be
- modified, and `attrs' specifies the modifications to be made to its
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 17]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
- attributes. Attributes are discussed in more detail in Section
- ``File Attributes''. The server will respond to this request with
- SSH_FXP_STATUS.
-
-6.10 Dealing with Symbolic links
-
- The SSH_FXP_READLINK request may be used to read the target of a
- symbolic link. It would have a data part as follows:
-
- uint32 id
- string path
-
- where `id' is the request identifier and `path' specifies the path
- name of the symlink to be read.
-
- The server will respond with a SSH_FXP_NAME packet containing only
- one name and a dummy attributes value. The name in the returned
- packet contains the target of the link. If an error occurs, the
- server may respond with SSH_FXP_STATUS.
-
- The SSH_FXP_SYMLINK request will create a symbolic link on the
- server. It is of the following format
-
- uint32 id
- string linkpath
- string targetpath
-
- where `id' is the request identifier, `linkpath' specifies the path
- name of the symlink to be created and `targetpath' specifies the
- target of the symlink. The server shall respond with a
- SSH_FXP_STATUS indicating either success (SSH_FX_OK) or an error
- condition.
-
-6.11 Canonicalizing the Server-Side Path Name
-
- The SSH_FXP_REALPATH request can be used to have the server
- canonicalize any given path name to an absolute path. This is useful
- for converting path names containing ".." components or relative
- pathnames without a leading slash into absolute paths. The format of
- the request is as follows:
-
- uint32 id
- string path
-
- where `id' is the request identifier and `path' specifies the path
- name to be canonicalized. The server will respond with a
- SSH_FXP_NAME packet containing only one name and a dummy attributes
- value. The name is the returned packet will be in canonical form.
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 18]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
- If an error occurs, the server may also respond with SSH_FXP_STATUS.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 19]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-7. Responses from the Server to the Client
-
- The server responds to the client using one of a few response
- packets. All requests can return a SSH_FXP_STATUS response upon
- failure. When the operation is successful, any of the responses may
- be returned (depending on the operation). If no data needs to be
- returned to the client, the SSH_FXP_STATUS response with SSH_FX_OK
- status is appropriate. Otherwise, the SSH_FXP_HANDLE message is used
- to return a file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR
- requests), SSH_FXP_DATA is used to return data from SSH_FXP_READ,
- SSH_FXP_NAME is used to return one or more file names from a
- SSH_FXP_READDIR or SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is
- used to return file attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and
- SSH_FXP_FSTAT requests.
-
- Exactly one response will be returned for each request. Each
- response packet contains a request identifier which can be used to
- match each response with the corresponding request. Note that it is
- legal to have several requests outstanding simultaneously, and the
- server is allowed to send responses to them in a different order from
- the order in which the requests were sent (the result of their
- execution, however, is guaranteed to be as if they had been processed
- one at a time in the order in which the requests were sent).
-
- Response packets are of the same general format as request packets.
- Each response packet begins with the request identifier.
-
- The format of the data portion of the SSH_FXP_STATUS response is as
- follows:
-
- uint32 id
- uint32 error/status code
- string error message (ISO-10646 UTF-8 [RFC-2279])
- string language tag (as defined in [RFC-1766])
-
- where `id' is the request identifier, and `error/status code'
- indicates the result of the requested operation. The value SSH_FX_OK
- indicates success, and all other values indicate failure.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 20]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
- Currently, the following 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).
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 21]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
- SSH_FX_OP_UNSUPPORTED
- indicates that an attempt was made to perform an operation which
- is not supported for the server (it may be generated locally by
- the client if e.g. the version number exchange indicates that a
- required feature is not supported by the server, or it may be
- returned by the server if the server does not implement an
- operation).
-
- The SSH_FXP_HANDLE response has the following format:
-
- uint32 id
- string handle
-
- where `id' is the request identifier, and `handle' is an arbitrary
- string that identifies an open file or directory on the server. The
- handle is opaque to the client; the client MUST NOT attempt to
- interpret or modify it in any way. The length of the handle string
- MUST NOT exceed 256 data bytes.
-
- The SSH_FXP_DATA response has the following format:
-
- uint32 id
- string data
-
- where `id' is the request identifier, and `data' is an arbitrary byte
- string containing the requested data. The data string may be at most
- the number of bytes requested in a SSH_FXP_READ request, but may also
- be shorter if end of file is reached or if the read is from something
- other than a regular file.
-
- The SSH_FXP_NAME response has the following format:
-
- uint32 id
- uint32 count
- repeats count times:
- string filename
- string longname
- ATTRS attrs
-
- where `id' is the request identifier, `count' is the number of names
- returned in this response, and the remaining fields repeat `count'
- times (so that all three fields are first included for the first
- file, then for the second file, etc). In the repeated part,
- `filename' is a file name being returned (for SSH_FXP_READDIR, it
- will be a relative name within the directory, without any path
- components; for SSH_FXP_REALPATH it will be an absolute path name),
- `longname' is an expanded format for the file name, similar to what
- is returned by "ls -l" on Unix systems, and `attrs' is the attributes
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 22]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
- 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:
-
- uint32 id
- ATTRS attrs
-
- where `id' is the request identifier, and `attrs' is the returned
- file attributes as described in Section ``File Attributes''.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 23]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-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 ...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 24]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-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 the SSH User Authentication Protocol [6].
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 25]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-10. Changes from previous protocol versions
-
- The SSH File Transfer Protocol has changed over time, before it's
- standardization. The following is a description of the incompatible
- changes between different versions.
-
-10.1 Changes between versions 3 and 2
-
- o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added.
-
- o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were
- added.
-
- o The SSH_FXP_STATUS message was changed to include fields `error
- message' and `language tag'.
-
-
-10.2 Changes between versions 2 and 1
-
- o The SSH_FXP_RENAME message was added.
-
-
-10.3 Changes between versions 1 and 0
-
- o Implementation changes, no actual protocol changes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 26]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-11. Trademark Issues
-
- "ssh" is a registered trademark of SSH Communications Security Corp
- in the United States and/or other countries.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 27]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-References
-
- [1] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
- P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
- 1999.
-
- [2] Institute of Electrical and Electronics Engineers, "Information
- Technology - Portable Operating System Interface (POSIX) - Part
- 1: System Application Program Interface (API) [C Language]",
- IEEE Standard 1003.2, 1996.
-
- [3] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
- Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh-
- architecture-09 (work in progress), July 2001.
-
- [4] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
- Lehtinen, "SSH Protocol Transport Protocol", draft-ietf-secsh-
- architecture-09 (work in progress), July 2001.
-
- [5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
- Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-11
- (work in progress), July 2001.
-
- [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
- Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh-
- userauth-11 (work in progress), July 2001.
-
-
-Authors' Addresses
-
- Tatu Ylonen
- SSH Communications Security Corp
- Fredrikinkatu 42
- HELSINKI FIN-00100
- Finland
-
- EMail: ylo@ssh.com
-
-
- Sami Lehtinen
- SSH Communications Security Corp
- Fredrikinkatu 42
- HELSINKI FIN-00100
- Finland
-
- EMail: sjl@ssh.com
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 28]
-
-Internet-Draft SSH File Transfer Protocol October 2001
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ylonen & Lehtinen Expires April 1, 2002 [Page 29]
-
-
-