RepoMirrors/openssh
1
0
Fork 0
mirror of git://anongit.mindrot.org/openssh.git synced 2024-12-24 19:02:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

- djm@cvs.openbsd.org 2008/06/12 05:15:41

Browse Source 
[PROTOCOL]
     document tun@openssh.com forwarding method
This commit is contained in:
Darren Tucker 2008-06-13 04:53:27 +10:00
parent d6173c0bd7
commit e5d98290a6
2 changed files with 70 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
ChangeLog
View File

@ -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
View File

@ -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 $