draft-ietf-secsh-filexfer-02.txt

来自「OTP是开放电信平台的简称」· 文本 代码 · 共 1,628 行 · 第 1/4 页

   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: [e-mail]


   Sami Lehtinen
   SSH Communications Security Corp
   Fredrikinkatu 42
   HELSINKI  FIN-00100
   Finland

   EMail: [e-mail]





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]