diff options
Diffstat (limited to 'PROTOCOL')
| -rw-r--r-- | PROTOCOL | 73 |
1 files changed, 58 insertions, 15 deletions
@@ -4,7 +4,7 @@ protocol. Note that OpenSSH's sftp and sftp-server implement revision 3 of the SSH filexfer protocol described in: -http://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt +https://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt Newer versions of the draft will not be supported, though some features are individually implemented as extensions described below. @@ -20,7 +20,7 @@ This is a new transport-layer MAC method using the UMAC algorithm (rfc4418). This method is identical to the "umac-64" method documented in: -http://www.openssh.com/txt/draft-miller-secsh-umac-01.txt +https://www.openssh.com/txt/draft-miller-secsh-umac-01.txt 1.2. transport: Protocol 2 compression algorithm "zlib@openssh.com" @@ -31,10 +31,10 @@ avoids exposing compression code to attacks from unauthenticated users. The method is documented in: -http://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt +https://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt -1.3. transport: New public key algorithms "ssh-rsa-cert-v00@openssh.com", - "ssh-dsa-cert-v00@openssh.com", +1.3. transport: New public key algorithms "ssh-rsa-cert-v01@openssh.com", + "ssh-dsa-cert-v01@openssh.com", "ecdsa-sha2-nistp256-cert-v01@openssh.com", "ecdsa-sha2-nistp384-cert-v01@openssh.com" and "ecdsa-sha2-nistp521-cert-v01@openssh.com" @@ -175,7 +175,7 @@ whitelisted to receive this message upon request. OpenSSH supports layer 2 and layer 3 tunnelling via the "tun@openssh.com" channel type. This channel type supports forwarding of network packets -with datagram boundaries intact between endpoints equipped with +with datagram boundaries intact between endpoints equipped with interfaces like the BSD tun(4) device. Tunnel forwarding channels are requested by the client with the following packet: @@ -194,7 +194,7 @@ layer 2 frames or layer 3 packets. It may take one of the following values: SSH_TUNMODE_ETHERNET 2 /* layer 2 frames */ The "tunnel unit number" specifies the remote interface number, or may -be 0x7fffffff to allow the server to automatically chose an interface. A +be 0x7fffffff to allow the server to automatically choose an interface. A server that is not willing to open a client-specified unit should refuse the request with a SSH_MSG_CHANNEL_OPEN_FAILURE error. On successful open, the server should reply with SSH_MSG_CHANNEL_OPEN_SUCCESS. @@ -247,7 +247,8 @@ to request that the server make a connection to a Unix domain socket. uint32 initial window size uint32 maximum packet size string socket path - string reserved for future use + string reserved + uint32 reserved Similar to forwarded-tcpip, forwarded-streamlocal is sent by the server when the client has previously send the server a streamlocal-forward @@ -294,10 +295,14 @@ has completed. string[] hostkeys Upon receiving this message, a client should check which of the -supplied host keys are present in known_hosts. For keys that are -not present, it should send a "hostkeys-prove@openssh.com" message -to request the server prove ownership of the private half of the -key. +supplied host keys are present in known_hosts. + +Note that the server may send key types that the client does not +support. The client should disregard such keys if they are received. + +If the client identifies any keys that are not present for the host, +it should send a "hostkeys-prove@openssh.com" message to request the +server prove ownership of the private half of the key. byte SSH_MSG_GLOBAL_REQUEST string "hostkeys-prove-00@openssh.com" @@ -329,6 +334,13 @@ a server may offer multiple keys of the same type for a period (to give clients an opportunity to learn them using this extension) before removing the deprecated key from those offered. +2.6. connection: SIGINFO support for "signal" channel request + +The SSH channels protocol (RFC4254 section 6.9) supports sending a +signal to a session attached to a channel. OpenSSH supports one +extension signal "INFO@openssh.com" that allows sending SIGINFO on +BSD-derived systems. + 3. SFTP protocol changes 3.1. sftp: Reversal of arguments to SSH_FXP_SYMLINK @@ -423,7 +435,7 @@ The values of the f_flag bitmask are as follows: Both the "statvfs@openssh.com" and "fstatvfs@openssh.com" extensions are advertised in the SSH_FXP_VERSION hello with version "2". -10. sftp: Extension request "hardlink@openssh.com" +3.5. sftp: Extension request "hardlink@openssh.com" This request is for creating a hard link to a regular file. This request is implemented as a SSH_FXP_EXTENDED request with the @@ -439,7 +451,7 @@ link(oldpath, newpath) and will respond with a SSH_FXP_STATUS message. This extension is advertised in the SSH_FXP_VERSION hello with version "1". -10. sftp: Extension request "fsync@openssh.com" +3.6. sftp: Extension request "fsync@openssh.com" This request asks the server to call fsync(2) on an open file handle. @@ -453,4 +465,35 @@ respond with a SSH_FXP_STATUS message. This extension is advertised in the SSH_FXP_VERSION hello with version "1". -$OpenBSD: PROTOCOL,v 1.27 2015/02/20 22:17:21 djm Exp $ +4. Miscellaneous changes + +4.1 Public key format + +OpenSSH public keys, as generated by ssh-keygen(1) and appearing in +authorized_keys files, are formatted as a single line of text consisting +of the public key algorithm name followed by a base64-encoded key blob. +The public key blob (before base64 encoding) is the same format used for +the encoding of public keys sent on the wire: as described in RFC4253 +section 6.6 for RSA and DSA keys, RFC5656 section 3.1 for ECDSA keys +and the "New public key formats" section of PROTOCOL.certkeys for the +OpenSSH certificate formats. + +4.2 Private key format + +OpenSSH private keys, as generated by ssh-keygen(1) use the format +described in PROTOCOL.key by default. As a legacy option, PEM format +(RFC7468) private keys are also supported for RSA, DSA and ECDSA keys +and were the default format before OpenSSH 7.8. + +4.3 KRL format + +OpenSSH supports a compact format for Key Revocation Lists (KRLs). This +format is described in the PROTOCOL.krl file. + +4.4 Connection multiplexing + +OpenSSH's connection multiplexing uses messages as described in +PROTOCOL.mux over a Unix domain socket for communications between a +master instance and later clients. + +$OpenBSD: PROTOCOL,v 1.37 2020/02/21 00:04:43 dtucker Exp $ |