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