draft-ietf-secsh-filexfer-04.txt
来自「OTP是开放电信平台的简称」· 文本 代码 · 共 2,026 行 · 第 1/5 页
TXT
2,026 行
Internet-Draft SSH File Transfer Protocol December 20028. 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 ... 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.Galbraith, et al. Expires June 18, 2003 [Page 30] Internet-Draft SSH File Transfer Protocol December 20029. 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 [8]. 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.Galbraith, et al. Expires June 18, 2003 [Page 31] Internet-Draft SSH File Transfer Protocol December 200210. 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 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 Clarify the use of stderr by the server. o Clarify handling of very large read requests by the server. o Make all filenames UTF-8. o Added 'newline' extension. o Made time fields 64 bit, and optionally have nanosecond resultion. 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.Galbraith, et al. Expires June 18, 2003 [Page 32] Internet-Draft SSH File Transfer Protocol December 200210.2 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.3 Changes between versions 2 and 1 o The SSH_FXP_RENAME message was added.10.4 Changes between versions 1 and 0 o Implementation changes, no actual protocol changes.Galbraith, et al. Expires June 18, 2003 [Page 33] Internet-Draft SSH File Transfer Protocol December 200211. Trademark Issues "ssh" is a registered trademark of SSH Communications Security Corp in the United States and/or other countries.Galbraith, et al. Expires June 18, 2003 [Page 34] Internet-Draft SSH File Transfer Protocol December 2002References [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] 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 1: System Application Program Interface (API) [C Language]", IEEE Standard 1003.2, 1996. [5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh-architecture-13 (work in progress), September 2002. [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. Lehtinen, "SSH Protocol Transport Protocol", draft-ietf-secsh-transport-15 (work in progress), September 2002. [7] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-16 (work in progress), September 2002. [8] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh-userauth-16 (work in progress), September 2002.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.comGalbraith, et al. Expires June 18, 2003 [Page 35] Internet-Draft SSH File Transfer Protocol December 2002 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.comGalbraith, et al. Expires June 18, 2003 [Page 36] Internet-Draft SSH File Transfer Protocol December 2002Intellectual Property Statement 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 whic⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?