mirror of git://anongit.mindrot.org/openssh.git
- djm@cvs.openbsd.org 2008/06/12 05:15:41
[PROTOCOL]
document tun@openssh.com forwarding method
This commit is contained in:
Darren Tucker
parent
d6173c0bd7
commit
e5d98290a6
|
|
@ -91,6 +91,9 @@
|
|||
- djm@cvs.openbsd.org 2008/06/12 04:24:06
|
||||
[ssh.c]
|
||||
thal shalt not code past the eightieth column
|
||||
- djm@cvs.openbsd.org 2008/06/12 05:15:41
|
||||
[PROTOCOL]
|
||||
document tun@openssh.com forwarding method
|
||||
|
||||
20080611
|
||||
- (djm) [channels.c configure.ac]
|
||||
|
|
@ -4253,4 +4256,4 @@
|
|||
OpenServer 6 and add osr5bigcrypt support so when someone migrates
|
||||
passwords between UnixWare and OpenServer they will still work. OK dtucker@
|
||||
|
||||
$Id: ChangeLog,v 1.4980 2008/06/12 18:52:53 dtucker Exp $
|
||||
$Id: ChangeLog,v 1.4981 2008/06/12 18:53:27 dtucker Exp $
|
||||
|
|
|
|||
72
PROTOCOL
72
PROTOCOL
|
|
@ -84,7 +84,68 @@ connection.
|
|||
Note that this is not a general defence against compromised clients
|
||||
(that is impossible), but it thwarts a simple attack.
|
||||
|
||||
5. sftp: Reversal of arguments to SSH_FXP_SYMLINK
|
||||
5. connection: Tunnel forward extension "tun@openssh.com"
|
||||
|
||||
OpenSSH supports layer 2 and layer 3 tunneling via the "tun@openssh.com"
|
||||
channel type. This channel type supports forwarding of network packets
|
||||
with datagram boundaries entact between endpoints equipped with
|
||||
interfaces like the BSD tun(4) device. Tunnel forwarding channels are
|
||||
requested by the client with the following packet:
|
||||
|
||||
byte SSH_MSG_CHANNEL_OPEN
|
||||
string "tun@openssh.com"
|
||||
uint32 sender channel
|
||||
uint32 initial window size
|
||||
uint32 maximum packet size
|
||||
uint32 tunnel mode
|
||||
uint32 remote unit number
|
||||
|
||||
The "tunnel mode" parameter specifies whether the tunnel should forward
|
||||
layer 2 frames or layer 3 packets. It may take one of the following values:
|
||||
|
||||
SSH_TUNMODE_POINTOPOINT 1 /* layer 3 packets */
|
||||
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.
|
||||
|
||||
Once established the client and server may exchange packet or frames
|
||||
over the tunnel channel by encapsulating them in SSH protocol strings
|
||||
and sending them as channel data. This ensures that packet boundaries
|
||||
are kept intact. Specifically, packets are transmitted using normal
|
||||
SSH_MSG_CHANNEL_DATA packets:
|
||||
|
||||
byte SSH_MSG_CHANNEL_DATA
|
||||
uint32 recipient channel
|
||||
string data
|
||||
|
||||
The contents of the "data" field for layer 3 packets is:
|
||||
|
||||
uint32 packet length
|
||||
uint32 address family
|
||||
byte[packet length - 4] packet data
|
||||
|
||||
The "address family" field identifies the type of packet in the message.
|
||||
It may be one of:
|
||||
|
||||
SSH_TUN_AF_INET 2 /* IPv4 */
|
||||
SSH_TUN_AF_INET6 24 /* IPv6 */
|
||||
|
||||
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:
|
||||
|
||||
uint32 packet length
|
||||
byte[packet length] frame
|
||||
|
||||
The "frame" field contains an IEEE 802.3 ethernet frame, including
|
||||
header.
|
||||
|
||||
6. sftp: Reversal of arguments to SSH_FXP_SYMLINK
|
||||
|
||||
When OpenSSH's sftp-server was implemented, the order of the arguments
|
||||
to the SSH_FXP_SYMLINK method was inadvertendly reversed. Unfortunately,
|
||||
|
|
@ -97,7 +158,7 @@ SSH_FXP_SYMLINK as follows:
|
|||
string targetpath
|
||||
string linkpath
|
||||
|
||||
6. sftp: Server extension announcement in SSH_FXP_VERSION
|
||||
7. sftp: Server extension announcement in SSH_FXP_VERSION
|
||||
|
||||
OpenSSH's sftp-server lists the extensions it supports using the
|
||||
standard 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
|
|||
extension with multiple versions (though this is unlikely). Clients MUST
|
||||
check the version number before attemping to use the extension.
|
||||
|
||||
7. sftp: Extension request "posix-rename@openssh.com"
|
||||
8. sftp: Extension request "posix-rename@openssh.com"
|
||||
|
||||
This operation provides a rename operation with POSIX semantics, which
|
||||
are 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.
|
|||
This extension is advertised in the SSH_FXP_VERSION hello with version
|
||||
"1".
|
||||
|
||||
8. sftp: Extension requests "statvfs@openssh.com" and
|
||||
9. sftp: Extension requests "statvfs@openssh.com" and
|
||||
"fstatvfs@openssh.com"
|
||||
|
||||
These requests correspond to the statvfs and fstatvfs POSIX system
|
||||
|
|
@ -176,5 +237,4 @@ The values of the f_flag bitmask are as follows:
|
|||
This extension is advertised in the SSH_FXP_VERSION hello with version
|
||||
"2".
|
||||
|
||||
$OpenBSD: PROTOCOL,v 1.6 2008/06/10 22:15:23 djm Exp $
|
||||
|
||||
$OpenBSD: PROTOCOL,v 1.7 2008/06/12 05:15:41 djm Exp $
|
||||
|
|
|
|||
Loading…
Reference in New Issue