Lines Matching +full:protocol +full:- +full:id
2 protocol.
4 Note that OpenSSH's sftp and sftp-server implement revision 3 of the SSH
5 filexfer protocol described in:
7 https://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt
12 The protocol used by OpenSSH's ssh-agent is described in the file
13 PROTOCOL.agent
15 1. Transport protocol changes
17 1.1. transport: Protocol 2 MAC algorithm "umac-64@openssh.com"
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
23 https://www.openssh.com/txt/draft-miller-secsh-umac-01.txt
25 1.2. transport: Protocol 2 compression algorithm "zlib@openssh.com"
27 This transport-layer compression method uses the zlib compression
34 https://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt
36 1.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"
44 in the file PROTOCOL.certkeys
49 specified in RFC5656. Only the ecdsa-sha2-nistp256, ecdsa-sha2-nistp384
50 and ecdsa-sha2-nistp521 curves over GF(p) are supported. Elliptic
54 1.5 transport: Protocol 2 Encrypt-then-MAC MAC algorithms
56 OpenSSH supports MAC algorithms, whose names contain "-etm", that
58 4253. These variants use the so-called "encrypt then MAC" ordering,
61 protocol, where decryption of unauthenticated ciphertext provided a
65 Specifically, the "-etm" MAC algorithms modify the transport protocol
79 byte[n1] payload; n1 = packet_length - padding_length - 1
82 1.6 transport: AES-GCM
84 OpenSSH supports the AES-GCM algorithm as specified in RFC 5647.
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
94 1.7 transport: chacha20-poly1305@openssh.com authenticated encryption
97 as described in PROTOCOL.chacha20poly1305.
99 1.8 transport: curve25519-sha256@libssh.org key exchange algorithm
103 http://git.libssh.org/users/aris/libssh.git/plain/doc/curve25519-sha256@libssh.org.txt?h=curve25519
105 This is identical to curve25519-sha256 as later published in RFC8731.
142 OpenSSH supports a number of transport-layer hardening measures under
144 RFC8308 ext-info feature: by including a additional algorithm in the
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
153 the protocol:
155 a) During initial KEX, terminate the connection if out-of-sequence
169 This protocol extension allows the SSH2_MSG_EXT_INFO to be sent
172 of user authentication and this is too late to signal per-user
177 "ext-info-in-auth@openssh.com" key via its initial SSH2_MSG_EXT_INFO
183 The client SHOULD be prepared to update the server-sig-algs that
186 2. Connection protocol changes
190 The SSH connection protocol (rfc4254) provides the SSH_MSG_CHANNEL_EOF
228 "no-more-sessions@openssh.com"
233 request "no-more-sessions@openssh.com" to mitigate this attack.
240 string "no-more-sessions@openssh.com"
241 char want-reply
251 of this message, the no-more-sessions request is only sent to OpenSSH
279 server that is not willing to open a client-specified unit should refuse
284 over the tunnel channel by encapsulating them in SSH protocol strings
297 byte[packet length - 4] packet data
322 Similar to direct-tcpip, direct-streamlocal is sent by the client
326 string "direct-streamlocal@openssh.com"
334 Similar to forwarded-tcpip, forwarded-streamlocal is sent by the
335 server when the client has previously send the server a streamlocal-forward
339 string "forwarded-streamlocal@openssh.com"
351 Similar to tcpip-forward, streamlocal-forward is sent by the client
355 string "streamlocal-forward@openssh.com"
359 Similar to cancel-tcpip-forward, cancel-streamlocal-forward is sent
363 string "cancel-streamlocal-forward@openssh.com"
367 2.5. connection: hostkey update and rotation "hostkeys-00@openssh.com"
368 and "hostkeys-prove-00@openssh.com"
370 OpenSSH supports a protocol extension allowing a server to inform
371 a client of all its protocol v.2 host keys after user-authentication
375 string "hostkeys-00@openssh.com"
376 char 0 /* want-reply */
386 it should send a "hostkeys-prove@openssh.com" message to request the
390 string "hostkeys-prove-00@openssh.com"
391 char 1 /* want-reply */
397 string "hostkeys-prove-00@openssh.com"
421 The SSH channels protocol (RFC4254 section 6.9) supports sending a
424 BSD-derived systems.
426 3. Authentication protocol changes
428 3.1. Host-bound public key authentication
436 string "ssh-connection"
437 string "publickey-hostbound-v00@openssh.com"
446 signer. OpenSSH uses this binding via signed data to implement per-key
447 restrictions in ssh-agent.
452 string "publickey-hostbound@openssh.com"
455 Clients should prefer host-bound authentication when advertised by
458 4. SFTP protocol changes
462 When OpenSSH's sftp-server was implemented, the order of the arguments
469 uint32 id
475 OpenSSH's sftp-server lists the extensions it supports using the
479 uint32 3 /* protocol version */
480 string ext1-name
481 string ext1-version
482 string ext2-name
483 string ext2-version
485 string extN-name
486 string extN-version
494 4.3. sftp: Extension request "posix-rename@openssh.com"
498 draft-ietf-secsh-filexfer-02.txt. This request is implemented as a
501 uint32 id
502 string "posix-rename@openssh.com"
518 uint32 id
524 uint32 id
531 uint32 id
536 uint64 f_bavail /* free blocks for non-root */
539 uint64 f_favail /* free file inodes for to non-root */
540 uint64 f_fsid /* file system id */
546 #define SSH_FXE_STATVFS_ST_RDONLY 0x1 /* read-only */
558 uint32 id
572 uint32 id
588 uint32 id
604 uint32 id
609 uint32 id
610 uint64 max-packet-length
611 uint64 max-read-length
612 uint64 max-write-length
613 uint64 max-open-handles
615 The 'max-packet-length' applies to the total number of bytes in a
618 The 'max-read-length' is the largest length in a SSH_FXP_READ packet.
623 The 'max-write-length' is the largest length in a SSH_FXP_WRITE packet
626 The 'max-open-handles' is the maximum number of active handles that the
641 4.9. sftp: Extension request "expand-path@openssh.com"
644 those that need tilde-expansion, i.e. "~", "~/..." and "~user/..."
645 These paths are expanded using shell-like rules and the resultant
651 uint32 id
652 string "expand-path@openssh.com"
660 4.10. sftp: Extension request "copy-data"
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
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
681 read-from-handle and a series of requests of SSH_FXP_WRITE on
682 write-to-handle.
684 If read-from-handle and write-to-handle are the same, the server will
687 If read-data-length is 0, then the server will read data from the
688 read-from-handle until EOF is reached.
693 This request is identical to the "copy-data" request documented in:
695 https://tools.ietf.org/html/draft-ietf-secsh-filexfer-extensions-00#section-7
697 4.11. sftp: Extension request "home-directory"
704 uint32 id
705 string "home-directory"
711 This provides similar information as the "expand-path@openssh.com" extension.
713 This request is identical to the "home-directory" request documented in:
715 https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-extensions-00#section-5
717 4.12. sftp: Extension request "users-groups-by-id@openssh.com"
725 uint32 id
726 string "users-groups-by-id@openssh.com"
733 uint32 id-0
739 uint32 id
746 string name-0
749 If a name cannot be identified for a given user or group ID, an empty
763 OpenSSH public keys, as generated by ssh-keygen(1) and appearing in
765 of the public key algorithm name followed by a base64-encoded key blob.
769 and the "New public key formats" section of PROTOCOL.certkeys for the
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
782 format is described in the PROTOCOL.krl file.
787 PROTOCOL.mux over a Unix domain socket for communications between a
790 5.5. Agent protocol extensions
792 OpenSSH extends the usual agent protocol. These changes are documented
793 in the PROTOCOL.agent file.
795 $OpenBSD: PROTOCOL,v 1.55 2024/01/08 05:05:15 djm Exp $