[BACK]Return to PROTOCOL CVS log [TXT][DIR] Up to [local] / src / usr.bin / ssh

Diff for /src/usr.bin/ssh/PROTOCOL between version 1.6 and 1.7

version 1.6, 2008/06/10 22:15:23 version 1.7, 2008/06/12 05:15:41
Line 84 
Line 84 
 Note that this is not a general defence against compromised clients  Note that this is not a general defence against compromised clients
 (that is impossible), but it thwarts a simple attack.  (that is impossible), but it thwarts a simple attack.
   
 5. sftp: Reversal of arguments to SSH_FXP_SYMLINK  5. connection: Tunnel forward extension "tun@openssh.com"
   
   OpenSSH supports layer 2 and layer 3 tunneling via the "tun@openssh.com"
   channel type. This channel type supports forwarding of network packets
   with datagram boundaries entact between endpoints equipped with
   interfaces like the BSD tun(4) device. Tunnel forwarding channels are
   requested by the client with the following packet:
   
           byte            SSH_MSG_CHANNEL_OPEN
           string          "tun@openssh.com"
           uint32          sender channel
           uint32          initial window size
           uint32          maximum packet size
           uint32          tunnel mode
           uint32          remote unit number
   
   The "tunnel mode" parameter specifies whether the tunnel should forward
   layer 2 frames or layer 3 packets. It may take one of the following values:
   
           SSH_TUNMODE_POINTOPOINT  1              /* layer 3 packets */
           SSH_TUNMODE_ETHERNET     2              /* layer 2 frames */
   
   The "tunnel unit number" specifies the remote interface number, or may
   be zero to allow the server to automatically chose an interface. A server
   that is not willing to open a client-specified unit should refuse the
   request with a SSH_MSG_CHANNEL_OPEN_FAILURE error. On successful open,
   the server should reply with SSH_MSG_CHANNEL_OPEN_SUCCESS.
   
   Once established the client and server may exchange packet or frames
   over the tunnel channel by encapsulating them in SSH protocol strings
   and sending them as channel data. This ensures that packet boundaries
   are kept intact. Specifically, packets are transmitted using normal
   SSH_MSG_CHANNEL_DATA packets:
   
           byte            SSH_MSG_CHANNEL_DATA
           uint32          recipient channel
           string          data
   
   The contents of the "data" field for layer 3 packets is:
   
           uint32                  packet length
           uint32                  address family
           byte[packet length - 4] packet data
   
   The "address family" field identifies the type of packet in the message.
   It may be one of:
   
           SSH_TUN_AF_INET         2               /* IPv4 */
           SSH_TUN_AF_INET6        24              /* IPv6 */
   
   The "packet data" field consists of the IPv4/IPv6 datagram itself
   without any link layer header.
   
   The contents of the "data" field for layer 3 packets is:
   
           uint32                  packet length
           byte[packet length]     frame
   
   The "frame" field contains an IEEE 802.3 ethernet frame, including
   header.
   
   6. sftp: Reversal of arguments to SSH_FXP_SYMLINK
   
 When OpenSSH's sftp-server was implemented, the order of the arguments  When OpenSSH's sftp-server was implemented, the order of the arguments
 to the SSH_FXP_SYMLINK method was inadvertendly reversed. Unfortunately,  to the SSH_FXP_SYMLINK method was inadvertendly reversed. Unfortunately,
 the reversal was not noticed until the server was widely deployed. Since  the reversal was not noticed until the server was widely deployed. Since
Line 97 
Line 158 
         string          targetpath          string          targetpath
         string          linkpath          string          linkpath
   
 6. sftp: Server extension announcement in SSH_FXP_VERSION  7. sftp: Server extension announcement in SSH_FXP_VERSION
   
 OpenSSH's sftp-server lists the extensions it supports using the  OpenSSH's sftp-server lists the extensions it supports using the
 standard extension announcement mechanism in the SSH_FXP_VERSION server  standard extension announcement mechanism in the SSH_FXP_VERSION server
Line 118 
Line 179 
 extension with multiple versions (though this is unlikely). Clients MUST  extension with multiple versions (though this is unlikely). Clients MUST
 check the version number before attemping to use the extension.  check the version number before attemping to use the extension.
   
 7. sftp: Extension request "posix-rename@openssh.com"  8. sftp: Extension request "posix-rename@openssh.com"
   
 This operation provides a rename operation with POSIX semantics, which  This operation provides a rename operation with POSIX semantics, which
 are different to those provided by the standard SSH_FXP_RENAME in  are different to those provided by the standard SSH_FXP_RENAME in
Line 135 
Line 196 
 This extension is advertised in the SSH_FXP_VERSION hello with version  This extension is advertised in the SSH_FXP_VERSION hello with version
 "1".  "1".
   
 8. sftp: Extension requests "statvfs@openssh.com" and  9. sftp: Extension requests "statvfs@openssh.com" and
          "fstatvfs@openssh.com"           "fstatvfs@openssh.com"
   
 These requests correspond to the statvfs and fstatvfs POSIX system  These requests correspond to the statvfs and fstatvfs POSIX system
Line 177 
Line 238 
 "2".  "2".
   
 $OpenBSD$  $OpenBSD$
   
Legend:
Removed from v.1.6  
changed lines
  Added in v.1.7