Lines Matching +full:send +full:- +full:empty
4 Note that OpenSSH's sftp and sftp-server implement revision 3 of the SSH
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
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
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"
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,
65 Specifically, the "-etm" MAC algorithms modify the transport protocol
66 to calculate the MAC over the packet ciphertext and to send the packet
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
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.
120 The reply copies the data (which may be the empty string) from the
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
155 a) During initial KEX, terminate the connection if out-of-sequence
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
180 A server that supports this extension MAY send a second
183 The client SHOULD be prepared to update the server-sig-algs that
191 message to allow an endpoint to signal its peer that it will send no
194 while still keeping the channel open for the endpoint to send data to
228 "no-more-sessions@openssh.com"
233 request "no-more-sessions@openssh.com" to mitigate this attack.
237 will send the following global request:
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
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"
349 The client currently sends the empty string for this field.
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"
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 */
382 Note that the server may send key types that the client does not
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"
424 BSD-derived systems.
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
462 When OpenSSH's sftp-server was implemented, the order of the arguments
466 current order was retained. For correct operation, clients should send
475 OpenSSH's sftp-server lists the extensions it supports using the
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
502 string "posix-rename@openssh.com"
536 uint64 f_bavail /* free blocks for non-root */
539 uint64 f_favail /* free file inodes for to non-root */
546 #define SSH_FXE_STATVFS_ST_RDONLY 0x1 /* read-only */
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
652 string "expand-path@openssh.com"
660 4.10. sftp: Extension request "copy-data"
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"
700 An empty username implies the current user. This can be used by the client
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"
726 string "users-groups-by-id@openssh.com"
733 uint32 id-0
746 string name-0
749 If a name cannot be identified for a given user or group ID, an empty
752 It is acceptable for either "uids" or "gids" to be an empty set, in
754 be 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.
774 OpenSSH private keys, as generated by ssh-keygen(1) use the format