Lines Matching +full:send +full:- +full:not +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
9 Newer versions of the draft will not be supported, though some features
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
51 curve points encoded using point compression are NOT accepted or
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
137 short packet lengths, which would not be possible with other
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
156 packet or any message that is not strictly required by KEX is
158 packet received is not SSH2_MSG_KEXINIT. Unexpected packets for
164 duration of the connection (i.e. not just the first
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
218 still be sent in the other direction. This message does not consume
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
247 Note that this is not a general defence against compromised clients
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"
346 The reserved field is not currently defined and is ignored on the
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
385 If the client identifies any keys that are not present for the host,
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"
407 When the client receives this reply (and not a failure), it should
409 that it has not seen before and deleting keys for the server host that
412 These extensions let a client learn key types that it had not previously
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
464 the reversal was not noticed until the server was widely deployed. Since
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 */
601 Clients should not attempt to exceed these limits as the server might sever
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
629 (e.g. system logging or stdout/stderr), so clients SHOULD NOT expect to
635 dynamic. The client SHOULD take care to not try to exceed reasonable
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