[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.15 and 1.16

version 1.15, 2010/02/26 20:29:54 version 1.16, 2010/08/31 11:54:45
Line 12 
Line 12 
 The protocol used by OpenSSH's ssh-agent is described in the file  The protocol used by OpenSSH's ssh-agent is described in the file
 PROTOCOL.agent  PROTOCOL.agent
   
 1. transport: Protocol 2 MAC algorithm "umac-64@openssh.com"  1. Transport protocol changes
   
   1.1. transport: Protocol 2 MAC algorithm "umac-64@openssh.com"
   
 This is a new transport-layer MAC method using the UMAC algorithm  This is a new transport-layer MAC method using the UMAC algorithm
 (rfc4418). This method is identical to the "umac-64" method documented  (rfc4418). This method is identical to the "umac-64" method documented
 in:  in:
   
 http://www.openssh.com/txt/draft-miller-secsh-umac-01.txt  http://www.openssh.com/txt/draft-miller-secsh-umac-01.txt
   
 2. transport: Protocol 2 compression algorithm "zlib@openssh.com"  1.2. transport: Protocol 2 compression algorithm "zlib@openssh.com"
   
 This transport-layer compression method uses the zlib compression  This transport-layer compression method uses the zlib compression
 algorithm (identical to the "zlib" method in rfc4253), but delays the  algorithm (identical to the "zlib" method in rfc4253), but delays the
Line 31 
Line 33 
   
 http://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt  http://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt
   
 3. transport: New public key algorithms "ssh-rsa-cert-v00@openssh.com" and  1.3. transport: New public key algorithms "ssh-rsa-cert-v00@openssh.com",
    "ssh-dsa-cert-v00@openssh.com"       "ssh-dsa-cert-v00@openssh.com",
        "ecdsa-sha2-nistp256-cert-v01@openssh.com",
        "ecdsa-sha2-nistp384-cert-v01@openssh.com" and
        "ecdsa-sha2-nistp521-cert-v01@openssh.com"
   
 OpenSSH introduces two new public key algorithms to support certificate  OpenSSH introduces new public key algorithms to support certificate
 authentication for users and hostkeys. These methods are documented in  authentication for users and hostkeys. These methods are documented in
 the file PROTOCOL.certkeys  the file PROTOCOL.certkeys
   
 4. connection: Channel write close extension "eow@openssh.com"  1.4. transport: Elliptic Curve cryptography
   
   OpenSSH supports ECC key exchange and public key authentication as
   specified in RFC5656. Only the ecdsa-sha2-nistp256, ecdsa-sha2-nistp384
   and ecdsa-sha2-nistp521 curves over GF(p) are supported. Elliptic
   curve points encoded using point compression are NOT accepted or
   generated.
   
   2. Connection protocol changes
   
   2.1. connection: Channel write close extension "eow@openssh.com"
   
 The SSH connection protocol (rfc4254) provides the SSH_MSG_CHANNEL_EOF  The SSH connection protocol (rfc4254) provides the SSH_MSG_CHANNEL_EOF
 message to allow an endpoint to signal its peer that it will send no  message to allow an endpoint to signal its peer that it will send no
 more data over a channel. Unfortunately, there is no symmetric way for  more data over a channel. Unfortunately, there is no symmetric way for
Line 77 
Line 92 
 Other SSH implementations may be whitelisted to receive this message  Other SSH implementations may be whitelisted to receive this message
 upon request.  upon request.
   
 5. connection: disallow additional sessions extension  2.2. connection: disallow additional sessions extension
    "no-more-sessions@openssh.com"       "no-more-sessions@openssh.com"
   
 Most SSH connections will only ever request a single session, but a  Most SSH connections will only ever request a single session, but a
 attacker may abuse a running ssh client to surreptitiously open  attacker may abuse a running ssh client to surreptitiously open
Line 105 
Line 120 
 servers (identified by banner). Other SSH implementations may be  servers (identified by banner). Other SSH implementations may be
 whitelisted to receive this message upon request.  whitelisted to receive this message upon request.
   
 6. connection: Tunnel forward extension "tun@openssh.com"  2.3. connection: Tunnel forward extension "tun@openssh.com"
   
 OpenSSH supports layer 2 and layer 3 tunnelling via the "tun@openssh.com"  OpenSSH supports layer 2 and layer 3 tunnelling via the "tun@openssh.com"
 channel type. This channel type supports forwarding of network packets  channel type. This channel type supports forwarding of network packets
Line 166 
Line 181 
 The "frame" field contains an IEEE 802.3 Ethernet frame, including  The "frame" field contains an IEEE 802.3 Ethernet frame, including
 header.  header.
   
 7. sftp: Reversal of arguments to SSH_FXP_SYMLINK  3. SFTP protocol changes
   
   3.1. 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 inadvertently reversed. Unfortunately,  to the SSH_FXP_SYMLINK method was inadvertently 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 179 
Line 196 
         string          targetpath          string          targetpath
         string          linkpath          string          linkpath
   
 8. sftp: Server extension announcement in SSH_FXP_VERSION  3.2. 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 200 
Line 217 
 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 attempting to use the extension.  check the version number before attempting to use the extension.
   
 9. sftp: Extension request "posix-rename@openssh.com"  3.3. 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 217 
Line 234 
 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".
   
 10. sftp: Extension requests "statvfs@openssh.com" and  3.4. 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
Legend:
Removed from v.1.15  
changed lines
  Added in v.1.16