summaryrefslogtreecommitdiff
path: root/PROTOCOL
diff options
context:
space:
mode:
authorDarren Tucker <dtucker@zip.com.au>2008-06-13 04:53:27 +1000
committerDarren Tucker <dtucker@zip.com.au>2008-06-13 04:53:27 +1000
commite5d98290a6bff2352c47bb54b769a605f0794d5d (patch)
treeffb3e5f7c023dfb31f7006b4d64968cadfc7ec51 /PROTOCOL
parentd6173c0bd7acf5880640bb3a89cf19cb5d4e092d (diff)
- djm@cvs.openbsd.org 2008/06/12 05:15:41
[PROTOCOL] document tun@openssh.com forwarding method
Diffstat (limited to 'PROTOCOL')
-rw-r--r--PROTOCOL72
1 files changed, 66 insertions, 6 deletions
diff --git a/PROTOCOL b/PROTOCOL
index 76e6adb4b..08b16dc16 100644
--- a/PROTOCOL
+++ b/PROTOCOL
@@ -84,7 +84,68 @@ connection.
84Note that this is not a general defence against compromised clients 84Note that this is not a general defence against compromised clients
85(that is impossible), but it thwarts a simple attack. 85(that is impossible), but it thwarts a simple attack.
86 86
875. sftp: Reversal of arguments to SSH_FXP_SYMLINK 875. connection: Tunnel forward extension "tun@openssh.com"
88
89OpenSSH supports layer 2 and layer 3 tunneling via the "tun@openssh.com"
90channel type. This channel type supports forwarding of network packets
91with datagram boundaries entact between endpoints equipped with
92interfaces like the BSD tun(4) device. Tunnel forwarding channels are
93requested by the client with the following packet:
94
95 byte SSH_MSG_CHANNEL_OPEN
96 string "tun@openssh.com"
97 uint32 sender channel
98 uint32 initial window size
99 uint32 maximum packet size
100 uint32 tunnel mode
101 uint32 remote unit number
102
103The "tunnel mode" parameter specifies whether the tunnel should forward
104layer 2 frames or layer 3 packets. It may take one of the following values:
105
106 SSH_TUNMODE_POINTOPOINT 1 /* layer 3 packets */
107 SSH_TUNMODE_ETHERNET 2 /* layer 2 frames */
108
109The "tunnel unit number" specifies the remote interface number, or may
110be zero to allow the server to automatically chose an interface. A server
111that is not willing to open a client-specified unit should refuse the
112request with a SSH_MSG_CHANNEL_OPEN_FAILURE error. On successful open,
113the server should reply with SSH_MSG_CHANNEL_OPEN_SUCCESS.
114
115Once established the client and server may exchange packet or frames
116over the tunnel channel by encapsulating them in SSH protocol strings
117and sending them as channel data. This ensures that packet boundaries
118are kept intact. Specifically, packets are transmitted using normal
119SSH_MSG_CHANNEL_DATA packets:
120
121 byte SSH_MSG_CHANNEL_DATA
122 uint32 recipient channel
123 string data
124
125The contents of the "data" field for layer 3 packets is:
126
127 uint32 packet length
128 uint32 address family
129 byte[packet length - 4] packet data
130
131The "address family" field identifies the type of packet in the message.
132It may be one of:
133
134 SSH_TUN_AF_INET 2 /* IPv4 */
135 SSH_TUN_AF_INET6 24 /* IPv6 */
136
137The "packet data" field consists of the IPv4/IPv6 datagram itself
138without any link layer header.
139
140The contents of the "data" field for layer 3 packets is:
141
142 uint32 packet length
143 byte[packet length] frame
144
145The "frame" field contains an IEEE 802.3 ethernet frame, including
146header.
147
1486. sftp: Reversal of arguments to SSH_FXP_SYMLINK
88 149
89When OpenSSH's sftp-server was implemented, the order of the arguments 150When OpenSSH's sftp-server was implemented, the order of the arguments
90to the SSH_FXP_SYMLINK method was inadvertendly reversed. Unfortunately, 151to the SSH_FXP_SYMLINK method was inadvertendly reversed. Unfortunately,
@@ -97,7 +158,7 @@ SSH_FXP_SYMLINK as follows:
97 string targetpath 158 string targetpath
98 string linkpath 159 string linkpath
99 160
1006. sftp: Server extension announcement in SSH_FXP_VERSION 1617. sftp: Server extension announcement in SSH_FXP_VERSION
101 162
102OpenSSH's sftp-server lists the extensions it supports using the 163OpenSSH's sftp-server lists the extensions it supports using the
103standard extension announcement mechanism in the SSH_FXP_VERSION server 164standard extension announcement mechanism in the SSH_FXP_VERSION server
@@ -118,7 +179,7 @@ ever changed in an incompatible way. The server MAY advertise the same
118extension with multiple versions (though this is unlikely). Clients MUST 179extension with multiple versions (though this is unlikely). Clients MUST
119check the version number before attemping to use the extension. 180check the version number before attemping to use the extension.
120 181
1217. sftp: Extension request "posix-rename@openssh.com" 1828. sftp: Extension request "posix-rename@openssh.com"
122 183
123This operation provides a rename operation with POSIX semantics, which 184This operation provides a rename operation with POSIX semantics, which
124are different to those provided by the standard SSH_FXP_RENAME in 185are different to those provided by the standard SSH_FXP_RENAME in
@@ -135,7 +196,7 @@ rename(oldpath, newpath) and will respond with a SSH_FXP_STATUS message.
135This extension is advertised in the SSH_FXP_VERSION hello with version 196This extension is advertised in the SSH_FXP_VERSION hello with version
136"1". 197"1".
137 198
1388. sftp: Extension requests "statvfs@openssh.com" and 1999. sftp: Extension requests "statvfs@openssh.com" and
139 "fstatvfs@openssh.com" 200 "fstatvfs@openssh.com"
140 201
141These requests correspond to the statvfs and fstatvfs POSIX system 202These requests correspond to the statvfs and fstatvfs POSIX system
@@ -176,5 +237,4 @@ The values of the f_flag bitmask are as follows:
176This extension is advertised in the SSH_FXP_VERSION hello with version 237This extension is advertised in the SSH_FXP_VERSION hello with version
177"2". 238"2".
178 239
179$OpenBSD: PROTOCOL,v 1.6 2008/06/10 22:15:23 djm Exp $ 240$OpenBSD: PROTOCOL,v 1.7 2008/06/12 05:15:41 djm Exp $
180