Lines Matching +full:forward +full:- +full:channel
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.
136 than as a named global or channel request to allow pings with very
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
183 The client SHOULD be prepared to update the server-sig-algs that
188 2.1. connection: Channel write close extension "eow@openssh.com"
192 more data over a channel. Unfortunately, there is no symmetric way for
194 while still keeping the channel open for the endpoint to send data to
202 OpenSSH implements a channel extension message to perform this
204 an endpoint when the local output of a session channel is closed or
208 uint32 recipient channel
213 the channel and MAY signal the process from which the channel data
216 As with the symmetric SSH_MSG_CHANNEL_EOF message, the channel does
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
255 2.3. connection: Tunnel forward extension "tun@openssh.com"
258 channel type. This channel type supports forwarding of network packets
265 uint32 sender channel
271 The "tunnel mode" parameter specifies whether the tunnel should forward
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
285 and sending them as channel data. This ensures that packet boundaries
290 uint32 recipient channel
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"
327 uint32 sender channel
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"
340 uint32 sender channel
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 */
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"
419 2.6. connection: SIGINFO support for "signal" channel request
422 signal to a session attached to a channel. OpenSSH supports one
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
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"
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
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