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