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 7https://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 23https://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 34https://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 1662. Connection protocol changes 167 1682.1. connection: Channel write close extension "eow@openssh.com" 169 170The SSH connection protocol (rfc4254) provides the SSH_MSG_CHANNEL_EOF 171message to allow an endpoint to signal its peer that it will send no 172more data over a channel. Unfortunately, there is no symmetric way for 173an endpoint to request that its peer should cease sending data to it 174while still keeping the channel open for the endpoint to send data to 175the peer. 176 177This is desirable, since it saves the transmission of data that would 178otherwise need to be discarded and it allows an endpoint to signal local 179processes of the condition, e.g. by closing the corresponding file 180descriptor. 181 182OpenSSH implements a channel extension message to perform this 183signalling: "eow@openssh.com" (End Of Write). This message is sent by 184an endpoint when the local output of a session channel is closed or 185experiences a write error. The message is formatted as follows: 186 187 byte SSH_MSG_CHANNEL_REQUEST 188 uint32 recipient channel 189 string "eow@openssh.com" 190 boolean FALSE 191 192On receiving this message, the peer SHOULD cease sending data of 193the channel and MAY signal the process from which the channel data 194originates (e.g. by closing its read file descriptor). 195 196As with the symmetric SSH_MSG_CHANNEL_EOF message, the channel does 197remain open after a "eow@openssh.com" has been sent and more data may 198still be sent in the other direction. This message does not consume 199window space and may be sent even if no window space is available. 200 201NB. due to certain broken SSH implementations aborting upon receipt 202of this message (in contravention of RFC4254 section 5.4), this 203message is only sent to OpenSSH peers (identified by banner). 204Other SSH implementations may be listed to receive this message 205upon request. 206 2072.2. connection: disallow additional sessions extension 208 "no-more-sessions@openssh.com" 209 210Most SSH connections will only ever request a single session, but a 211attacker may abuse a running ssh client to surreptitiously open 212additional sessions under their control. OpenSSH provides a global 213request "no-more-sessions@openssh.com" to mitigate this attack. 214 215When an OpenSSH client expects that it will never open another session 216(i.e. it has been started with connection multiplexing disabled), it 217will send the following global request: 218 219 byte SSH_MSG_GLOBAL_REQUEST 220 string "no-more-sessions@openssh.com" 221 char want-reply 222 223On receipt of such a message, an OpenSSH server will refuse to open 224future channels of type "session" and instead immediately abort the 225connection. 226 227Note that this is not a general defence against compromised clients 228(that is impossible), but it thwarts a simple attack. 229 230NB. due to certain broken SSH implementations aborting upon receipt 231of this message, the no-more-sessions request is only sent to OpenSSH 232servers (identified by banner). Other SSH implementations may be 233listed to receive this message upon request. 234 2352.3. connection: Tunnel forward extension "tun@openssh.com" 236 237OpenSSH supports layer 2 and layer 3 tunnelling via the "tun@openssh.com" 238channel type. This channel type supports forwarding of network packets 239with datagram boundaries intact between endpoints equipped with 240interfaces like the BSD tun(4) device. Tunnel forwarding channels are 241requested by the client with the following packet: 242 243 byte SSH_MSG_CHANNEL_OPEN 244 string "tun@openssh.com" 245 uint32 sender channel 246 uint32 initial window size 247 uint32 maximum packet size 248 uint32 tunnel mode 249 uint32 remote unit number 250 251The "tunnel mode" parameter specifies whether the tunnel should forward 252layer 2 frames or layer 3 packets. It may take one of the following values: 253 254 SSH_TUNMODE_POINTOPOINT 1 /* layer 3 packets */ 255 SSH_TUNMODE_ETHERNET 2 /* layer 2 frames */ 256 257The "tunnel unit number" specifies the remote interface number, or may 258be 0x7fffffff to allow the server to automatically choose an interface. A 259server that is not willing to open a client-specified unit should refuse 260the request with a SSH_MSG_CHANNEL_OPEN_FAILURE error. On successful 261open, the server should reply with SSH_MSG_CHANNEL_OPEN_SUCCESS. 262 263Once established the client and server may exchange packet or frames 264over the tunnel channel by encapsulating them in SSH protocol strings 265and sending them as channel data. This ensures that packet boundaries 266are kept intact. Specifically, packets are transmitted using normal 267SSH_MSG_CHANNEL_DATA packets: 268 269 byte SSH_MSG_CHANNEL_DATA 270 uint32 recipient channel 271 string data 272 273The contents of the "data" field for layer 3 packets is: 274 275 uint32 packet length 276 uint32 address family 277 byte[packet length - 4] packet data 278 279The "address family" field identifies the type of packet in the message. 280It may be one of: 281 282 SSH_TUN_AF_INET 2 /* IPv4 */ 283 SSH_TUN_AF_INET6 24 /* IPv6 */ 284 285The "packet data" field consists of the IPv4/IPv6 datagram itself 286without any link layer header. 287 288The contents of the "data" field for layer 2 packets is: 289 290 uint32 packet length 291 byte[packet length] frame 292 293The "frame" field contains an IEEE 802.3 Ethernet frame, including 294header. 295 2962.4. connection: Unix domain socket forwarding 297 298OpenSSH supports local and remote Unix domain socket forwarding 299using the "streamlocal" extension. Forwarding is initiated as per 300TCP sockets but with a single path instead of a host and port. 301 302Similar to direct-tcpip, direct-streamlocal is sent by the client 303to request that the server make a connection to a Unix domain socket. 304 305 byte SSH_MSG_CHANNEL_OPEN 306 string "direct-streamlocal@openssh.com" 307 uint32 sender channel 308 uint32 initial window size 309 uint32 maximum packet size 310 string socket path 311 string reserved 312 uint32 reserved 313 314Similar to forwarded-tcpip, forwarded-streamlocal is sent by the 315server when the client has previously send the server a streamlocal-forward 316GLOBAL_REQUEST. 317 318 byte SSH_MSG_CHANNEL_OPEN 319 string "forwarded-streamlocal@openssh.com" 320 uint32 sender channel 321 uint32 initial window size 322 uint32 maximum packet size 323 string socket path 324 string reserved for future use 325 326The reserved field is not currently defined and is ignored on the 327remote end. It is intended to be used in the future to pass 328information about the socket file, such as ownership and mode. 329The client currently sends the empty string for this field. 330 331Similar to tcpip-forward, streamlocal-forward is sent by the client 332to request remote forwarding of a Unix domain socket. 333 334 byte SSH2_MSG_GLOBAL_REQUEST 335 string "streamlocal-forward@openssh.com" 336 boolean TRUE 337 string socket path 338 339Similar to cancel-tcpip-forward, cancel-streamlocal-forward is sent 340by the client cancel the forwarding of a Unix domain socket. 341 342 byte SSH2_MSG_GLOBAL_REQUEST 343 string "cancel-streamlocal-forward@openssh.com" 344 boolean FALSE 345 string socket path 346 3472.5. connection: hostkey update and rotation "hostkeys-00@openssh.com" 348and "hostkeys-prove-00@openssh.com" 349 350OpenSSH supports a protocol extension allowing a server to inform 351a client of all its protocol v.2 host keys after user-authentication 352has completed. 353 354 byte SSH_MSG_GLOBAL_REQUEST 355 string "hostkeys-00@openssh.com" 356 char 0 /* want-reply */ 357 string[] hostkeys 358 359Upon receiving this message, a client should check which of the 360supplied host keys are present in known_hosts. 361 362Note that the server may send key types that the client does not 363support. The client should disregard such keys if they are received. 364 365If the client identifies any keys that are not present for the host, 366it should send a "hostkeys-prove@openssh.com" message to request the 367server prove ownership of the private half of the key. 368 369 byte SSH_MSG_GLOBAL_REQUEST 370 string "hostkeys-prove-00@openssh.com" 371 char 1 /* want-reply */ 372 string[] hostkeys 373 374When a server receives this message, it should generate a signature 375using each requested key over the following: 376 377 string "hostkeys-prove-00@openssh.com" 378 string session identifier 379 string hostkey 380 381These signatures should be included in the reply, in the order matching 382the hostkeys in the request: 383 384 byte SSH_MSG_REQUEST_SUCCESS 385 string[] signatures 386 387When the client receives this reply (and not a failure), it should 388validate the signatures and may update its known_hosts file, adding keys 389that it has not seen before and deleting keys for the server host that 390are no longer offered. 391 392These extensions let a client learn key types that it had not previously 393encountered, thereby allowing it to potentially upgrade from weaker 394key algorithms to better ones. It also supports graceful key rotation: 395a server may offer multiple keys of the same type for a period (to 396give clients an opportunity to learn them using this extension) before 397removing the deprecated key from those offered. 398 3992.6. connection: SIGINFO support for "signal" channel request 400 401The SSH channels protocol (RFC4254 section 6.9) supports sending a 402signal to a session attached to a channel. OpenSSH supports one 403extension signal "INFO@openssh.com" that allows sending SIGINFO on 404BSD-derived systems. 405 4063. Authentication protocol changes 407 4083.1. Host-bound public key authentication 409 410This is trivial change to the traditional "publickey" authentication 411method. The authentication request is identical to the original method 412but for the name and one additional field: 413 414 byte SSH2_MSG_USERAUTH_REQUEST 415 string username 416 string "ssh-connection" 417 string "publickey-hostbound-v00@openssh.com" 418 bool has_signature 419 string pkalg 420 string public key 421 string server host key 422 423Because the entire SSH2_MSG_USERAUTH_REQUEST message is included in 424the signed data, this ensures that a binding between the destination 425user, the server identity and the session identifier is visible to the 426signer. OpenSSH uses this binding via signed data to implement per-key 427restrictions in ssh-agent. 428 429A server may advertise this method using the SSH2_MSG_EXT_INFO 430mechanism (RFC8308), with the following message: 431 432 string "publickey-hostbound@openssh.com" 433 string "0" (version) 434 435Clients should prefer host-bound authentication when advertised by 436server. 437 4384. SFTP protocol changes 439 4404.1. sftp: Reversal of arguments to SSH_FXP_SYMLINK 441 442When OpenSSH's sftp-server was implemented, the order of the arguments 443to the SSH_FXP_SYMLINK method was inadvertently reversed. Unfortunately, 444the reversal was not noticed until the server was widely deployed. Since 445fixing this to follow the specification would cause incompatibility, the 446current order was retained. For correct operation, clients should send 447SSH_FXP_SYMLINK as follows: 448 449 uint32 id 450 string targetpath 451 string linkpath 452 4534.2. sftp: Server extension announcement in SSH_FXP_VERSION 454 455OpenSSH's sftp-server lists the extensions it supports using the 456standard extension announcement mechanism in the SSH_FXP_VERSION server 457hello packet: 458 459 uint32 3 /* protocol version */ 460 string ext1-name 461 string ext1-version 462 string ext2-name 463 string ext2-version 464 ... 465 string extN-name 466 string extN-version 467 468Each extension reports its integer version number as an ASCII encoded 469string, e.g. "1". The version will be incremented if the extension is 470ever changed in an incompatible way. The server MAY advertise the same 471extension with multiple versions (though this is unlikely). Clients MUST 472check the version number before attempting to use the extension. 473 4744.3. sftp: Extension request "posix-rename@openssh.com" 475 476This operation provides a rename operation with POSIX semantics, which 477are different to those provided by the standard SSH_FXP_RENAME in 478draft-ietf-secsh-filexfer-02.txt. This request is implemented as a 479SSH_FXP_EXTENDED request with the following format: 480 481 uint32 id 482 string "posix-rename@openssh.com" 483 string oldpath 484 string newpath 485 486On receiving this request the server will perform the POSIX operation 487rename(oldpath, newpath) and will respond with a SSH_FXP_STATUS message. 488This extension is advertised in the SSH_FXP_VERSION hello with version 489"1". 490 4914.4. sftp: Extension requests "statvfs@openssh.com" and 492 "fstatvfs@openssh.com" 493 494These requests correspond to the statvfs and fstatvfs POSIX system 495interfaces. The "statvfs@openssh.com" request operates on an explicit 496pathname, and is formatted as follows: 497 498 uint32 id 499 string "statvfs@openssh.com" 500 string path 501 502The "fstatvfs@openssh.com" operates on an open file handle: 503 504 uint32 id 505 string "fstatvfs@openssh.com" 506 string handle 507 508These requests return a SSH_FXP_STATUS reply on failure. On success they 509return the following SSH_FXP_EXTENDED_REPLY reply: 510 511 uint32 id 512 uint64 f_bsize /* file system block size */ 513 uint64 f_frsize /* fundamental fs block size */ 514 uint64 f_blocks /* number of blocks (unit f_frsize) */ 515 uint64 f_bfree /* free blocks in file system */ 516 uint64 f_bavail /* free blocks for non-root */ 517 uint64 f_files /* total file inodes */ 518 uint64 f_ffree /* free file inodes */ 519 uint64 f_favail /* free file inodes for to non-root */ 520 uint64 f_fsid /* file system id */ 521 uint64 f_flag /* bit mask of f_flag values */ 522 uint64 f_namemax /* maximum filename length */ 523 524The values of the f_flag bitmask are as follows: 525 526 #define SSH_FXE_STATVFS_ST_RDONLY 0x1 /* read-only */ 527 #define SSH_FXE_STATVFS_ST_NOSUID 0x2 /* no setuid */ 528 529Both the "statvfs@openssh.com" and "fstatvfs@openssh.com" extensions are 530advertised in the SSH_FXP_VERSION hello with version "2". 531 5324.5. sftp: Extension request "hardlink@openssh.com" 533 534This request is for creating a hard link to a regular file. This 535request is implemented as a SSH_FXP_EXTENDED request with the 536following format: 537 538 uint32 id 539 string "hardlink@openssh.com" 540 string oldpath 541 string newpath 542 543On receiving this request the server will perform the operation 544link(oldpath, newpath) and will respond with a SSH_FXP_STATUS message. 545This extension is advertised in the SSH_FXP_VERSION hello with version 546"1". 547 5484.6. sftp: Extension request "fsync@openssh.com" 549 550This request asks the server to call fsync(2) on an open file handle. 551 552 uint32 id 553 string "fsync@openssh.com" 554 string handle 555 556On receiving this request, a server will call fsync(handle_fd) and will 557respond with a SSH_FXP_STATUS message. 558 559This extension is advertised in the SSH_FXP_VERSION hello with version 560"1". 561 5624.7. sftp: Extension request "lsetstat@openssh.com" 563 564This request is like the "setstat" command, but sets file attributes on 565symlinks. It is implemented as a SSH_FXP_EXTENDED request with the 566following format: 567 568 uint32 id 569 string "lsetstat@openssh.com" 570 string path 571 ATTRS attrs 572 573See the "setstat" command for more details. 574 575This extension is advertised in the SSH_FXP_VERSION hello with version 576"1". 577 5784.8. sftp: Extension request "limits@openssh.com" 579 580This request is used to determine various limits the server might impose. 581Clients should not attempt to exceed these limits as the server might sever 582the connection immediately. 583 584 uint32 id 585 string "limits@openssh.com" 586 587The server will respond with a SSH_FXP_EXTENDED_REPLY reply: 588 589 uint32 id 590 uint64 max-packet-length 591 uint64 max-read-length 592 uint64 max-write-length 593 uint64 max-open-handles 594 595The 'max-packet-length' applies to the total number of bytes in a 596single SFTP packet. Servers SHOULD set this at least to 34000. 597 598The 'max-read-length' is the largest length in a SSH_FXP_READ packet. 599Even if the client requests a larger size, servers will usually respond 600with a shorter SSH_FXP_DATA packet. Servers SHOULD set this at least to 60132768. 602 603The 'max-write-length' is the largest length in a SSH_FXP_WRITE packet 604the server will accept. Servers SHOULD set this at least to 32768. 605 606The 'max-open-handles' is the maximum number of active handles that the 607server allows (e.g. handles created by SSH_FXP_OPEN and SSH_FXP_OPENDIR 608packets). Servers MAY count internal file handles against this limit 609(e.g. system logging or stdout/stderr), so clients SHOULD NOT expect to 610open this many handles in practice. 611 612If the server doesn't enforce a specific limit, then the field may be 613set to 0. This implies the server relies on the OS to enforce limits 614(e.g. available memory or file handles), and such limits might be 615dynamic. The client SHOULD take care to not try to exceed reasonable 616limits. 617 618This extension is advertised in the SSH_FXP_VERSION hello with version 619"1". 620 6214.9. sftp: Extension request "expand-path@openssh.com" 622 623This request supports canonicalisation of relative paths and 624those that need tilde-expansion, i.e. "~", "~/..." and "~user/..." 625These paths are expanded using shell-like rules and the resultant 626path is canonicalised similarly to SSH2_FXP_REALPATH. 627 628It is implemented as a SSH_FXP_EXTENDED request with the following 629format: 630 631 uint32 id 632 string "expand-path@openssh.com" 633 string path 634 635Its reply is the same format as that of SSH2_FXP_REALPATH. 636 637This extension is advertised in the SSH_FXP_VERSION hello with version 638"1". 639 6404.10. sftp: Extension request "copy-data" 641 642This request asks the server to copy data from one open file handle and 643write it to a different open file handle. This avoids needing to transfer 644the data across the network twice (a download followed by an upload). 645 646 byte SSH_FXP_EXTENDED 647 uint32 id 648 string "copy-data" 649 string read-from-handle 650 uint64 read-from-offset 651 uint64 read-data-length 652 string write-to-handle 653 uint64 write-to-offset 654 655The server will copy read-data-length bytes starting from 656read-from-offset from the read-from-handle and write them to 657write-to-handle starting from write-to-offset, and then respond with a 658SSH_FXP_STATUS message. 659 660It's equivalent to issuing a series of SSH_FXP_READ requests on 661read-from-handle and a series of requests of SSH_FXP_WRITE on 662write-to-handle. 663 664If read-from-handle and write-to-handle are the same, the server will 665fail the request and respond with a SSH_FX_INVALID_PARAMETER message. 666 667If read-data-length is 0, then the server will read data from the 668read-from-handle until EOF is reached. 669 670This extension is advertised in the SSH_FXP_VERSION hello with version 671"1". 672 673This request is identical to the "copy-data" request documented in: 674 675https://tools.ietf.org/html/draft-ietf-secsh-filexfer-extensions-00#section-7 676 6774.11. sftp: Extension request "home-directory" 678 679This request asks the server to expand the specified user's home directory. 680An empty username implies the current user. This can be used by the client 681to expand ~/ type paths locally. 682 683 byte SSH_FXP_EXTENDED 684 uint32 id 685 string "home-directory" 686 string username 687 688This extension is advertised in the SSH_FXP_VERSION hello with version 689"1". 690 691This provides similar information as the "expand-path@openssh.com" extension. 692 693This request is identical to the "home-directory" request documented in: 694 695https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-extensions-00#section-5 696 6974.12. sftp: Extension request "users-groups-by-id@openssh.com" 698 699This request asks the server to return user and/or group names that 700correspond to one or more IDs (e.g. as returned from a SSH_FXP_STAT 701request). This may be used by the client to provide usernames in 702directory listings. 703 704 byte SSH_FXP_EXTENDED 705 uint32 id 706 string "users-groups-by-id@openssh.com" 707 string uids 708 string gids 709 710Where "uids" and "gids" consists of one or more integer user or group 711identifiers: 712 713 uint32 id-0 714 ... 715 716The server will reply with a SSH_FXP_EXTENDED_REPLY: 717 718 byte SSH_FXP_EXTENDED_REPLY 719 string usernames 720 string groupnames 721 722Where "username" and "groupnames" consists of names in identical request 723order to "uids" and "gids" respectively: 724 725 string name-0 726 ... 727 728If a name cannot be identified for a given user or group ID, an empty 729string will be returned in its place. 730 731It is acceptable for either "uids" or "gids" to be an empty set, in 732which case the respective "usernames" or "groupnames" list will also 733be empty. 734 735This extension is advertised in the SSH_FXP_VERSION hello with version 736"1". 737 7385. Miscellaneous changes 739 7405.1 Public key format 741 742OpenSSH public keys, as generated by ssh-keygen(1) and appearing in 743authorized_keys files, are formatted as a single line of text consisting 744of the public key algorithm name followed by a base64-encoded key blob. 745The public key blob (before base64 encoding) is the same format used for 746the encoding of public keys sent on the wire: as described in RFC4253 747section 6.6 for RSA and DSA keys, RFC5656 section 3.1 for ECDSA keys 748and the "New public key formats" section of PROTOCOL.certkeys for the 749OpenSSH certificate formats. 750 7515.2 Private key format 752 753OpenSSH private keys, as generated by ssh-keygen(1) use the format 754described in PROTOCOL.key by default. As a legacy option, PEM format 755(RFC7468) private keys are also supported for RSA, DSA and ECDSA keys 756and were the default format before OpenSSH 7.8. 757 7585.3 KRL format 759 760OpenSSH supports a compact format for Key Revocation Lists (KRLs). This 761format is described in the PROTOCOL.krl file. 762 7635.4 Connection multiplexing 764 765OpenSSH's connection multiplexing uses messages as described in 766PROTOCOL.mux over a Unix domain socket for communications between a 767master instance and later clients. 768 7695.5. Agent protocol extensions 770 771OpenSSH extends the usual agent protocol. These changes are documented 772in the PROTOCOL.agent file. 773 774$OpenBSD: PROTOCOL,v 1.50 2023/12/18 14:45:17 djm Exp $ 775