| PROTOCOL (204917) | PROTOCOL (221420) |
|---|---|
| 1This documents OpenSSH's deviations and extensions to the published SSH 2protocol. 3 4Note that OpenSSH's sftp and sftp-server implement revision 3 of the SSH 5filexfer protocol described in: 6 7http://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt 8 9Newer versions of the draft will not be supported, though some features 10are individually implemented as extensions described below. 11 12The protocol used by OpenSSH's ssh-agent is described in the file 13PROTOCOL.agent 14 | 1This documents OpenSSH's deviations and extensions to the published SSH 2protocol. 3 4Note that OpenSSH's sftp and sftp-server implement revision 3 of the SSH 5filexfer protocol described in: 6 7http://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt 8 9Newer versions of the draft will not be supported, though some features 10are individually implemented as extensions described below. 11 12The protocol used by OpenSSH's ssh-agent is described in the file 13PROTOCOL.agent 14 |
| 151. transport: Protocol 2 MAC algorithm "umac-64@openssh.com" | 151. Transport protocol changes |
| 16 | 16 |
| 171.1. transport: Protocol 2 MAC algorithm "umac-64@openssh.com" 18 |
|
| 17This is a new transport-layer MAC method using the UMAC algorithm 18(rfc4418). This method is identical to the "umac-64" method documented 19in: 20 21http://www.openssh.com/txt/draft-miller-secsh-umac-01.txt 22 | 19This is a new transport-layer MAC method using the UMAC algorithm 20(rfc4418). This method is identical to the "umac-64" method documented 21in: 22 23http://www.openssh.com/txt/draft-miller-secsh-umac-01.txt 24 |
| 232. transport: Protocol 2 compression algorithm "zlib@openssh.com" | 251.2. transport: Protocol 2 compression algorithm "zlib@openssh.com" |
| 24 25This transport-layer compression method uses the zlib compression 26algorithm (identical to the "zlib" method in rfc4253), but delays the 27start of compression until after authentication has completed. This 28avoids exposing compression code to attacks from unauthenticated users. 29 30The method is documented in: 31 32http://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt 33 | 26 27This transport-layer compression method uses the zlib compression 28algorithm (identical to the "zlib" method in rfc4253), but delays the 29start of compression until after authentication has completed. This 30avoids exposing compression code to attacks from unauthenticated users. 31 32The method is documented in: 33 34http://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt 35 |
| 343. transport: New public key algorithms "ssh-rsa-cert-v00@openssh.com" and 35 "ssh-dsa-cert-v00@openssh.com" | 361.3. transport: New public key algorithms "ssh-rsa-cert-v00@openssh.com", 37 "ssh-dsa-cert-v00@openssh.com", 38 "ecdsa-sha2-nistp256-cert-v01@openssh.com", 39 "ecdsa-sha2-nistp384-cert-v01@openssh.com" and 40 "ecdsa-sha2-nistp521-cert-v01@openssh.com" |
| 36 | 41 |
| 37OpenSSH introduces two new public key algorithms to support certificate | 42OpenSSH introduces new public key algorithms to support certificate |
| 38authentication for users and hostkeys. These methods are documented in 39the file PROTOCOL.certkeys 40 | 43authentication for users and hostkeys. These methods are documented in 44the file PROTOCOL.certkeys 45 |
| 414. connection: Channel write close extension "eow@openssh.com" | 461.4. transport: Elliptic Curve cryptography |
| 42 | 47 |
| 48OpenSSH supports ECC key exchange and public key authentication as 49specified in RFC5656. Only the ecdsa-sha2-nistp256, ecdsa-sha2-nistp384 50and ecdsa-sha2-nistp521 curves over GF(p) are supported. Elliptic 51curve points encoded using point compression are NOT accepted or 52generated. 53 542. Connection protocol changes 55 562.1. connection: Channel write close extension "eow@openssh.com" 57 |
|
| 43The SSH connection protocol (rfc4254) provides the SSH_MSG_CHANNEL_EOF 44message to allow an endpoint to signal its peer that it will send no 45more data over a channel. Unfortunately, there is no symmetric way for 46an endpoint to request that its peer should cease sending data to it 47while still keeping the channel open for the endpoint to send data to 48the peer. 49 50This is desirable, since it saves the transmission of data that would --- 21 unchanged lines hidden (view full) --- 72window space and may be sent even if no window space is available. 73 74NB. due to certain broken SSH implementations aborting upon receipt 75of this message (in contravention of RFC4254 section 5.4), this 76message is only sent to OpenSSH peers (identified by banner). 77Other SSH implementations may be whitelisted to receive this message 78upon request. 79 | 58The SSH connection protocol (rfc4254) provides the SSH_MSG_CHANNEL_EOF 59message to allow an endpoint to signal its peer that it will send no 60more data over a channel. Unfortunately, there is no symmetric way for 61an endpoint to request that its peer should cease sending data to it 62while still keeping the channel open for the endpoint to send data to 63the peer. 64 65This is desirable, since it saves the transmission of data that would --- 21 unchanged lines hidden (view full) --- 87window space and may be sent even if no window space is available. 88 89NB. due to certain broken SSH implementations aborting upon receipt 90of this message (in contravention of RFC4254 section 5.4), this 91message is only sent to OpenSSH peers (identified by banner). 92Other SSH implementations may be whitelisted to receive this message 93upon request. 94 |
| 805. connection: disallow additional sessions extension 81 "no-more-sessions@openssh.com" | 952.2. connection: disallow additional sessions extension 96 "no-more-sessions@openssh.com" |
| 82 83Most SSH connections will only ever request a single session, but a 84attacker may abuse a running ssh client to surreptitiously open 85additional sessions under their control. OpenSSH provides a global 86request "no-more-sessions@openssh.com" to mitigate this attack. 87 88When an OpenSSH client expects that it will never open another session 89(i.e. it has been started with connection multiplexing disabled), it --- 10 unchanged lines hidden (view full) --- 100Note that this is not a general defence against compromised clients 101(that is impossible), but it thwarts a simple attack. 102 103NB. due to certain broken SSH implementations aborting upon receipt 104of this message, the no-more-sessions request is only sent to OpenSSH 105servers (identified by banner). Other SSH implementations may be 106whitelisted to receive this message upon request. 107 | 97 98Most SSH connections will only ever request a single session, but a 99attacker may abuse a running ssh client to surreptitiously open 100additional sessions under their control. OpenSSH provides a global 101request "no-more-sessions@openssh.com" to mitigate this attack. 102 103When an OpenSSH client expects that it will never open another session 104(i.e. it has been started with connection multiplexing disabled), it --- 10 unchanged lines hidden (view full) --- 115Note that this is not a general defence against compromised clients 116(that is impossible), but it thwarts a simple attack. 117 118NB. due to certain broken SSH implementations aborting upon receipt 119of this message, the no-more-sessions request is only sent to OpenSSH 120servers (identified by banner). Other SSH implementations may be 121whitelisted to receive this message upon request. 122 |
| 1086. connection: Tunnel forward extension "tun@openssh.com" | 1232.3. connection: Tunnel forward extension "tun@openssh.com" |
| 109 110OpenSSH supports layer 2 and layer 3 tunnelling via the "tun@openssh.com" 111channel type. This channel type supports forwarding of network packets 112with datagram boundaries intact between endpoints equipped with 113interfaces like the BSD tun(4) device. Tunnel forwarding channels are 114requested by the client with the following packet: 115 116 byte SSH_MSG_CHANNEL_OPEN --- 44 unchanged lines hidden (view full) --- 161The contents of the "data" field for layer 2 packets is: 162 163 uint32 packet length 164 byte[packet length] frame 165 166The "frame" field contains an IEEE 802.3 Ethernet frame, including 167header. 168 | 124 125OpenSSH supports layer 2 and layer 3 tunnelling via the "tun@openssh.com" 126channel type. This channel type supports forwarding of network packets 127with datagram boundaries intact between endpoints equipped with 128interfaces like the BSD tun(4) device. Tunnel forwarding channels are 129requested by the client with the following packet: 130 131 byte SSH_MSG_CHANNEL_OPEN --- 44 unchanged lines hidden (view full) --- 176The contents of the "data" field for layer 2 packets is: 177 178 uint32 packet length 179 byte[packet length] frame 180 181The "frame" field contains an IEEE 802.3 Ethernet frame, including 182header. 183 |
| 1697. sftp: Reversal of arguments to SSH_FXP_SYMLINK | 1843. SFTP protocol changes |
| 170 | 185 |
| 1863.1. sftp: Reversal of arguments to SSH_FXP_SYMLINK 187 |
|
| 171When OpenSSH's sftp-server was implemented, the order of the arguments 172to the SSH_FXP_SYMLINK method was inadvertently reversed. Unfortunately, 173the reversal was not noticed until the server was widely deployed. Since 174fixing this to follow the specification would cause incompatibility, the 175current order was retained. For correct operation, clients should send 176SSH_FXP_SYMLINK as follows: 177 178 uint32 id 179 string targetpath 180 string linkpath 181 | 188When OpenSSH's sftp-server was implemented, the order of the arguments 189to the SSH_FXP_SYMLINK method was inadvertently reversed. Unfortunately, 190the reversal was not noticed until the server was widely deployed. Since 191fixing this to follow the specification would cause incompatibility, the 192current order was retained. For correct operation, clients should send 193SSH_FXP_SYMLINK as follows: 194 195 uint32 id 196 string targetpath 197 string linkpath 198 |
| 1828. sftp: Server extension announcement in SSH_FXP_VERSION | 1993.2. sftp: Server extension announcement in SSH_FXP_VERSION |
| 183 184OpenSSH's sftp-server lists the extensions it supports using the 185standard extension announcement mechanism in the SSH_FXP_VERSION server 186hello packet: 187 188 uint32 3 /* protocol version */ 189 string ext1-name 190 string ext1-version --- 4 unchanged lines hidden (view full) --- 195 string extN-version 196 197Each extension reports its integer version number as an ASCII encoded 198string, e.g. "1". The version will be incremented if the extension is 199ever changed in an incompatible way. The server MAY advertise the same 200extension with multiple versions (though this is unlikely). Clients MUST 201check the version number before attempting to use the extension. 202 | 200 201OpenSSH's sftp-server lists the extensions it supports using the 202standard extension announcement mechanism in the SSH_FXP_VERSION server 203hello packet: 204 205 uint32 3 /* protocol version */ 206 string ext1-name 207 string ext1-version --- 4 unchanged lines hidden (view full) --- 212 string extN-version 213 214Each extension reports its integer version number as an ASCII encoded 215string, e.g. "1". The version will be incremented if the extension is 216ever changed in an incompatible way. The server MAY advertise the same 217extension with multiple versions (though this is unlikely). Clients MUST 218check the version number before attempting to use the extension. 219 |
| 2039. sftp: Extension request "posix-rename@openssh.com" | 2203.3. sftp: Extension request "posix-rename@openssh.com" |
| 204 205This operation provides a rename operation with POSIX semantics, which 206are different to those provided by the standard SSH_FXP_RENAME in 207draft-ietf-secsh-filexfer-02.txt. This request is implemented as a 208SSH_FXP_EXTENDED request with the following format: 209 210 uint32 id 211 string "posix-rename@openssh.com" 212 string oldpath 213 string newpath 214 215On receiving this request the server will perform the POSIX operation 216rename(oldpath, newpath) and will respond with a SSH_FXP_STATUS message. 217This extension is advertised in the SSH_FXP_VERSION hello with version 218"1". 219 | 221 222This operation provides a rename operation with POSIX semantics, which 223are different to those provided by the standard SSH_FXP_RENAME in 224draft-ietf-secsh-filexfer-02.txt. This request is implemented as a 225SSH_FXP_EXTENDED request with the following format: 226 227 uint32 id 228 string "posix-rename@openssh.com" 229 string oldpath 230 string newpath 231 232On receiving this request the server will perform the POSIX operation 233rename(oldpath, newpath) and will respond with a SSH_FXP_STATUS message. 234This extension is advertised in the SSH_FXP_VERSION hello with version 235"1". 236 |
| 22010. sftp: Extension requests "statvfs@openssh.com" and | 2373.4. sftp: Extension requests "statvfs@openssh.com" and |
| 221 "fstatvfs@openssh.com" 222 223These requests correspond to the statvfs and fstatvfs POSIX system 224interfaces. The "statvfs@openssh.com" request operates on an explicit 225pathname, and is formatted as follows: 226 227 uint32 id 228 string "statvfs@openssh.com" --- 24 unchanged lines hidden (view full) --- 253The values of the f_flag bitmask are as follows: 254 255 #define SSH_FXE_STATVFS_ST_RDONLY 0x1 /* read-only */ 256 #define SSH_FXE_STATVFS_ST_NOSUID 0x2 /* no setuid */ 257 258Both the "statvfs@openssh.com" and "fstatvfs@openssh.com" extensions are 259advertised in the SSH_FXP_VERSION hello with version "2". 260 | 238 "fstatvfs@openssh.com" 239 240These requests correspond to the statvfs and fstatvfs POSIX system 241interfaces. The "statvfs@openssh.com" request operates on an explicit 242pathname, and is formatted as follows: 243 244 uint32 id 245 string "statvfs@openssh.com" --- 24 unchanged lines hidden (view full) --- 270The values of the f_flag bitmask are as follows: 271 272 #define SSH_FXE_STATVFS_ST_RDONLY 0x1 /* read-only */ 273 #define SSH_FXE_STATVFS_ST_NOSUID 0x2 /* no setuid */ 274 275Both the "statvfs@openssh.com" and "fstatvfs@openssh.com" extensions are 276advertised in the SSH_FXP_VERSION hello with version "2". 277 |
| 261$OpenBSD: PROTOCOL,v 1.15 2010/02/26 20:29:54 djm Exp $ | 27810. sftp: Extension request "hardlink@openssh.com" 279 280This request is for creating a hard link to a regular file. This 281request is implemented as a SSH_FXP_EXTENDED request with the 282following format: 283 284 uint32 id 285 string "hardlink@openssh.com" 286 string oldpath 287 string newpath 288 289On receiving this request the server will perform the operation 290link(oldpath, newpath) and will respond with a SSH_FXP_STATUS message. 291This extension is advertised in the SSH_FXP_VERSION hello with version 292"1". 293 294$OpenBSD: PROTOCOL,v 1.17 2010/12/04 00:18:01 djm Exp $ |