Lines Matching +full:client +full:- +full:id
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
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.
142 OpenSSH supports a number of transport-layer hardening measures under
144 RFC8308 ext-info feature: by including a additional algorithm in the
145 initial SSH2_MSG_KEXINIT kex_algorithms field. The client may append
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
176 authentication is signalled by the client including a
177 "ext-info-in-auth@openssh.com" key via its initial SSH2_MSG_EXT_INFO
181 SSH2_MSG_EXT_INFO message any time after the client's first
183 The client SHOULD be prepared to update the server-sig-algs that
228 "no-more-sessions@openssh.com"
231 attacker may abuse a running ssh client to surreptitiously open
233 request "no-more-sessions@openssh.com" to mitigate this attack.
235 When an OpenSSH client expects that it will never open another session
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
261 requested by the client with the following packet:
279 server that is not willing to open a client-specified unit should refuse
283 Once established the client and server may exchange packet or frames
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
360 by the client cancel the forwarding of a Unix domain socket.
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 */
379 Upon receiving this message, a client should check which of the
382 Note that the server may send key types that the client does not
383 support. The client should disregard such keys if they are received.
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
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
469 uint32 id
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
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.
619 Even if the client requests a larger size, servers will usually respond
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
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
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"
700 An empty username implies the current user. This can be used by the client
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"
721 request). This may be used by the client to provide usernames in
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.
774 OpenSSH private keys, as generated by ssh-keygen(1) use the format