]>
Commit | Line | Data |
---|---|---|
58a81148 DM |
1 | This documents OpenSSH's deviations and extensions to the published SSH |
2 | protocol. | |
3 | ||
4 | Note that OpenSSH's sftp and sftp-server implement revision 3 of the SSH | |
5 | filexfer protocol described in: | |
6 | ||
461f50e7 | 7 | https://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt |
58a81148 | 8 | |
a2e10485 DT |
9 | Newer versions of the draft will not be supported, though some features |
10 | are individually implemented as extensions described below. | |
58a81148 | 11 | |
1e18beb1 DM |
12 | The protocol used by OpenSSH's ssh-agent is described in the file |
13 | PROTOCOL.agent | |
14 | ||
eb8b60e3 DM |
15 | 1. Transport protocol changes |
16 | ||
17 | 1.1. transport: Protocol 2 MAC algorithm "umac-64@openssh.com" | |
58a81148 DM |
18 | |
19 | This is a new transport-layer MAC method using the UMAC algorithm | |
20 | (rfc4418). This method is identical to the "umac-64" method documented | |
21 | in: | |
22 | ||
461f50e7 | 23 | https://www.openssh.com/txt/draft-miller-secsh-umac-01.txt |
58a81148 | 24 | |
eb8b60e3 | 25 | 1.2. transport: Protocol 2 compression algorithm "zlib@openssh.com" |
58a81148 DM |
26 | |
27 | This transport-layer compression method uses the zlib compression | |
28 | algorithm (identical to the "zlib" method in rfc4253), but delays the | |
29 | start of compression until after authentication has completed. This | |
30 | avoids exposing compression code to attacks from unauthenticated users. | |
31 | ||
32 | The method is documented in: | |
33 | ||
461f50e7 | 34 | https://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt |
58a81148 | 35 | |
8ba0fd40 | 36 | 1.3. transport: New public key algorithms "ssh-rsa-cert-v01@openssh.com", |
37 | "ssh-dsa-cert-v01@openssh.com", | |
eb8b60e3 DM |
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" | |
0a80ca19 | 41 | |
eb8b60e3 | 42 | OpenSSH introduces new public key algorithms to support certificate |
523463a3 | 43 | authentication for users and host keys. These methods are documented |
44 | in the file PROTOCOL.certkeys | |
0a80ca19 | 45 | |
eb8b60e3 DM |
46 | 1.4. transport: Elliptic Curve cryptography |
47 | ||
48 | OpenSSH supports ECC key exchange and public key authentication as | |
49 | specified in RFC5656. Only the ecdsa-sha2-nistp256, ecdsa-sha2-nistp384 | |
50 | and ecdsa-sha2-nistp521 curves over GF(p) are supported. Elliptic | |
51 | curve points encoded using point compression are NOT accepted or | |
52 | generated. | |
53 | ||
af43a7ac DM |
54 | 1.5 transport: Protocol 2 Encrypt-then-MAC MAC algorithms |
55 | ||
56 | OpenSSH supports MAC algorithms, whose names contain "-etm", that | |
57 | perform the calculations in a different order to that defined in RFC | |
58 | 4253. These variants use the so-called "encrypt then MAC" ordering, | |
59 | calculating the MAC over the packet ciphertext rather than the | |
60 | plaintext. This ordering closes a security flaw in the SSH transport | |
61 | protocol, where decryption of unauthenticated ciphertext provided a | |
62 | "decryption oracle" that could, in conjunction with cipher flaws, reveal | |
63 | session plaintext. | |
64 | ||
65 | Specifically, the "-etm" MAC algorithms modify the transport protocol | |
66 | to calculate the MAC over the packet ciphertext and to send the packet | |
67 | length unencrypted. This is necessary for the transport to obtain the | |
68 | length of the packet and location of the MAC tag so that it may be | |
69 | verified without decrypting unauthenticated data. | |
70 | ||
71 | As such, the MAC covers: | |
72 | ||
3739c8f0 | 73 | mac = MAC(key, sequence_number || packet_length || encrypted_packet) |
af43a7ac | 74 | |
3739c8f0 DM |
75 | where "packet_length" is encoded as a uint32 and "encrypted_packet" |
76 | contains: | |
af43a7ac DM |
77 | |
78 | byte padding_length | |
79 | byte[n1] payload; n1 = packet_length - padding_length - 1 | |
80 | byte[n2] random padding; n2 = padding_length | |
81 | ||
1d75abfe DM |
82 | 1.6 transport: AES-GCM |
83 | ||
84 | OpenSSH supports the AES-GCM algorithm as specified in RFC 5647. | |
85 | Because of problems with the specification of the key exchange | |
86 | the behaviour of OpenSSH differs from the RFC as follows: | |
87 | ||
88 | AES-GCM is only negotiated as the cipher algorithms | |
89 | "aes128-gcm@openssh.com" or "aes256-gcm@openssh.com" and never as | |
90 | an MAC algorithm. Additionally, if AES-GCM is selected as the cipher | |
91 | the exchanged MAC algorithms are ignored and there doesn't have to be | |
92 | a matching MAC. | |
93 | ||
0fde8acd DM |
94 | 1.7 transport: chacha20-poly1305@openssh.com authenticated encryption |
95 | ||
96 | OpenSSH supports authenticated encryption using ChaCha20 and Poly1305 | |
97 | as described in PROTOCOL.chacha20poly1305. | |
98 | ||
e4870c09 DM |
99 | 1.8 transport: curve25519-sha256@libssh.org key exchange algorithm |
100 | ||
101 | OpenSSH supports the use of ECDH in Curve25519 for key exchange as | |
102 | described at: | |
103 | http://git.libssh.org/users/aris/libssh.git/plain/doc/curve25519-sha256@libssh.org.txt?h=curve25519 | |
104 | ||
aa192030 | 105 | This is identical to curve25519-sha256 as later published in RFC8731. |
106 | ||
dce6d80d | 107 | 1.9 transport: ping facility |
108 | ||
109 | OpenSSH implements a transport level ping message SSH2_MSG_PING | |
110 | and a corresponding SSH2_MSG_PONG reply. | |
111 | ||
112 | #define SSH2_MSG_PING 192 | |
113 | #define SSH2_MSG_PONG 193 | |
114 | ||
115 | The ping message is simply: | |
116 | ||
117 | byte SSH_MSG_PING | |
118 | string data | |
119 | ||
120 | The reply copies the data (which may be the empty string) from the | |
121 | ping: | |
122 | ||
123 | byte SSH_MSG_PONG | |
124 | string data | |
125 | ||
126 | Replies are sent in order. They are sent immediately except when rekeying | |
127 | is in progress, in which case they are queued until rekeying completes. | |
128 | ||
129 | The server advertises support for these messages using the | |
130 | SSH2_MSG_EXT_INFO mechanism (RFC8308), with the following message: | |
131 | ||
132 | string "ping@openssh.com" | |
133 | string "0" (version) | |
134 | ||
135 | The ping/reply message is implemented at the transport layer rather | |
136 | than as a named global or channel request to allow pings with very | |
137 | short packet lengths, which would not be possible with other | |
138 | approaches. | |
139 | ||
5413b1c7 | 140 | 1.10 transport: strict key exchange extension |
1edb00c5 | 141 | |
142 | OpenSSH supports a number of transport-layer hardening measures under | |
143 | a "strict KEX" feature. This feature is signalled similarly to the | |
144 | RFC8308 ext-info feature: by including a additional algorithm in the | |
64ddf776 | 145 | initial SSH2_MSG_KEXINIT kex_algorithms field. The client may append |
1edb00c5 | 146 | "kex-strict-c-v00@openssh.com" to its kex_algorithms and the server |
147 | may append "kex-strict-s-v00@openssh.com". These pseudo-algorithms | |
148 | are only valid in the initial SSH2_MSG_KEXINIT and MUST be ignored | |
149 | if they are present in subsequent SSH2_MSG_KEXINIT packets. | |
150 | ||
151 | When an endpoint that supports this extension observes this algorithm | |
152 | name in a peer's KEXINIT packet, it MUST make the following changes to | |
64ddf776 | 153 | the protocol: |
1edb00c5 | 154 | |
f64cede2 | 155 | a) During initial KEX, terminate the connection if out-of-sequence |
156 | packet or any message that is not strictly required by KEX is | |
157 | received. This includes terminating the connection if the first | |
158 | packet received is not SSH2_MSG_KEXINIT. Unexpected packets for | |
159 | the purpose of strict KEX include messages that are otherwise | |
160 | valid at any time during the connection such as SSH2_MSG_DEBUG, | |
161 | SSH2_MSG_IGNORE or SSH2_MSG_UNIMPLEMENTED. | |
1edb00c5 | 162 | b) After sending or receiving a SSH2_MSG_NEWKEYS message, reset the |
163 | packet sequence number to zero. This behaviour persists for the | |
164 | duration of the connection (i.e. not just the first | |
165 | SSH2_MSG_NEWKEYS). | |
166 | ||
5413b1c7 | 167 | 1.11 transport: SSH2_MSG_EXT_INFO during user authentication |
a7ed931c | 168 | |
169 | This protocol extension allows the SSH2_MSG_EXT_INFO to be sent | |
170 | during user authentication. RFC8308 does allow a second | |
171 | SSH2_MSG_EXT_INFO notification, but it may only be sent at the end | |
172 | of user authentication and this is too late to signal per-user | |
173 | server signature algorithms. | |
174 | ||
175 | Support for receiving the SSH2_MSG_EXT_INFO message during user | |
176 | authentication is signalled by the client including a | |
177 | "ext-info-in-auth@openssh.com" key via its initial SSH2_MSG_EXT_INFO | |
178 | set after the SSH2_MSG_NEWKEYS message. | |
179 | ||
180 | A server that supports this extension MAY send a second | |
181 | SSH2_MSG_EXT_INFO message any time after the client's first | |
182 | SSH2_MSG_USERAUTH_REQUEST, regardless of whether it succeed or fails. | |
183 | The client SHOULD be prepared to update the server-sig-algs that | |
184 | it received during an earlier SSH2_MSG_EXT_INFO with the later one. | |
185 | ||
eb8b60e3 DM |
186 | 2. Connection protocol changes |
187 | ||
188 | 2.1. connection: Channel write close extension "eow@openssh.com" | |
58a81148 DM |
189 | |
190 | The SSH connection protocol (rfc4254) provides the SSH_MSG_CHANNEL_EOF | |
191 | message to allow an endpoint to signal its peer that it will send no | |
192 | more data over a channel. Unfortunately, there is no symmetric way for | |
193 | an endpoint to request that its peer should cease sending data to it | |
194 | while still keeping the channel open for the endpoint to send data to | |
195 | the peer. | |
196 | ||
197 | This is desirable, since it saves the transmission of data that would | |
198 | otherwise need to be discarded and it allows an endpoint to signal local | |
199 | processes of the condition, e.g. by closing the corresponding file | |
200 | descriptor. | |
201 | ||
202 | OpenSSH implements a channel extension message to perform this | |
1f781b19 DT |
203 | signalling: "eow@openssh.com" (End Of Write). This message is sent by |
204 | an endpoint when the local output of a session channel is closed or | |
205 | experiences a write error. The message is formatted as follows: | |
58a81148 DM |
206 | |
207 | byte SSH_MSG_CHANNEL_REQUEST | |
208 | uint32 recipient channel | |
209 | string "eow@openssh.com" | |
210 | boolean FALSE | |
211 | ||
212 | On receiving this message, the peer SHOULD cease sending data of | |
213 | the channel and MAY signal the process from which the channel data | |
214 | originates (e.g. by closing its read file descriptor). | |
215 | ||
216 | As with the symmetric SSH_MSG_CHANNEL_EOF message, the channel does | |
217 | remain open after a "eow@openssh.com" has been sent and more data may | |
218 | still be sent in the other direction. This message does not consume | |
219 | window space and may be sent even if no window space is available. | |
220 | ||
6385e758 DM |
221 | NB. due to certain broken SSH implementations aborting upon receipt |
222 | of this message (in contravention of RFC4254 section 5.4), this | |
223 | message is only sent to OpenSSH peers (identified by banner). | |
6d755706 | 224 | Other SSH implementations may be listed to receive this message |
6385e758 DM |
225 | upon request. |
226 | ||
eb8b60e3 DM |
227 | 2.2. connection: disallow additional sessions extension |
228 | "no-more-sessions@openssh.com" | |
8901fa9c DT |
229 | |
230 | Most SSH connections will only ever request a single session, but a | |
231 | attacker may abuse a running ssh client to surreptitiously open | |
232 | additional sessions under their control. OpenSSH provides a global | |
233 | request "no-more-sessions@openssh.com" to mitigate this attack. | |
234 | ||
235 | When an OpenSSH client expects that it will never open another session | |
236 | (i.e. it has been started with connection multiplexing disabled), it | |
237 | will send the following global request: | |
238 | ||
239 | byte SSH_MSG_GLOBAL_REQUEST | |
240 | string "no-more-sessions@openssh.com" | |
241 | char want-reply | |
242 | ||
243 | On receipt of such a message, an OpenSSH server will refuse to open | |
244 | future channels of type "session" and instead immediately abort the | |
245 | connection. | |
246 | ||
247 | Note that this is not a general defence against compromised clients | |
248 | (that is impossible), but it thwarts a simple attack. | |
249 | ||
6385e758 DM |
250 | NB. due to certain broken SSH implementations aborting upon receipt |
251 | of this message, the no-more-sessions request is only sent to OpenSSH | |
252 | servers (identified by banner). Other SSH implementations may be | |
6d755706 | 253 | listed to receive this message upon request. |
6385e758 | 254 | |
eb8b60e3 | 255 | 2.3. connection: Tunnel forward extension "tun@openssh.com" |
e5d98290 | 256 | |
bd45afb5 | 257 | OpenSSH supports layer 2 and layer 3 tunnelling via the "tun@openssh.com" |
e5d98290 | 258 | channel type. This channel type supports forwarding of network packets |
4e636cf2 | 259 | with datagram boundaries intact between endpoints equipped with |
e5d98290 DT |
260 | interfaces like the BSD tun(4) device. Tunnel forwarding channels are |
261 | requested by the client with the following packet: | |
262 | ||
263 | byte SSH_MSG_CHANNEL_OPEN | |
264 | string "tun@openssh.com" | |
265 | uint32 sender channel | |
266 | uint32 initial window size | |
267 | uint32 maximum packet size | |
268 | uint32 tunnel mode | |
269 | uint32 remote unit number | |
270 | ||
271 | The "tunnel mode" parameter specifies whether the tunnel should forward | |
272 | layer 2 frames or layer 3 packets. It may take one of the following values: | |
273 | ||
274 | SSH_TUNMODE_POINTOPOINT 1 /* layer 3 packets */ | |
275 | SSH_TUNMODE_ETHERNET 2 /* layer 2 frames */ | |
276 | ||
277 | The "tunnel unit number" specifies the remote interface number, or may | |
0001576a | 278 | be 0x7fffffff to allow the server to automatically choose an interface. A |
f2705c8b DT |
279 | server that is not willing to open a client-specified unit should refuse |
280 | the request with a SSH_MSG_CHANNEL_OPEN_FAILURE error. On successful | |
281 | open, the server should reply with SSH_MSG_CHANNEL_OPEN_SUCCESS. | |
e5d98290 DT |
282 | |
283 | Once established the client and server may exchange packet or frames | |
284 | over the tunnel channel by encapsulating them in SSH protocol strings | |
285 | and sending them as channel data. This ensures that packet boundaries | |
286 | are kept intact. Specifically, packets are transmitted using normal | |
287 | SSH_MSG_CHANNEL_DATA packets: | |
288 | ||
289 | byte SSH_MSG_CHANNEL_DATA | |
290 | uint32 recipient channel | |
291 | string data | |
292 | ||
293 | The contents of the "data" field for layer 3 packets is: | |
294 | ||
295 | uint32 packet length | |
296 | uint32 address family | |
297 | byte[packet length - 4] packet data | |
298 | ||
299 | The "address family" field identifies the type of packet in the message. | |
300 | It may be one of: | |
301 | ||
302 | SSH_TUN_AF_INET 2 /* IPv4 */ | |
303 | SSH_TUN_AF_INET6 24 /* IPv6 */ | |
304 | ||
305 | The "packet data" field consists of the IPv4/IPv6 datagram itself | |
306 | without any link layer header. | |
307 | ||
f2705c8b | 308 | The contents of the "data" field for layer 2 packets is: |
e5d98290 DT |
309 | |
310 | uint32 packet length | |
311 | byte[packet length] frame | |
312 | ||
bd45afb5 | 313 | The "frame" field contains an IEEE 802.3 Ethernet frame, including |
e5d98290 DT |
314 | header. |
315 | ||
7acefbbc DM |
316 | 2.4. connection: Unix domain socket forwarding |
317 | ||
318 | OpenSSH supports local and remote Unix domain socket forwarding | |
319 | using the "streamlocal" extension. Forwarding is initiated as per | |
320 | TCP sockets but with a single path instead of a host and port. | |
321 | ||
322 | Similar to direct-tcpip, direct-streamlocal is sent by the client | |
323 | to request that the server make a connection to a Unix domain socket. | |
324 | ||
325 | byte SSH_MSG_CHANNEL_OPEN | |
326 | string "direct-streamlocal@openssh.com" | |
327 | uint32 sender channel | |
328 | uint32 initial window size | |
329 | uint32 maximum packet size | |
330 | string socket path | |
90ee563f | 331 | string reserved |
332 | uint32 reserved | |
7acefbbc DM |
333 | |
334 | Similar to forwarded-tcpip, forwarded-streamlocal is sent by the | |
335 | server when the client has previously send the server a streamlocal-forward | |
336 | GLOBAL_REQUEST. | |
337 | ||
338 | byte SSH_MSG_CHANNEL_OPEN | |
339 | string "forwarded-streamlocal@openssh.com" | |
340 | uint32 sender channel | |
341 | uint32 initial window size | |
342 | uint32 maximum packet size | |
343 | string socket path | |
344 | string reserved for future use | |
345 | ||
346 | The reserved field is not currently defined and is ignored on the | |
347 | remote end. It is intended to be used in the future to pass | |
348 | information about the socket file, such as ownership and mode. | |
349 | The client currently sends the empty string for this field. | |
350 | ||
351 | Similar to tcpip-forward, streamlocal-forward is sent by the client | |
352 | to request remote forwarding of a Unix domain socket. | |
353 | ||
354 | byte SSH2_MSG_GLOBAL_REQUEST | |
355 | string "streamlocal-forward@openssh.com" | |
356 | boolean TRUE | |
357 | string socket path | |
358 | ||
359 | Similar to cancel-tcpip-forward, cancel-streamlocal-forward is sent | |
360 | by the client cancel the forwarding of a Unix domain socket. | |
361 | ||
362 | byte SSH2_MSG_GLOBAL_REQUEST | |
363 | string "cancel-streamlocal-forward@openssh.com" | |
364 | boolean FALSE | |
365 | string socket path | |
366 | ||
44732de0 | 367 | 2.5. connection: hostkey update and rotation "hostkeys-00@openssh.com" |
368 | and "hostkeys-prove-00@openssh.com" | |
8d4f8725 | 369 | |
370 | OpenSSH supports a protocol extension allowing a server to inform | |
523463a3 | 371 | a client of all its protocol v.2 host keys after user-authentication |
8d4f8725 | 372 | has completed. |
373 | ||
374 | byte SSH_MSG_GLOBAL_REQUEST | |
44732de0 | 375 | string "hostkeys-00@openssh.com" |
63238f5a | 376 | char 0 /* want-reply */ |
8d4f8725 | 377 | string[] hostkeys |
378 | ||
523463a3 | 379 | Upon receiving this message, a client should check which of the |
fcdb9d77 | 380 | supplied host keys are present in known_hosts. |
381 | ||
382 | Note that the server may send key types that the client does not | |
0001576a | 383 | support. The client should disregard such keys if they are received. |
fcdb9d77 | 384 | |
385 | If the client identifies any keys that are not present for the host, | |
386 | it should send a "hostkeys-prove@openssh.com" message to request the | |
387 | server prove ownership of the private half of the key. | |
8d4f8725 | 388 | |
523463a3 | 389 | byte SSH_MSG_GLOBAL_REQUEST |
44732de0 | 390 | string "hostkeys-prove-00@openssh.com" |
523463a3 | 391 | char 1 /* want-reply */ |
392 | string[] hostkeys | |
393 | ||
394 | When a server receives this message, it should generate a signature | |
395 | using each requested key over the following: | |
396 | ||
44732de0 | 397 | string "hostkeys-prove-00@openssh.com" |
523463a3 | 398 | string session identifier |
523463a3 | 399 | string hostkey |
400 | ||
401 | These signatures should be included in the reply, in the order matching | |
402 | the hostkeys in the request: | |
403 | ||
404 | byte SSH_MSG_REQUEST_SUCCESS | |
405 | string[] signatures | |
406 | ||
407 | When the client receives this reply (and not a failure), it should | |
408 | validate the signatures and may update its known_hosts file, adding keys | |
409 | that it has not seen before and deleting keys for the server host that | |
410 | are no longer offered. | |
411 | ||
412 | These extensions let a client learn key types that it had not previously | |
413 | encountered, thereby allowing it to potentially upgrade from weaker | |
414 | key algorithms to better ones. It also supports graceful key rotation: | |
415 | a server may offer multiple keys of the same type for a period (to | |
416 | give clients an opportunity to learn them using this extension) before | |
417 | removing the deprecated key from those offered. | |
8d4f8725 | 418 | |
a46ac4d8 | 419 | 2.6. connection: SIGINFO support for "signal" channel request |
420 | ||
421 | The SSH channels protocol (RFC4254 section 6.9) supports sending a | |
422 | signal to a session attached to a channel. OpenSSH supports one | |
423 | extension signal "INFO@openssh.com" that allows sending SIGINFO on | |
424 | BSD-derived systems. | |
425 | ||
266678e1 | 426 | 3. Authentication protocol changes |
eb8b60e3 | 427 | |
266678e1 | 428 | 3.1. Host-bound public key authentication |
429 | ||
430 | This is trivial change to the traditional "publickey" authentication | |
431 | method. The authentication request is identical to the original method | |
432 | but for the name and one additional field: | |
433 | ||
434 | byte SSH2_MSG_USERAUTH_REQUEST | |
435 | string username | |
436 | string "ssh-connection" | |
437 | string "publickey-hostbound-v00@openssh.com" | |
438 | bool has_signature | |
439 | string pkalg | |
440 | string public key | |
441 | string server host key | |
442 | ||
443 | Because the entire SSH2_MSG_USERAUTH_REQUEST message is included in | |
444 | the signed data, this ensures that a binding between the destination | |
445 | user, the server identity and the session identifier is visible to the | |
446 | signer. OpenSSH uses this binding via signed data to implement per-key | |
447 | restrictions in ssh-agent. | |
448 | ||
449 | A server may advertise this method using the SSH2_MSG_EXT_INFO | |
450 | mechanism (RFC8308), with the following message: | |
451 | ||
452 | string "publickey-hostbound@openssh.com" | |
453 | string "0" (version) | |
454 | ||
455 | Clients should prefer host-bound authentication when advertised by | |
456 | server. | |
457 | ||
458 | 4. SFTP protocol changes | |
459 | ||
460 | 4.1. sftp: Reversal of arguments to SSH_FXP_SYMLINK | |
58a81148 DM |
461 | |
462 | When OpenSSH's sftp-server was implemented, the order of the arguments | |
bd45afb5 | 463 | to the SSH_FXP_SYMLINK method was inadvertently reversed. Unfortunately, |
58a81148 DM |
464 | the reversal was not noticed until the server was widely deployed. Since |
465 | fixing this to follow the specification would cause incompatibility, the | |
466 | current order was retained. For correct operation, clients should send | |
467 | SSH_FXP_SYMLINK as follows: | |
468 | ||
469 | uint32 id | |
470 | string targetpath | |
471 | string linkpath | |
472 | ||
266678e1 | 473 | 4.2. sftp: Server extension announcement in SSH_FXP_VERSION |
58a81148 DM |
474 | |
475 | OpenSSH's sftp-server lists the extensions it supports using the | |
476 | standard extension announcement mechanism in the SSH_FXP_VERSION server | |
477 | hello packet: | |
478 | ||
479 | uint32 3 /* protocol version */ | |
480 | string ext1-name | |
481 | string ext1-version | |
482 | string ext2-name | |
483 | string ext2-version | |
484 | ... | |
485 | string extN-name | |
486 | string extN-version | |
487 | ||
488 | Each extension reports its integer version number as an ASCII encoded | |
489 | string, e.g. "1". The version will be incremented if the extension is | |
490 | ever changed in an incompatible way. The server MAY advertise the same | |
491 | extension with multiple versions (though this is unlikely). Clients MUST | |
bd45afb5 | 492 | check the version number before attempting to use the extension. |
58a81148 | 493 | |
266678e1 | 494 | 4.3. sftp: Extension request "posix-rename@openssh.com" |
58a81148 DM |
495 | |
496 | This operation provides a rename operation with POSIX semantics, which | |
497 | are different to those provided by the standard SSH_FXP_RENAME in | |
498 | draft-ietf-secsh-filexfer-02.txt. This request is implemented as a | |
499 | SSH_FXP_EXTENDED request with the following format: | |
500 | ||
501 | uint32 id | |
502 | string "posix-rename@openssh.com" | |
503 | string oldpath | |
504 | string newpath | |
505 | ||
506 | On receiving this request the server will perform the POSIX operation | |
507 | rename(oldpath, newpath) and will respond with a SSH_FXP_STATUS message. | |
508 | This extension is advertised in the SSH_FXP_VERSION hello with version | |
509 | "1". | |
510 | ||
266678e1 | 511 | 4.4. sftp: Extension requests "statvfs@openssh.com" and |
58a81148 DM |
512 | "fstatvfs@openssh.com" |
513 | ||
514 | These requests correspond to the statvfs and fstatvfs POSIX system | |
515 | interfaces. The "statvfs@openssh.com" request operates on an explicit | |
516 | pathname, and is formatted as follows: | |
517 | ||
518 | uint32 id | |
519 | string "statvfs@openssh.com" | |
520 | string path | |
521 | ||
bd45afb5 | 522 | The "fstatvfs@openssh.com" operates on an open file handle: |
58a81148 DM |
523 | |
524 | uint32 id | |
525 | string "fstatvfs@openssh.com" | |
526 | string handle | |
527 | ||
528 | These requests return a SSH_FXP_STATUS reply on failure. On success they | |
529 | return the following SSH_FXP_EXTENDED_REPLY reply: | |
530 | ||
531 | uint32 id | |
cd2ada6d DT |
532 | uint64 f_bsize /* file system block size */ |
533 | uint64 f_frsize /* fundamental fs block size */ | |
58a81148 DM |
534 | uint64 f_blocks /* number of blocks (unit f_frsize) */ |
535 | uint64 f_bfree /* free blocks in file system */ | |
536 | uint64 f_bavail /* free blocks for non-root */ | |
537 | uint64 f_files /* total file inodes */ | |
538 | uint64 f_ffree /* free file inodes */ | |
539 | uint64 f_favail /* free file inodes for to non-root */ | |
17ec5d4e | 540 | uint64 f_fsid /* file system id */ |
cd2ada6d DT |
541 | uint64 f_flag /* bit mask of f_flag values */ |
542 | uint64 f_namemax /* maximum filename length */ | |
58a81148 DM |
543 | |
544 | The values of the f_flag bitmask are as follows: | |
545 | ||
546 | #define SSH_FXE_STATVFS_ST_RDONLY 0x1 /* read-only */ | |
547 | #define SSH_FXE_STATVFS_ST_NOSUID 0x2 /* no setuid */ | |
548 | ||
c9c96f2e DM |
549 | Both the "statvfs@openssh.com" and "fstatvfs@openssh.com" extensions are |
550 | advertised in the SSH_FXP_VERSION hello with version "2". | |
17ec5d4e | 551 | |
266678e1 | 552 | 4.5. sftp: Extension request "hardlink@openssh.com" |
af1f9092 DT |
553 | |
554 | This request is for creating a hard link to a regular file. This | |
555 | request is implemented as a SSH_FXP_EXTENDED request with the | |
556 | following format: | |
557 | ||
558 | uint32 id | |
559 | string "hardlink@openssh.com" | |
560 | string oldpath | |
561 | string newpath | |
562 | ||
563 | On receiving this request the server will perform the operation | |
564 | link(oldpath, newpath) and will respond with a SSH_FXP_STATUS message. | |
565 | This extension is advertised in the SSH_FXP_VERSION hello with version | |
566 | "1". | |
567 | ||
266678e1 | 568 | 4.6. sftp: Extension request "fsync@openssh.com" |
f29238e6 DM |
569 | |
570 | This request asks the server to call fsync(2) on an open file handle. | |
571 | ||
572 | uint32 id | |
573 | string "fsync@openssh.com" | |
574 | string handle | |
575 | ||
7988bfc4 | 576 | On receiving this request, a server will call fsync(handle_fd) and will |
f29238e6 DM |
577 | respond with a SSH_FXP_STATUS message. |
578 | ||
579 | This extension is advertised in the SSH_FXP_VERSION hello with version | |
580 | "1". | |
581 | ||
266678e1 | 582 | 4.7. sftp: Extension request "lsetstat@openssh.com" |
16eacdb0 | 583 | |
584 | This request is like the "setstat" command, but sets file attributes on | |
585 | symlinks. It is implemented as a SSH_FXP_EXTENDED request with the | |
586 | following format: | |
587 | ||
588 | uint32 id | |
589 | string "lsetstat@openssh.com" | |
590 | string path | |
591 | ATTRS attrs | |
592 | ||
593 | See the "setstat" command for more details. | |
594 | ||
595 | This extension is advertised in the SSH_FXP_VERSION hello with version | |
596 | "1". | |
597 | ||
266678e1 | 598 | 4.8. sftp: Extension request "limits@openssh.com" |
788cbc5b | 599 | |
600 | This request is used to determine various limits the server might impose. | |
601 | Clients should not attempt to exceed these limits as the server might sever | |
602 | the connection immediately. | |
603 | ||
604 | uint32 id | |
605 | string "limits@openssh.com" | |
606 | ||
607 | The server will respond with a SSH_FXP_EXTENDED_REPLY reply: | |
608 | ||
609 | uint32 id | |
610 | uint64 max-packet-length | |
611 | uint64 max-read-length | |
612 | uint64 max-write-length | |
613 | uint64 max-open-handles | |
614 | ||
615 | The 'max-packet-length' applies to the total number of bytes in a | |
616 | single SFTP packet. Servers SHOULD set this at least to 34000. | |
617 | ||
618 | The 'max-read-length' is the largest length in a SSH_FXP_READ packet. | |
619 | Even if the client requests a larger size, servers will usually respond | |
620 | with a shorter SSH_FXP_DATA packet. Servers SHOULD set this at least to | |
621 | 32768. | |
622 | ||
623 | The 'max-write-length' is the largest length in a SSH_FXP_WRITE packet | |
624 | the server will accept. Servers SHOULD set this at least to 32768. | |
625 | ||
626 | The 'max-open-handles' is the maximum number of active handles that the | |
627 | server allows (e.g. handles created by SSH_FXP_OPEN and SSH_FXP_OPENDIR | |
628 | packets). Servers MAY count internal file handles against this limit | |
629 | (e.g. system logging or stdout/stderr), so clients SHOULD NOT expect to | |
630 | open this many handles in practice. | |
631 | ||
632 | If the server doesn't enforce a specific limit, then the field may be | |
633 | set to 0. This implies the server relies on the OS to enforce limits | |
634 | (e.g. available memory or file handles), and such limits might be | |
635 | dynamic. The client SHOULD take care to not try to exceed reasonable | |
636 | limits. | |
637 | ||
638 | This extension is advertised in the SSH_FXP_VERSION hello with version | |
639 | "1". | |
640 | ||
266678e1 | 641 | 4.9. sftp: Extension request "expand-path@openssh.com" |
2ab86401 | 642 | |
643 | This request supports canonicalisation of relative paths and | |
644 | those that need tilde-expansion, i.e. "~", "~/..." and "~user/..." | |
645 | These paths are expanded using shell-like rules and the resultant | |
646 | path is canonicalised similarly to SSH2_FXP_REALPATH. | |
647 | ||
648 | It is implemented as a SSH_FXP_EXTENDED request with the following | |
649 | format: | |
650 | ||
651 | uint32 id | |
652 | string "expand-path@openssh.com" | |
653 | string path | |
654 | ||
655 | Its reply is the same format as that of SSH2_FXP_REALPATH. | |
656 | ||
657 | This extension is advertised in the SSH_FXP_VERSION hello with version | |
658 | "1". | |
659 | ||
7988bfc4 | 660 | 4.10. sftp: Extension request "copy-data" |
661 | ||
662 | This request asks the server to copy data from one open file handle and | |
663 | write it to a different open file handle. This avoids needing to transfer | |
664 | the data across the network twice (a download followed by an upload). | |
665 | ||
666 | byte SSH_FXP_EXTENDED | |
667 | uint32 id | |
668 | string "copy-data" | |
669 | string read-from-handle | |
670 | uint64 read-from-offset | |
671 | uint64 read-data-length | |
672 | string write-to-handle | |
673 | uint64 write-to-offset | |
674 | ||
675 | The server will copy read-data-length bytes starting from | |
676 | read-from-offset from the read-from-handle and write them to | |
677 | write-to-handle starting from write-to-offset, and then respond with a | |
678 | SSH_FXP_STATUS message. | |
679 | ||
680 | It's equivalent to issuing a series of SSH_FXP_READ requests on | |
681 | read-from-handle and a series of requests of SSH_FXP_WRITE on | |
682 | write-to-handle. | |
683 | ||
684 | If read-from-handle and write-to-handle are the same, the server will | |
685 | fail the request and respond with a SSH_FX_INVALID_PARAMETER message. | |
686 | ||
687 | If read-data-length is 0, then the server will read data from the | |
688 | read-from-handle until EOF is reached. | |
689 | ||
690 | This extension is advertised in the SSH_FXP_VERSION hello with version | |
691 | "1". | |
692 | ||
693 | This request is identical to the "copy-data" request documented in: | |
694 | ||
695 | https://tools.ietf.org/html/draft-ietf-secsh-filexfer-extensions-00#section-7 | |
696 | ||
730a8060 | 697 | 4.11. sftp: Extension request "home-directory" |
698 | ||
699 | This request asks the server to expand the specified user's home directory. | |
700 | An empty username implies the current user. This can be used by the client | |
701 | to expand ~/ type paths locally. | |
702 | ||
703 | byte SSH_FXP_EXTENDED | |
704 | uint32 id | |
705 | string "home-directory" | |
706 | string username | |
707 | ||
708 | This extension is advertised in the SSH_FXP_VERSION hello with version | |
709 | "1". | |
710 | ||
711 | This provides similar information as the "expand-path@openssh.com" extension. | |
712 | ||
713 | This request is identical to the "home-directory" request documented in: | |
714 | ||
715 | https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-extensions-00#section-5 | |
716 | ||
74b77f74 | 717 | 4.12. sftp: Extension request "users-groups-by-id@openssh.com" |
718 | ||
5c3f18fb | 719 | This request asks the server to return user and/or group names that |
74b77f74 | 720 | correspond to one or more IDs (e.g. as returned from a SSH_FXP_STAT |
721 | request). This may be used by the client to provide usernames in | |
722 | directory listings. | |
723 | ||
724 | byte SSH_FXP_EXTENDED | |
725 | uint32 id | |
726 | string "users-groups-by-id@openssh.com" | |
727 | string uids | |
728 | string gids | |
729 | ||
730 | Where "uids" and "gids" consists of one or more integer user or group | |
731 | identifiers: | |
732 | ||
733 | uint32 id-0 | |
734 | ... | |
735 | ||
736 | The server will reply with a SSH_FXP_EXTENDED_REPLY: | |
737 | ||
738 | byte SSH_FXP_EXTENDED_REPLY | |
4c3cf362 | 739 | uint32 id |
74b77f74 | 740 | string usernames |
741 | string groupnames | |
742 | ||
743 | Where "username" and "groupnames" consists of names in identical request | |
744 | order to "uids" and "gids" respectively: | |
745 | ||
746 | string name-0 | |
747 | ... | |
748 | ||
749 | If a name cannot be identified for a given user or group ID, an empty | |
750 | string will be returned in its place. | |
751 | ||
752 | It is acceptable for either "uids" or "gids" to be an empty set, in | |
753 | which case the respective "usernames" or "groupnames" list will also | |
754 | be empty. | |
755 | ||
756 | This extension is advertised in the SSH_FXP_VERSION hello with version | |
757 | "1". | |
758 | ||
266678e1 | 759 | 5. Miscellaneous changes |
7c712966 | 760 | |
266678e1 | 761 | 5.1 Public key format |
7c712966 | 762 | |
763 | OpenSSH public keys, as generated by ssh-keygen(1) and appearing in | |
764 | authorized_keys files, are formatted as a single line of text consisting | |
765 | of the public key algorithm name followed by a base64-encoded key blob. | |
e1b26ce5 | 766 | The public key blob (before base64 encoding) is the same format used for |
767 | the encoding of public keys sent on the wire: as described in RFC4253 | |
768 | section 6.6 for RSA and DSA keys, RFC5656 section 3.1 for ECDSA keys | |
769 | and the "New public key formats" section of PROTOCOL.certkeys for the | |
770 | OpenSSH certificate formats. | |
7c712966 | 771 | |
266678e1 | 772 | 5.2 Private key format |
7c712966 | 773 | |
774 | OpenSSH private keys, as generated by ssh-keygen(1) use the format | |
775 | described in PROTOCOL.key by default. As a legacy option, PEM format | |
776 | (RFC7468) private keys are also supported for RSA, DSA and ECDSA keys | |
777 | and were the default format before OpenSSH 7.8. | |
778 | ||
266678e1 | 779 | 5.3 KRL format |
7c712966 | 780 | |
781 | OpenSSH supports a compact format for Key Revocation Lists (KRLs). This | |
782 | format is described in the PROTOCOL.krl file. | |
783 | ||
266678e1 | 784 | 5.4 Connection multiplexing |
7c712966 | 785 | |
786 | OpenSSH's connection multiplexing uses messages as described in | |
787 | PROTOCOL.mux over a Unix domain socket for communications between a | |
788 | master instance and later clients. | |
789 | ||
266678e1 | 790 | 5.5. Agent protocol extensions |
791 | ||
792 | OpenSSH extends the usual agent protocol. These changes are documented | |
793 | in the PROTOCOL.agent file. | |
794 | ||
4c3cf362 | 795 | $OpenBSD: PROTOCOL,v 1.55 2024/01/08 05:05:15 djm Exp $ |