http://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt
-Features from newer versions of the draft are not supported, unless
-explicitly implemented as extensions described below.
+Newer versions of the draft will not be supported, though some features
+are individually implemented as extensions described below.
The protocol used by OpenSSH's ssh-agent is described in the file
PROTOCOL.agent
descriptor.
OpenSSH implements a channel extension message to perform this
-signalling: "eow@openssh.com" (End Of Write). This message is sent by an
-endpoint when the local output of a channel is closed or experiences a
-write error. The message is formatted as follows:
+signalling: "eow@openssh.com" (End Of Write). This message is sent by
+an endpoint when the local output of a session channel is closed or
+experiences a write error. The message is formatted as follows:
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
still be sent in the other direction. This message does not consume
window space and may be sent even if no window space is available.
+NB. due to certain broken SSH implementations aborting upon receipt
+of this message (in contravention of RFC4254 section 5.4), this
+message is only sent to OpenSSH peers (identified by banner).
+Other SSH implementations may be whitelisted to receive this message
+upon request.
+
4. connection: disallow additional sessions extension
"no-more-sessions@openssh.com"
Note that this is not a general defence against compromised clients
(that is impossible), but it thwarts a simple attack.
+NB. due to certain broken SSH implementations aborting upon receipt
+of this message, the no-more-sessions request is only sent to OpenSSH
+servers (identified by banner). Other SSH implementations may be
+whitelisted to receive this message upon request.
+
5. connection: Tunnel forward extension "tun@openssh.com"
OpenSSH supports layer 2 and layer 3 tunnelling via the "tun@openssh.com"
SSH_TUNMODE_ETHERNET 2 /* layer 2 frames */
The "tunnel unit number" specifies the remote interface number, or may
-be zero to allow the server to automatically chose 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.
+be 0x7fffffff to allow the server to automatically chose 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.
Once established the client and server may exchange packet or frames
over the tunnel channel by encapsulating them in SSH protocol strings
The "packet data" field consists of the IPv4/IPv6 datagram itself
without any link layer header.
-The contents of the "data" field for layer 3 packets is:
+The contents of the "data" field for layer 2 packets is:
uint32 packet length
byte[packet length] frame
#define SSH_FXE_STATVFS_ST_RDONLY 0x1 /* read-only */
#define SSH_FXE_STATVFS_ST_NOSUID 0x2 /* no setuid */
-This extension is advertised in the SSH_FXP_VERSION hello with version
-"2".
+Both the "statvfs@openssh.com" and "fstatvfs@openssh.com" extensions are
+advertised in the SSH_FXP_VERSION hello with version "2".
-$OpenBSD: PROTOCOL,v 1.9 2008/06/28 14:08:30 djm Exp $
+$OpenBSD: PROTOCOL,v 1.14 2010/01/09 00:57:10 djm Exp $