Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
ZEBEDEE(1)			    Zebedee			    ZEBEDEE(1)

NAME
       Zebedee --- a simple, free, secure TCP and UDP tunnel program

SYNOPSIS
       Server:
	   zebedee -s [common-options] [-c host] [-C num] [-r ports] [target
	   ...]

       Client:
	   zebedee [-m]	[-e command]
	    [server] [tunnel-spec ...]

       Common Options:
	   zebedee [-dDLtuU] [-b address] [-F char] [-f	file] [-K
	   checksumlevel] [-k keybits] [-n name] [-o log] [-T port] [-v	level]
	   [-x config] [-z level] ...

       Key generation:
	   zebedee -p [-f file]

	   zebedee -P [-p] [-f file]

       Hash generation:
	   zebedee -h [file ...]

	   zebedee -H string ...

       Windows Service:
	   zebedee [-n name] -S	[install[=file]	| remove | run]

       UNIX-like only
	   zebedee [-N userid] ...

DESCRIPTION
       Zebedee is a simple program to establish	an encrypted, compressed
       "tunnel"	for TCP/IP or UDP traffic between two systems. This allows
       data from, for example, telnet, ftp and X sessions to be	protected from
       snooping.  You can also use compression,	either with or without data
       encryption, to gain performance over low-bandwidth networks.

       This document describes the features of Zebedee as at release 2.5.3.
       For details of the new features in this release see CHANGES.

       The main	goals for Zebedee are to:

       o   Provide client and server functionality under both UNIX/Linux and
	   Windows.

       o   Be easy to install, use and maintain	with little or no
	   configuration required.

       o   Have	a small	footprint, low wire protocol overhead and give
	   significant traffic reduction by the	use of compression.

       o   Use only algorithms that are	either unpatented or for which the
	   patent has expired.

       o   Be entirely free for	commercial or non-commercial use and
	   distributed under the term of the GNU General Public	Licence	(see
	   "CREDITS AND	LEGALITIES").

       Of course, Zebedee is by	no means the first, or only secure tunnel
       program available. It does not pretend to compete with the likes	of ssh
       or SSL in terms of breadth of function but if you want something	quick,
       simple and completely free then it may be the tool for you.

   What's in a name?
       In case you were	wondering, or even if you weren't, Zebedee is named
       after its three main components:

       o   Zlib	compression

       o   Blowfish encryption and

       o   Diffie-Hellman key agreement.

       So now you know!

   Basic Usage
       To set up a secure connection between your local	machine	and a remote
       host you	need first to run Zebedee in server mode on the	remote system.
       The easiest way to do this is to	run Zebedee with the -s	option (but
       please read the notes on	security issues	later):

	zebedee	-s

       If all goes well	(and it	should!) Zebedee will detach from the terminal
       (or console window under	Windows) and run in the	background. It will
       then be listening for incoming requests from clients.

       On your local machine you then run Zebedee in client mode. You need to
       specify the name	of the remote machine and the name of the service or
       number of the port to which the tunnel should be	established ---	we
       will call this the "target" port. If the	remote machine is called
       "remhost" and you want to set up	a secure telnet	session	then you would
       run:

	zebedee	remhost:telnet

       In fact,	if you don't specify a service or port the default is telnet
       so

	zebedee	remhost

       would do	just as	well in	this instance. When you	run this command it
       will print out a	message	telling	you the	port number which is the local
       end of the tunnel. Zebedee will then detach from	the terminal and run
       in the background waiting for you to connect to the local port. If, for
       example,	the port number	it printed out was 1234	then to	connect	to
       "remhost" using the secure tunnel you would run:

	telnet localhost 1234

       By default, Zebedee will	continue to listen for connections and tunnel
       them, handling multiple simultaneous connections	if necessary, until
       you terminate the process.

       Sometimes you will want to start	Zebedee	and then run a command that
       connects	to the port straight away. You can do this in a	single
       invocation of Zebedee as	follows:

	zebedee	-e "telnet localhost %d" remhost

       The "%d"	in the string is automatically replaced	with the local port
       number so there is no need for Zebedee to print it out. If you specify
       a command like this then	the local Zebedee client will exit once	the
       command closes its connection.

       You may want or need to control the local port number that the client
       uses.  This is necessary	if the command whose connection	you are	trying
       to protect expects to connect only to a specific	port. In this case you
       can also	specify	the local port number by invoking Zebedee as follows:

	zebedee	clientport:hostname:targetport

       So, for example,	the command:

	zebedee	8000:webhost:80

       will allow you to secure	all HTTP connections to	webhost	if accessed
       via port	8000 on	the client system. See EXAMPLES	for more details.

       You can also use	a single Zebedee client	to handle multiple
       simultaneous tunnels to different target	ports on the same remote host.
       In this case the	client and target port specifications are lists	of
       ports. For example:

	zebedee	9001,9002,9003:somehost:daytime,telnet,ftp

       This will tunnel	traffic	on the clientport 9001 to the daytime port on
       the remote target system, traffic on 9002 to the	telnet port and
       traffic on 9003 to the ftp port.

       This combination	of client listening ports, target host and destination
       ports is	called a "tunnel specification". See the tunnel	keyword	for
       more details.

   UDP Tunnelling
       Originally Zebedee was designed only to be able to handle TCP/IP
       traffic.	 It can	now also handle	connectionless UDP data. To enable
       this start Zebedee with the -U option (or use the ipmode	keyword). For
       example:

	zebedee	-s -U

       on the server host and

	zebedee	-U 10000:somehost:echo

       on the client. When run in this way Zebedee will	handle both TCP	and
       UDP traffic.

       The tunnel between Zebedee clients and servers still uses a TCP/IP
       connection even in UDP-mode. This connection is timed out after a
       certain period of inactivity.  It must be re-established	if more	data
       arrives.	For this reason	the performance	in UDP mode may	appear poor,
       depending on the	nature of the application using	it. You	should note
       that there is also a limit on the size of UDP datagrams that can	be
       handled.

       For further details see the maxbufsize, ipmode, udptimeout and
       tcptimeout keywords.

   Some	Terminology
       Usually there will only be two systems involved when you	set up a
       tunnel using Zebedee. You will run a client on one and communicate with
       it via connections to local ports. On the other you will	run a server
       which will speak	to services local to that machine.  However, there can
       be up to	four different systems involved, as shown below:

	[source] <===> [client]	<=====>	[server] <===> [target]
		   |		   |		   |
		   +- insecure	   |		   + insecure
		      connection   |		     connection
				   +- secure tunnel

       The Zebedee client runs on the "client" system and the server runs on
       the "server" host. The inital connection	that causes a tunnel to	be
       established between client and server originates	from the "source"
       machine.	This could be a	different system than where the	Zebedee	client
       is running, although it is usually the same. The	server will ultimately
       communicate with	the "target" system. Again, this is usually the	local
       machine but does	not have to be.

       Most of the time	you will not have to be	concerned with the distinction
       between source and client and server and	target.	The terminology	is,
       however,	reflected in a number of the keywords described	in the
       following section so you	should bear it in mind when reading their
       descriptions.

       In addition to the different systems involved in	Zebedee	tunnel there
       are also	several	different types	of keys	used to	secure connection. The
       client and server generate or are provided with private key values.
       These are used to calculate public values which are exchanged and used
       to derive a shared secret key using the Diffie-Hellman key agreement
       mechanism.  From	this shared key	a unique session key is	derived	to
       secure an individual connections	between	client and server.

   Multiple Destinations
       A single	Zebedee	client/server pair can handle tunnels for multiple
       targets,	not just the system on which the Zebedee server	is running.

       When a server is	started	it can be given	a list of valid	targets	either
       on the command-line or by using the target keyword.  Each target	is a
       host name optionally followed by	a list of ports	to which connections
       may be made. Consider the following command run on a machine called
       serverhost:

	zebedee	-s target1:daytime,telnet target2:telnet target3

       the server will allow connections to the	daytime	and telnet ports on
       target1,	the telnet port	on target2 and any port	on target3.

       Given this server invocation, a client may be started as	follows:

	zebedee	serverhost 10000:target1:telnet	20000:target3:telnet

       This will connect to the	Zebedee	server on serverhost and use it	to
       establish tunnels to the	telnet port on target1 via the client port
       10000 and tunnels to the	telnet port on target3 via 20000.  Note	that
       the name	of the host on which the server	is running is given as the
       first parameter.	If the server name is omitted it is determined from
       the first tunnel	specification. So if the server	had been running on
       target3 then the	above command could have been given as:

	zebedee	20000:target3:telnet 10000:target1:telnet

       In fact,	a server also maintains	a notion of a default target. This is
       the host	name of	the last target	specified. In the example server
       invocation above	the default target becomes target3. This is the	target
       used when the server and	target names specified by the client are the
       same. Be	careful	of this	because	you may	get results that you do	not
       expect. For example, if the server was started on "target3" as:

	zebedee	-s target2:telnet target3 target1:daytime,telnet

       then the	following client invocation:

	zebedee	20000:target3:telnet

       would result in connections to port 20000 being tunnelled to target1
       and not target3.	This is	because	when the server	and target specified
       by the client are the same then the traffic goes	to the server's
       default target. To avoid	confusion, if you want to include the server
       host in a list of multiple destinations then always name	it last. Note
       that as well as a default target	host it	is also	possible to specify a
       list of default allowed target ports where none are otherwise given.
       See the redirect	keyword	for more details.

       As with the target keyword for the server, the equivalent of the
       command-line parameter for the client is	the tunnel keyword (and
       serverhost in order to specify the server host explictly).

   Server-Initiated Connections
       In normal use a Zebedee client inititates connections to	the server
       when a connection has been made to it from a source system. Sometimes,
       for example when	using Zebedee through a	restrictive firewall, it may
       be necessary for	the server to initiate the connection back to the
       client --- to operate in	"reverse." For details on how to do this see
       the clienthost and listenmode keywords.

   Configuration File
       The behaviour of	Zebedee	is probably best controlled through the	use of
       a configuration file. A configuration file can be specified using the
       -f command-line option. The file	is read	at the point at	which the
       option is encountered so	later command-line options may override	the
       contents	of the file.

       Lines are of the	form:

	keyword	value #	optional comment

       The keyword is a	single,	case-insensitive word. The value is either a
       single word or a	string.	Strings	are enclosed either in double quotes
       ("like this") or	single quotes ('like this'). Double quotes may appear
       in single quoted	strings	and vice versa ("here's	an example"). Case is
       preserved in the	values where appropriate.

       Blank lines and lines beginning with a ""#"" (after any leading
       whitespace) are ignored.	Long strings may be continued onto the next
       line by ending the line with a ""\"" character. This character is
       eliminated and the next line is joined on to the	end. Note that there
       is a limit of a total of	1024 characters	on any line and	its
       continuations. Line continuation	happens	before anything	else,
       including comment recognition so	the lines:

	server false
	# This comment continues on the	next line \
	server true

       will leave the value of server as false.

       The keywords and	their meanings are as described	below. There is	a
       brief description of all	the keywords in	the "Quick-Reference Summary"
       section.	Some, but not all, keywords have equivalent command-line
       options.	These are shown	where available.  There	are also a few
       command-line options that have no equivalent in the configuration file.
       These are described at the end of this section.

       If a keyword is described as being a boolean then its value must	be one
       of the words true or false.

       Several keywords	require	a list of ports	to be specfied.	Where this the
       case the	value is string	that consists of a comma or white-space
       delimited list of port names, numbers or	numeric	ranges.	For example
       ""telnet, ftp 5900-5903"".  This	is equivalent to the list
       ""23,21,5900,5901,5902,5903"". You can also specify that	a particular
       port or range should only be used for TCP or UDP	traffic	by suffixing
       it with ""/tcp""	or ""/udp"". If	this suffix is omitted it can be used
       for either type.	So, the	list ""telnet/tcp,daytime/udp,echo"" specifies
       TCP-only	traffic	to the "telnet"	port, UDP-only traffic to the
       "daytime" port and either to the	"echo" port.

       A number	of the keywords	are either only	applicable to clients or only
       applicable to servers. The same Zebedee program runs as either client
       or server and will silently ignore inappropriate	options	for the
       current type of usage. The choice of client or server behaviour is
       controlled by the server	keyword:

       server (command-line -s)
	   This	is a boolean indicating	whether	the program should run as a
	   client or a server. The default is to run as	a client if this
	   keyword is not specified. The command-line -s option	is equivalent
	   to setting this keyword to true.

       targetconnecttimeout
	   This	specifies the about of time, in	seconds, that a	server should
	   block trying	to connect to a	target host. The default is 300
	   seconds.

   Client-Only Keywords
       The following keywords apply only to Zebedee clients:

       command (command-line -e)
	   When	running	as a client, this is a command that will be spawned to
	   run connected to the	tunnel.	If the value contains the character
	   sequence "%d" this will be replaced at run-time with	the local port
	   number (see the tunnel keyword). As this is done using sprintf the
	   conventions of that routine apply with regards to escaping ""%""
	   characters (i.e. use	""%%"" to generate a single ""%""). In
	   addition, specifying	more that one "%d" or other format sequence
	   will	very likely crash the program.

	   Once	the command closes its connection Zebedee will exit. Using
	   this	keyword	or option implicitly turns off multi-use mode (see
	   multiuse). You can not use automatic	command	spawning when a	single
	   Zebedee client is handling multiple connections in multiuse mode or
	   when	a list of ports	has been specified with	the tunnel keyword or
	   on the command-line.

       listenmode (command-line	-l)
	   In normal use a Zebedee client inititates connections to the	server
	   when	a connection has been made to it from a	source system.
	   Sometimes, for example when using Zebedee through a restrictive
	   firewall, it	may be necessary for the server	to initiate the
	   connection with a client ---	to operate in "reverse."

	   The listenmode keyword, if true, causes a Zebedee client to listen
	   for connections initiated by	the server rather than to connect
	   directly. The client	will listen for	connections at the network
	   level but the connection from the server will not be	fully accepted
	   and activated until a matching connection from the source system
	   has been received. Equally, a client	will accept connections	from
	   source clients but no data will be read from	or sent	to these
	   connections until a connection has been made	with a server.

	   Normally a client makes a connection	to a specific server address.
	   Server-initiated connections	could, however,	originate from
	   arbitrary addresses,	thus giving the	client no control over the
	   destination of the tunnel. To avoid this the	client will validate
	   that	the address of the server's connection matches that specified,
	   whether on the command-line,	via the	serverhost keyword or as part
	   of the first	tunnel specification. (The client can also use the
	   checkaddress	keyword	to perform such	checking).

	   When	using listenmode the server address can	also contain a network
	   mask.  So the following client invocation:

	    zebedee -l 10000:10.10.10.0/24:telnet

	   will	accept connections from	any address on the 10.10.10.0 class C
	   subnet.  As a special case, if the server name is ""*"" then
	   connections will be accepted	from any server	address. Use of	the
	   identity checking features is also recommended to ensure that the
	   correct server connects.

	   If a	connection from	a server is not	received within	a certain
	   period then the connection back to the source system	will be	closed
	   and the process abandoned.  This timeout is controlled by the
	   acceptconnecttimeout	keyword. The default is	300 seconds.

	   See the clienthost keyword for the description of the server	side
	   of this process.

       localsource
	   If this value is true then the client will only accept connections
	   originating from the	local machine. In other	words the "source"
	   system must be the same as the "client" system.

	   The default is for this value to be false and for connections to be
	   allowed from	any arbitrary source machine.

	   This	has been superseded by the more	generic	listenip keyword. So
	   ""localsource true""	is equivalent to ""listenip 127.0.0.1"".

       multiuse	(command-line -m)
	   If this value is true, which	is the default,	then the Zebedee
	   client will handle multiple (potentially simultaneous) connection
	   requests and	will establish a new tunnel to the server for each
	   one.	If it is false,	the client runs	in "single-use"	mode and exits
	   after the first connection to the server has	been closed.

	   The command-line -m option is equivalent to setting this to true.
	   This	is the default behaviour in the	current	version	of Zebedee and
	   the option is retained only for backwards-compatibility reasons.

	   Any client listening	on multiple ports will automatically run in
	   "multi-use" mode, even if this is set false (see clientport).

       serverhost
	   This	is the name of the host	on which a Zebedee server is running
	   and to which	a tunnel is to be connected.  There is no default and
	   a host name must be specified either	in a configuration file	or on
	   the command line.

	   See the listenmode keyword for the treatment	of this	value when
	   using server-initiated connections.

	   Prior to version 2.0.0 this was known as the	remotehost keyword.
	   This	is still recognised for	backwards compatibility.

       tunnel
	   This	is a string that consists of three parts separated by colons,
	   for example:

	    10000-10002:targethost:echo,telnet,daytime

	   The first part is the list of ports on which	the Zebedee client
	   will	listen for connections.	 The second part is the	name of	the
	   target host to which	the tunnelled data should be directed. The
	   final part is the list of target ports that correspond to the ports
	   on which the	client is listening. The numbers of entries in the
	   client and target port lists	must match.

	   As a	special	case, if only a	single tunnel specification is given
	   with	only a single target port then the client port list (and
	   separating colon) may be omitted. The client	port will be assigned
	   automatically (and a	message	will be	printed	to the terminal	giving
	   the port number). This is to	allow for backwards compatibility and
	   for use with	the command keyword. If	the target port	is also
	   omitted then	it will	default	to telnet (port	23).

	   As described	in the section "Multiple Destinations" if the Zebedee
	   server host is not explicitly specified, either as the first
	   argument on the command-line	or via the serverhost keyword, then it
	   will	be taken from the first	tunnel specification found.

	   There is also one final variant of the tunnel specification.	In
	   this	case the targethost is replaced	by a ""*"". This wild-card
	   form	is used	either with the	client running in "listen-mode"	(see
	   listenmode for further details) or when you want to specify
	   tunnelling to the server's default target, whatever it may be. This
	   latter form is useful in a configuration file when you want the
	   file	to be generically applicable to	any server. For	example, a
	   file	like this:

	    server false
	    tunnel 10000:*:daytime
	    tunnel 20000:*:echo
	    tunnel 30000:*:telnet

	   can be used to set up tunnels on ports 10000, 20000 and 30000 to
	   whatever host may be	specified on the command-line like this:

	    zebedee -f configfile serverhost

   Server-Only Keywords
       The following keywords apply only when running as a server:

       clienthost (command-line	-c)
	   If a	clienthost value is specified then the server will immediately
	   attempt to connect to the specified host (on	the port given by
	   serverport).	Once a connection to the client	has been established
	   the protocol	exchanges proceed as normal. Each time a connection
	   has been accepted by	the client the server tentatively opens	up
	   another one so that the client could	establish further tunnels if
	   necessary.

	   Three other keywords	affect this behaviour. The
	   serverconnecttimeout	keyword	determines how long the	server will
	   spend trying	to make	a connection. If it cannot immediately connect
	   to the client it will wait this many	seconds	before trying again.
	   Once	a connection has been established the server will wait up to
	   acceptconnecttimeout	seconds	for the	client to accept the
	   connection and start	the protocol exchange. Finally,	this whole
	   process will	be repeated up to connectattempts times. If a
	   connection is not opened and	accepted within	this number of
	   attempts the	server will exit once all currently active tunnels
	   have	been closed.

	   Note	that Zebedee does not itself provide a mechanism for co-
	   ordinating the starting of client and server	to set up a "reverse"
	   tunnel. That	must be	handled	by some	"out-of-band" mechanism.

       connectattempts (command-line -C)
	   This	specifies the number of	attempts the server makes to connect
	   back	to a client when a clienthost is given.	The default is 1.

       dropunknownprotocol
	   This	is a boolean indicating	whether	a Zebedee server should
	   attempt to continue negotiating a connection	with a client that
	   requests a version of the Zebedee protocol that the server can not
	   support. By default this is false, meaning that the server will
	   reply with the highest protocol version it supports,	allowing the
	   client to decide if it can continue.	If set to true,	the server
	   will	immediately terminate the connection.

	   See also lockprotocol.

       redirect	(command-line -r)
	   This	is the default list of the ports on the	target system to which
	   the server will accept requests to redirect data, when the target
	   specification does not otherwise specify a port range. An example
	   port	list might be ""telnet,	ftp, 5900-5910"".

	   If no redirect keyword is specified then requests to	redirect
	   traffic to any port will be accepted. While this is convenient for
	   testing it may pose a security risk so you should specify an
	   explict list	of allowed ports if at all possible. As	a special
	   case, if the	port range is given as ""none""	then any current
	   default redirection list will be cleared and	no target ports	will
	   be accepted by default.

	   The keyword (or -r option) may be specified multiple	times in which
	   case	redirection will be allowed to any of the ports	specified.

	   It is generally better to use the target keyword instead of
	   redirect, where possible. The main reason to	prefer redirect	is
	   when	you want to specify a common range of ports for	a number of
	   targets, for	example:

	    # Set up common target redirections
	    redirect telnet,ftp,daytime
	    target hosta
	    target hostb
	    target hostc
	    # Set up additional	host-specific redirections
	    target hostb:http

       target
	   This	specifies a target host	and, optionally, list of ports to
	   which a server will accept requests to redirect data. It is a
	   string consisting of	the target host	name followed by a colon and
	   then	a list of ports. For example

	    target www.winton.org.uk:http,ftp

	   If the port list (and colon)	are omitted then requests for
	   redirection will be controlled by the ports given by	the redirect
	   statements, if any.

	   The target hostname may also	be specified as	a CIDR network
	   address, that is an address with the	number of bits to be used for
	   the network mask, for example:

	    target 10.10.10.0/24:http

	   This	means that HTTP	connections to any host	address	in the
	   255-host class C subnet will	be accepted.

	   This	keyword	is equivalent to the comnmand-line arguments of	the
	   same	form (see "Multiple Destinations"). It may be repeated
	   multiple times. The final target host specified, either using the
	   this	keyword	or on the command line,	becomes	the default
	   destination for tunnels when	a client specifies the server's	host-
	   name	as the destination.

	   Be careful when using CIDR addresses	as targets that	the last
	   target specified will be valid default address. If the default
	   target has an address mask then Zebedee will	flag this as an	error
	   and exit.

	   It is also possible to apply	identity checking and source IP
	   address validation, like that provided by checkidfile and
	   checkaddress, to individual targets.	If the target is suffixed with
	   a ""?"" followed by a file name, such as this:

	    target 10.10.10.0/24:http?httpusers.ids

	   then	the file ("httpusers.ids" in this example) must	be a file in
	   the same format as that described in	the identity checking section.
	   The effect of this target specification is to allow connections to
	   be created to the HTTP port of any machine in the 10.10.10.0/24
	   sub-net, but	only by	clients	whose identities are found in
	   "httpusers.ids".

	   Similarly, the target can be	suffixed with ""@"" followed by	an
	   address specification in the	same form as that used by
	   checkaddress. For example:

	    target 10.10.10.0/24:http@10.20.30.0/24

	   In this case	only clients in	the 10.20.30.0/24 sub-net will be
	   permitted to	create tunnels to this target.

	   You can't combine both the ""?"" and	""@"" forms. But you really
	   wouldn't want to do that anyway, would you?

       targetconnecttimeout
	   This	sets maximum timeout for server	attempting to make a
	   connection to a target endpoint. Normally a connection attempt will
	   fail	immediately if there is	no target server running. However,
	   with	certain	kinds on network or system failures connection
	   attempts can	block almost indefinitely. This	timeout	prevents these
	   hangs. The default is 300 seconds.

       transparent
	   This	is a boolean value, which is false by default. If set true it
	   causes the Zebedee server to	attempt	to propagate the client's IP
	   address to the target server	--- for	the existence of the server to
	   become "transparent".

	   This	functionality will not work on all platforms and Zebedee will
	   have	to be run as a privileged user (e.g. "root" on UNIX-like
	   systems) in order for it to work at all. Full transparency support
	   for TCP and UDP traffic is currently	only expected work on Linux
	   and then only on systems with kernel	versions 2.0 and 2.2. It will
	   not work on Linux 2.4, although there is some hope that it may work
	   in future versions.

	   Support for a limited form of transparency for UDP traffic is
	   available for a wider range of UNIX-like platforms, although	this
	   must	have been enabled at compile time (it is not enabled by
	   default in the "standard" builds). If it has	been enabled then
	   unidirectional UDP traffic from client to server will preserve the
	   Zebedee client's IP address on datagrams sent to the	target server.
	   This	will be	sufficient for applications such as "syslog" where
	   there is no requirement that	the target server should reply to such
	   traffic.  Applications that attempt to reply	to the address in
	   these datagrams will	not send replies via the Zebedee tunnel	and,
	   in fact, are	likely to send their data to non-existent or invalid
	   endpoints.

   Compression,	Encryption and Checksum	Keywords
       The following keywords control the compression, encryption and
       checksumming of data passing through the	tunnel.	They apply to both
       clients and servers:

       checksumlevel (command-line -K)
	   Zebedee will, by default, calculate a checksum for every message
	   sent	over the tunnel. This checksum is appended to the message and
	   verified by the recipient. If the checksum calculated by the
	   recipient does not match that in the	message	the tunnel connection
	   will	be terminated. You should note that for	the checksum to	be
	   effective as	a means	of assuring that data has not been maliciously
	   modified, you should	ensure that the	data is	also encrypted.

	   The checksumlevel is	an integer between 0 and 3 that	determines the
	   checksumming	algorithm used to check	the integrity of data
	   transferred by Zebedee. The default is 2. This provides a
	   reasonable level of assurance, at the price of a 4-byte overhead on
	   each	message	and some extra computation.  Setting this to 0 turns
	   off checksumming (which was the behaviour prior to Zebedee version
	   2.5).

	   The checksum	level used will	be the minimum of the client's and
	   server's values (subject to any setting of minchecksumlevel).

	   The algorithms used and the overhead	they imply are as follows:

	   Level 0
	       No checksum, no additional overhead.

	   Level 1
	       This uses the "ADLER32" algorithm from zlib. It requires	a
	       4-byte overhead per message. The	algorithm is fast but gives
	       the lowest degree of assurance that the message has not been
	       modified	or corrupted in	transit.

	   Level 2
	       This uses the "CRC32" algorithm from zlib. It requires a	4-byte
	       overhead	per message. This is a little slower than "ADLER32"
	       but provides a better level of assurance	of the data integrity.

	   Level 3
	       This uses the "SHA" algorithm. It requires a 20-byte overhead
	       per message.  This is the most CPU-intensive operation but
	       provides	a very high degree of assurance	that the contents of
	       the message have	not been altered in transit.

       compression (command-line -z)
	   Zebedee can support both zlib and, if enabled when it is built,
	   bzip2 compression. This keyword specifies the type and level	of
	   compression to be used. The value is	of the form type:level where
	   type	is either ""zlib"" or ""bzip2""	and level is an	integer	from 0
	   to 9. As a special case an integer without any prefix implicitly
	   selects a zlib compression level.

	   The level specifies the maximum compression level to	used (9	is the
	   maximum and 0 is no compression). The actual	compression level used
	   will	be the minimum of the client's and server's values. For	these
	   purposes all	bzip2 levels (except 0)	are considered to be greater
	   than	all zlib levels	so if either client or server does not support
	   bzip2 the protocol degrades gracefully to using zlib. The default
	   compression value is	""zlib:6"".

	   Note	that, because of the way that bzip2 compression	works and the
	   buffer sizes	that Zebedee uses, bzip	will probably only be useful
	   if continuous streams of data are flowing. On smaller transfers,
	   such	as those in a normal telnet session, zlib will usually win.
	   You will have to experiment to see what works best for you. In
	   addition, because the buffer	size is	small there is no gain from
	   using bzip2 levels above 1 and Zebedee will round any higher	values
	   down	to this	level.

	   You can see exactly how much	compression is gaining you at
	   verbosity levels 2 and above	when basic statistics are printed out
	   on connection termination. For example:

	    zebedee(232/210):	read 166 bytes (265 expanded) in 3 messages
	    zebedee(232/210):	wrote 20969 bytes (30499 expanded) in 247 messages

       generator
	   This	is the "generator" for the Diffie-Hellman key exchange and is
	   a hexadecimal string. The default value is "2". I recommend that
	   you don't mess with this unless you know what you are doing.

       keygencommand
	   If this keyword is specified	its value is a command string that
	   will	be executed in order to	generate a private key (see
	   privatekey. The command should write	a single line of hexadecimal
	   digits to stdout. This line must be a string	of at least 10
	   hexadecimal digits. A simple	Tcl (see <http://tcl.activestate.com>)
	   script ("passphrase.tcl") that prompts a user for a pass-phrase and
	   then	uses this to generate an appropriate key is included in	the
	   standard Zebedee distribution. If might be used as follows ("wish"
	   is the Tcl script interpreter):

	    keygencommand "/usr/bin/wish -f passphrase.tcl"

	   If a	privatekey value is specified it takes precedence over any
	   keygencommand.

	   If the command string ends with a ""+"" character then the command
	   will	be run with three extra	command	line arguments.	The first is
	   IP address of the system to which the tunnel	is connected (the
	   server address for a	client,	and client for a server). This is in
	   numeric form, not the DNS name. The next argument is	the IP address
	   of the target for the tunnel	(note that if this is the default
	   target it will be given as 0.0.0.0).	The final argument is the
	   target port number. So, for a Zebedee client	run like this:

	    zebedee -x "keygencommand 'newkey -x +'" 1000:192.168.100.100:23

	   the key generation command run would	be as follows:

	    newkey -x 192.168.100.100 0.0.0.0 23

       keygenlevel
	   This	is an integer between 0	and 2 inclusive	that determines	how
	   strong the private key generation in	Zebedee	should be. The default
	   is 2	(the strongest)	and you	should generally not change this
	   unless connection set-up performance	becomes	unacceptable.

	   Briefly, on UNIX-like systems the level-2 key generation mechanism
	   uses	"/dev/urandom" or "/dev/random", if either of these devices is
	   available, to obtain	good pseudo-random data	based on the state of
	   the running kernel. If no random-data device	is available or	the
	   level is set	to 1 then data from the	current	contents of the
	   "/proc" file-system,	if there is one, will be used otherwise	at
	   level 0 only	data from the current process will be used.

	   On Windows systems there is currently no distinction	between
	   different key generation strength levels and	this keyword is
	   effectively ignored.

       keylength (command-line -k)
	   This	is an integer specifying the maximum key length	(in bits) for
	   the Blowfish	encryption. It should be a multiple of 4 between 4 and
	   576.	 The key length	used will be the minimum of the	client's and
	   server's values (subject to any setting of minkeylength).

	   The default value is	128. As	a special case setting this value to 0
	   will	turn off key negotiation and encryption.

       keylifetime
	   If the value	of this	parameter is non-zero it causes	the client to
	   request the re-use of a previously established shared secret	key
	   for deriving	session	keys for subsequent connections. This means
	   that	on the first connection	between	a Zebedee client and server
	   the full key	exchange dialogue will take place to establish a
	   shared secret key. On subsequent connections, until the key
	   expires, the	same secret key	will be	reused to generate a new
	   session key.	 Once the key expires a	new key	exchange will
	   automatically be performed when necessary.

	   This	keyword	specifies how long a shared secret key is valid	before
	   it must be renegotiated. This does not affect connections that have
	   already been	established, only new connections.

	   The value is	in seconds and must be less than or equal to 65535,
	   which is a little over 18 hours. By default it is set to 3600
	   seconds (one	hour). Setting this value to zero effectively disables
	   the use of reusable keys and	a full negotiation of a	shared key
	   will	be performed for each connection --- assuming that both	client
	   and server also generate a new private key each time. This will
	   impact performance and is recommended only if you have a very high
	   paranoia level!

       minchecksumlevel
	   If supplied,	this specifies the minimum acceptable checksum level
	   (see	checksumlevel) to be used by the client	or server. If a	client
	   requests a lower level of a server the server will reply with this
	   minimum. If a server	replies	with a lower level to a	client then
	   the client will terminate the connection.

	   The default value is	zero.

       minkeylength
	   If supplied,	this specifies the minimum acceptable key length (see
	   keylength) to be used by client or server. If a client requests a
	   lower level of a server the server will reply with this minimum. If
	   a server replies with a lower level to a client then	the client
	   will	terminate the connection.

	   The default value is	zero.

       modulus
	   The value of	this key is a hexadecimal string specifying the
	   modulus value for the Diffie-Hellman	key exchange. Don't alter this
	   unless you are both paranoid	and know what you are doing.

	   The default modulus is the 1024-bit prime:

	    f488fd584e49dbcd 20b49de49107366b 336c380d451d0f7c 88b31c7c5b2d8ef6
	    f3c923c043f0a55b 188d8ebb558cb85d 38d334fd7c175743 a31d186cde33212c
	    b52aff3ce1b12940 18118d7c84a70a72 d686c40319c80729 7aca950cd9969fab
	    d00a509b0246d308 3d66a45d419f9c7c bd894b221926baab a25ec355e92f78c7

	   This	was taken from the file	testdh.h in Peter Gutman's CryptLib.
	   The comment in this code says that the value	was among those
	   "generated by Colin Plumb for SKIP".	It further says	that "these
	   values were chosen as representative	well-known public values to
	   allay fears of possible trapdoors in	self-generated values.	The
	   generation method and actual	values can be checked against the SKIP
	   standards document."

       privatekey
	   By default Zebedee will generate a new private key (the "exponent"
	   value in the	Diffie-Hellman key exchange calculation) each time one
	   is required.	If, however, you wish to use a fixed key then it can
	   be specified	as a string of hexadecimal digits.  You	will
	   definitely need to do this if you wish to use the identity checking
	   feature. Note that the key must be at least 10 digits long.

       sharedkey
	   By default Zebedee uses the Diffie-Hellman key exchange protocol to
	   establish an	anonymous, shared secret key between client an server.
	   This	means that neither party has to	store any permanent secret
	   key.	However, under some circumstances you may wish to use a	pre-
	   established shared secret key, communicated by other	means. The
	   sharedkey keyword allows you	to do this.  Its value is a string of
	   hexadecimal digits. This value is the unencrypted shared key	and it
	   must	contain	at least as many bits (there are 4 bits	per digit) as
	   will	be used	to encrypt the traffic through the tunnel. Note	that
	   the shared key is not, however, used	to encrypt the data directly.
	   A unique session key	is still established for each tunnel.

	   All clients and servers that	wish to	communicate must use the same
	   shared secret key value. Connections	between	clients	and servers
	   that	do not share the same secret will be terminated	before a
	   tunnel is established. It is	your responsibility to distribute and
	   protect this	secret from disclosure.

       sharedkeygencommand
	   This	is the equivalent to the keygencommand but in this case
	   generates a sharedkey value.	Any sharedkey value overrides this, if
	   present.

   Miscellaneous Keywords
       The following keywords apply equally to clients and servers:

       checkaddress
	   This	keyword, which may be repeated multiple	times, specifies an IP
	   address and,	optionally, range of ports in the same form as that
	   used	by the target keyword. The IP address can be in	the form of a
	   CIDR	address.

	   When	a connection is	established between a client and a server the
	   IP address and, optionally, source port of the system at the	other
	   end of the connection is checked against the	set of specified
	   addresses and ports.	If it does not match any of the	entries	the
	   connection will be closed. So, for example, the entry:

	    checkaddress 192.168.1.0/24
	    checkaddress 192.168.2.0/24

	   in a	server's configuration file would only permit connections from
	   systems on the two subnets named. This checking is done before any
	   further validation of identity (see identity	checking).

	   Please note that source IP addresses	can easily be "spoofed"	and
	   you should not place	great reliance on this for validating the
	   identity of a client	or server. It is, however, a useful basic
	   protection mechanism.

       checkidfile
	   This	names a	file that contains a set of identities that will be
	   checked before allowing a connection	to be completed. This is
	   described further in	the description	of identity checking. You may
	   specify only	one identity file. If this keyword appears multiple
	   times only the last value will be used.

	   If a	keylength of zero has been agreed then no identity checking
	   will	be performed.

       acceptconnecttimeout
	   When	Zebedee	is used	in "reverse-mode" (see listenmode and
	   clienthost) the timeout on waiting for connections to be accepted
	   is controlled by this keyword. Its value is in seconds and may be
	   no greater than 65535.  The default is 300 seconds.

       debug (command-line -D)
	   This	is a boolean indicating	that Zebedee should run	in "debug"
	   mode. In this case a	server (or client running in multiuse mode)
	   only	accepts	and handles a single connection	at a time and does so
	   "inline" without creating another process or	thread.	This is	useful
	   when	running	the program under the control of a debugger. It	is
	   false by default. The command-line option -D	is equivalent to
	   setting this	to true.

	   Note	that this setting will not work	correctly in UDP mode, so
	   don't bother	trying it!

       detached	(command-line -d)
	   This	is a boolean indicating	whether	the process should detach
	   itself from the controlling terminal	and run	in the background (in
	   UNIX	terms, to run as a "daemon").  This is valid for both client
	   and server and is true by default.  The command-line	option -d is
	   equivalent to setting this to false.

	   Note	that this does not always seem to work from an interactive
	   command prompt under	Windows	systems. The symptom is	that output to
	   the console window will stop	and interrupt signals will be ignored
	   but the console prompt will not be issued until Zebedee terminates.
	   In order to work around this	you can	use the	"start"	command	as in
	   the following example:

	    DOS> start zebedee -f server.zbd

	   This	will start Zebedee in a	new console session from which it will
	   then	detach.	You may	see a console window appear briefly before it
	   detaches but	Zebedee	should be running in the background when it
	   disappears.

       dumpdata
	   This	is a boolean value indicating whether logging output should
	   include details of the data sent to and received from local
	   sockets. Because this data is potentially sensitive --- one of the
	   reasons for using Zebedee in	the first place	--- the	default	is for
	   such	data not to be included	(dumpdata is false). If	it is set to
	   true	then, when the verbosity level is 5 or greater,	the logging
	   output will include lines such as the following:

	    read 39 bytes from local socket 324
	    < 0000 00 00 00 #  ff S  M	B  a2 4	 00 00 c0 98 07	c8
	    < 0010 00 00 00 00 00 00 00	00 00 00 00 00 01 08 d0	03
	    < 0020 01 08 p  00 00 00 00

	   Lines beginning with	""<"" or "">"" show the	data that is being is
	   read	from or	written	to the local socket. Each line shows up	to
	   sixteen bytes of data and is	prefixed by the	offset,	in
	   hexadecimal,	from the beginning of the data stream. Printable ASCII
	   characters are shown	verbatim, such as the three characters ""SMB""
	   above, while	other bytes are	shown as a hexadecimal value.

       httpproxy
	   Zebedee now has support for making the client-server	TCP connection
	   via an HTTP proxy. If specified this	should give the	address	and
	   port	of the proxy server, for example:

	    httpproxy webproxy.example.com:8080

	   There is no default port, you must always specify one explicitly.
	   The proxy can be used for either client or server-initiated
	   connections (see listenmode). Source	or target connections are
	   unaffected, the proxy only applies to connections between a Zebedee
	   client and server.

	   Please note that using an HTTP proxy	server to tunnel arbitrary
	   connections is very likely to violate the security policy of	the
	   organisation	running	the server. If you intend to use Zebedee in
	   this	way (or, for that matter, to establish any other kind of
	   "backdoor" tunnel) I	strongly advise	you to seek permission from
	   the appropriate network administrators.

	   In order to give administrators some	chance to maintain proper
	   control over	the use	of their proxy servers Zebedee does identify
	   itself with a user-agent string of "Zebedee"	when it	connects to
	   the proxy server. Well, it does in the "official" version anyway.

       httpproxyauth
	   If tunnelling via an	HTTP proxy, using httpproxy, some proxy
	   servers require authentication information to be supplied in	order
	   to permit the connection to be made.	Zebedee	supports the "basic"
	   authentication type.	The username and password required for this
	   can be specified using the httpproxyauth keyword. The username and
	   password are	given in plain text, separated by a colon, as follows:

	    httpproxyauth "username:password"

       idletimeout
	   This	sets both the tcptimeout and udptimeout	to the same value,
	   causing idle	connections to be closed. Please see those keywords
	   for further details.

       include (command-line -f)
	   This	specifies the name of another configuration file to read and
	   parse at this point before continuing with the remainder of the
	   file. It might be used, for example,	where a	private	key is stored
	   in a	separate, more tightly protected file. There is	a limit	of 5
	   levels deep of include processing (counting the initial
	   configuration file as level 1). This	avoids unintentional
	   recursion.

       ipmode (command-line -U for "both" mode)
	   As of version 2.4, a	Zebedee	client or server can handle both TCP
	   and UDP traffic simultaneously. This	is controlled by the ipmode
	   keyword. It can have	a value	of tcp,	udp or both.

	   The default value is	tcp and	Zebedee	will only handle TCP traffic
	   in this case. The value udp is equivalent to	setting	udpmode	to be
	   true. In this case only UDP traffic will be handled and the Zebedee
	   server will,	by default use a different port	(11230). If it is set
	   to both then	a client will listen for both TCP and UDP traffic and
	   a server will handle	requests to tunnel both	TCP and	UDP traffic.
	   In this case	the server uses	only one port, by default the normal
	   TCP-mode port of 11965. The command-line option -U is equivalent to
	   ""ipmode both"".

	   Please be aware that	a client or server running purely in UDP mode
	   will	expect to use port 11230 by default. If	the corresponding
	   Zebedee server or client is running in "mixed" mode you may have to
	   specify the port explictly. For example, if the server is running
	   in mixed mode:

	    zebedee -s -U

	   then	a client running in UDP-only mode will need to specify the
	   server port:

	    zebedee -u -T 11965	10000:serverhost:echo

       listenip	(command-line -b)
	   Specifies the local IP address used to listen for connections. This
	   can be useful on a system with multiple network interfaces, but
	   where Zebedee should	only use one of	them. If listenip is not
	   specified the default is to listen on all of	the system's
	   interfaces.

	   The address can be given as a "dotted quad" or by name but in the
	   case	where the name can resolve to multiple IP addresses the
	   results may be unpredictable. The address must, obviously, also
	   correspond to one of	those belonging	to the system.

	   Note	that listenip is a more	general	form of	localsource and
	   setting localsource will override listenip and vice versa.

       lockprotocol (command-line -L)
	   In normal usage, different versions of Zebedee will try to
	   negotiate a compatible version of the Zebedee protocol between
	   themselves. Provided	that no	incompatible features are used,	all
	   versions of Zebedee from 2.0	onwards	can interwork with eachother.

	   The lockprotocol keyword is a boolean value that, if	set true,
	   causes a client or server to	reject requests	for protocol versions
	   that	do not match the default version being used by the program.
	   The default protocol	version	is always the highest that the program
	   supports so this has	the effect of stopping the protocol being
	   "downgraded"	to a previous version.

	   The main reason for using this is to	ensure that features only
	   available in	later versions of the protocol,	such as	checksumming
	   of data introduced in Zebedee version 2.5, can not be silently
	   dropped.

	   The default value is	false.

       maxbufsize
	   This	specifies the size, in bytes, of the buffer Zebedee will use
	   to read data	from applications. The actual size of buffer used will
	   be the minimum of the client's and server's values.

	   By default Zebedee attempts to read data from the client or server
	   programs at each end	of the tunnel in chunks	of 8192	bytes. There
	   may be occasions when you want to decrease this if, for example,
	   you have a highly interactive application and the response seems
	   sluggish because you	end up waiting for large data transfers.  You
	   can reduce the buffer size to one byte, but unless you are trying
	   to debug misbehaviour or have time to waste I don't recommend it!
	   Conversely, you may increase	the buffer size	up to a	maximum	of
	   16383 bytes to attempt to gain the most from	data compression where
	   large blocks	of data	are being transferred. Note that the
	   maxbufsize value does not affect how	much memory is allocated by
	   Zebedee, only the size of data chunks read.

	   When	running	in UDP mode this buffer	size will also affect the
	   maximum size	of any datagram	that can be handled. Datagrams larger
	   than	the current buffer size	will be	fragmented, which will likely
	   cause whatever application is consuming them	to fail. Datagrams
	   larger than 16383 bytes can not be handled at all.

       maxconnections
	   This	specifies that maximum number of concurrent connections
	   (tunnels) that the Zebedee instance will handle.

	   The default value is	zero, which means that no limit	is applied.
	   =item message

	   The specifies a string that will be logged at verbosity level 1
	   when	it is encountered in the configuration file.

       name (command-line -n)
	   This	is the name of the program that	is to be used in messages
	   rather than the executable file name. Under Windows it is also the
	   name	of any service to be installed or removed.

       logfile (command-line -o)
	   This	is the name of the file	to which messages will be written. If
	   it is not specified then messages are written to stderr.

	   Two special "file names" are	also recognised	as valid values. If
	   the name is NULL the	all messages will be turned off. If the	name
	   is SYSLOG then messages will	be written to the host system log. On
	   Windows systems this	is the system application event	log. Elsewhere
	   messages are	written	to the syslog service.

       readtimeout
	   The readtimeout keyword is primarily	intended to help provide a
	   Zebedee server with some additional defence against "denial of
	   service" attacks where a malicious user might make connections to a
	   server but not send any data	to them. Each connection consumes
	   resources and it might be possible for an attacker to crash the
	   server by exceeding its resource capacity.

	   This	value represents a time	limit in seconds within	which reads
	   from	a Zebedee tunnel must be complete. If the value	is zero	then
	   no timeout is applied. This is the default behaviour	because
	   applying a timeout will have	some impact on performance and an
	   unnecessarily small timeout may cause valid connections to fail.

	   The timeout primarily affects the initial Zebedee protocol
	   exchanges. If you wish to cause valid but apparently	idle
	   connections to be timed out you should use tcptimeout or
	   udptimeout.

	   This	value may also be useful when a	client is running in
	   listenmode.	While Zebedee tries to determine whether a connection
	   from	a server will be usable, and if	it has already been closed,
	   this	is not always possible.	In this	case setting this to a non-
	   zero	value will stop	the client hanging if it accepts such a	"dead"
	   connection.

       runasuser (command-line -N)
	   This	keyword	and option apply to UNIX/Linux systems only.

	   It may sometimes be necessary to run	Zebedee	as "root" (UID 0), for
	   example so that a server can	listen on a so-called "privileged"
	   port	below port 1024, or to access configuration or log files that
	   should not be readable by other users. However, having a program,
	   and particularly a network server, run as "root" for	longer than
	   necessary is	a potential security risk. If Zebedee is run as
	   "rootL" then	this keyword can be used to specify a user identity to
	   which Zebedee should	switch after it	has opened all files and set
	   up listening	sockets.

	   The user identity specified as an argument should be	the name of a
	   valid account on the	host machine. For example:

	    runasuser "nobody"

	   Zebedee will	switch to the user-ID and primary group-ID associated
	   with	that account. Note that	it is considered a fatal error if the
	   account does	not exist. This	protects you against Zebedee failing
	   to switch away from "root" if you were expecting it do so. If
	   Zebedee is not running as "root" a warning will be issued and the
	   keyword ignored, but	it will	not cause a fatal error.

	   WARNING: Please note	that it	is not safe to make Zebedee a setuid
	   "root" program, even	if this	keyword	is used. This keyword is only
	   intended for	use where Zebedee is run by "root". Making Zebedee a
	   setuid "root" program will open a gaping security hole in your
	   system!

       serverport (command-line	-T)
	   This	is the port on which the Zebedee server	will listen for	tunnel
	   connections.	The default is 11965 (0x2EBD) when running in TCP mode
	   or mixed TCP	and UDP	mode. It is 11230 (0x2BDE) in UDP-only mode.
	   The keyword causes a	server to listen on this port and a client to
	   attempt to connect to this port on the server system.

	   If using server-initiated connections (see listenmode and
	   clienthost) then this is also the port on which the client listens
	   for the server's incoming connections.

       serverconnecttimeout
	   This	sets maximum timeout for a client attempting to	make a
	   connection to a server or (if running in "reverse" mode) for	a
	   server to connect back to a client. Normally	a connection attempt
	   will	fail immediately if there is no	remote Zebedee process
	   running. However, with certain kinds	on network or system failures
	   connection attempts can block almost	indefinitely. This timeout
	   prevents these hangs. The default is	300 seconds.

       tcptimeout
	   By default, TCP-mode	tunnels	will stay open until either the
	   connection is closed	by either source or target. This keyword
	   allows them to be closed after a certain period of inactivity. The
	   value is in seconds and must	be no greater than 65535. Setting it
	   to zero results in an indefinite timeout.

	   See also idletimeout	and udptimeout.

       threadstacksize
	   This	specifies the size of the stack	allocated to each thread in
	   Zebedee, in units of	1 kilobyte. By default it is set to 64,	and
	   Zebedee creates threads with	a 64k stack. This should be more than
	   sufficient for its needs, and that of the C run time	library. If
	   you suffer from inexplicable	crashes	you may	wish to	try raising
	   this. Conversely, on	some platforms you may be able to lower	it
	   without causing problems. Previous versions of Zebedee have run
	   successfully	with a value of	32k. Under no circumstances can	it be
	   lowered below 16 (kilobytes).

       timestamplog (command-line -t)
	   This	is a boolean value indicating whether log messages should
	   contain a time-stamp. The default is	not to do so. The command-line
	   option -t is	equivalent to setting this to true.

       udpmode (command-line -u)
	   By default Zebedee handles connection-oriented TCP/IP traffic. If
	   this	keyword	is set true Zebedee handles UDP/IP connectionless
	   traffic instead.

	   The tunnel between Zebedee clients and servers still	uses a TCP/IP
	   connection. A separate connection is	established for	each different
	   originating UDP network endpoint. Because UDP is connectionless
	   there is no easy way	to tell	when the data traffic has been
	   completed. For this reason the Zebedee connection must be timed out
	   after a period of inactivity. This period is	controlled by the
	   udptimeout value.

	   If more data	subsequently arrives from a source the tunnel for
	   which has been timed	out, the connection must be re-established.
	   For this reason the performance in UDP mode may appear poor,
	   depending on	the nature of the application using it.	Altering the
	   keylifetime value may improve this by minimizing connection setup
	   times and changing the udptimeout value may also help.

	   The command-line -u option is equivalent to setting this to true.
	   It is also equivalent to setting ipmode to udp.

       udptimeout
	   By default, UDP-mode	tunnels	will shut down after 300 seconds of
	   inactivty.  They are	recreated automatically	if any further traffic
	   arrives. The	timeout	value can be changed by	using this keyword to
	   specify the timeout in seconds.  It must be no greater than 65535.
	   Setting it to zero results in an indefinite timeout.	This is
	   probably not	a good idea for	UDP traffic as it means	that there is
	   no way ever to indicate that	those connections should be closed.

	   See also idletimeout	and tcptimeout.

       verbosity (command-line -v)
	   This	is an integer specifying the level of message logging with 0
	   being just error messages and 5 giving excruciating detail of the
	   message traffic. The	default	(and generally most useful level) is
	   1.

	   Messages are	written	to stderr (unless redirected using the -o
	   command-line	option or logfile keyword). The	general	form of
	   messages is something like:

	    zebedee(54/119):  Listening	on local port 1172

	   The numbers in brackets represent the process and thread
	   identifiers of the code logging the message.	All error messages are
	   logged at level 0 and are preceded by the word "ERROR", as follows:

	    zebedee(54/119): ERROR: failed to connect to localhost:11965

	   Messages are	indented according to the level	at which they are
	   logged.

   Obsolete Keywords
       As Zebedee has evolved over time	some of	the keywords have been changed
       to reflect this.	In a few cases keywords	have been superseded and made
       obsolete.  These	obsolete keywords are still recognised in order	to
       retain backwards	compatibility with old configuration files but they
       should not be used in new ones.

       clientport
	   This	keyword	has been superseded by the more	general	tunnel
	   keyword.

	   This	is the port or list of ports on	which the Zebedee client will
	   listen for connections. It is equivalent to the first part of a
	   tunnel specification.

       connecttimeout
	   This	has been replaced by the acceptconnecttimeout keyword.

       localport
	   This	was the	name of	the clientport keyword prior to	version	2.0.0
	   of Zebedee.

       redirecthost
	   This	was the	name of	the targethost keyword prior to	version	2.0.0
	   of Zebedee.

       remoteport
	   This	was the	name of	the targetport keyword prior to	version	2.0.0
	   of Zebedee.

       targethost
	   This	keyword	has been superseded by the more	general	target
	   keyword.

	   This	keyword	gives the name of a host to which a Zebedee server
	   will	redirect all incoming tunnelled	data, rather than to ports on
	   the local machine.

       targetport
	   This	keyword	has been superseded by the more	general	tunnel
	   keyword.

	   It gives the	port or	list of	ports to which the client will request
	   that	Zebedee	server should establish	connections on the target
	   host. It is equivalent to the final part of a tunnel	specification.

   Other Options
       There are a few command-line options that have no equivalent in the
       configuration file. These are described below.

       -F char
	   The first character of the argument to this option specifies	an
	   additional field separator character, used in parsing configuration
	   file	option lines.  All instances of	this character will be
	   replaced with a space before	lines are parsed. It exists primarily
	   to be used in conjunction with the -x option	where there may	be
	   difficulties	in constructing	and invoking commands containing
	   spaces, owing to limitations	in command interpreters. So, for
	   example, the	command:

	    zebedee -F~	-x "message~'Hello,~World!'"

	   will	output a message like the following:

	    zebedee(1128/1348):	 Hello,	World!

	   Please be aware that	you can	specify	any character as a separator.
	   It is your responsibility to	ensure that the	character you choose
	   does	not conflict with any other usage in the configuration file.

       -p  This	causes Zebedee to generate a private key value and to write it
	   to standard output in a form	that can be used in a configuration
	   file	(see privatekey). For example:

	    privatekey "c480bd48f707c69dec54c9e7b6e22dd04cac659e"

       -P  This	causes Zebedee to generate a public "identity" suitable	for
	   use by the identity checking	feature. The result is written to
	   standard output. For	example:

	    ef8153a0e392df005f67321ca2f0ace5bb8c5a1f myhostname

	   This	option must either be specified	with a configuration file that
	   contains a private key value	or must	be used	in conjunction with -p
	   to generate private and public keys simultaneously.

       -h  This	option causes the remaining command-line arguments to be
	   treated as the names	of files. Each file is read in 8192 byte
	   chunks and the SHA hash is calculated. If no	arguments are
	   specified or	the argument is	""-"" then the standard	input is read
	   and the hash	of that	is calculated. For example:

	    $ zebedee -h /etc/passwd
	    bb1e734aeffd2111417761f5938dea3b53759598 /etc/passwd
	    $ zebedee -h < /etc/passwd
	    bb1e734aeffd2111417761f5938dea3b53759598 -

       -H  This	is similar to the -h option except that	each argument is
	   treated as a	literal	string and the SHA hash	of the string is
	   calculated and printed:

	    $ zebedee -H hello world
	    ac62a630ca850b4ea07eda664eaecf9480843152 hello
	    86bf25ecb8a40b40b885c097c683b6e236fc8085 world

       -S (Windows only)
	   On Windows systems Zebedee can be installed and run as a "service"
	   --- an independently	running	process	that is	started	automatically
	   at system boot time.

	   Zebedee can be installed as a service by specifying the install
	   parameter with the name of a	configuration file, for	example:

	    zebedee "-Sinstall=c:\zebedee\service.zbd"

	   You should always specify the full path to the configuration	file.
	   This	will be	read at	service	start-up and must contain all the
	   parameters required for the service to run. Note that if the	path
	   contains spaces you must enclose it in double quotes, as shown.

	   By default, the name	of the installed service will be taken from
	   the name of the program file, and hence is usually zebedee, but you
	   can change this by using the	-n option:

	    zebedee -n "Zebedee	Client Service"	"-Sinstall=c:\zebedee\clientsvc.zbd"

	   Once	the service has	been installed it will be automatically
	   started the next time that the system reboots. Alternatively	you
	   can start it	manually using the Service Control Panel (under
	   Windows NT).

	   To remove the service specify first stop it and then	use the	remove
	   parameter to	the -S option, along with any necessary	service	name
	   using -n. For example:

	    zebedee -n "Zebedee	Client Service"	-Sremove

	   There is one	further	valid parameter	to the -S option and this is
	   run.	 This is used internally by Zebedee to invoke the service
	   start-up code and should not	be used	directly.

       -x  This	option can be used to set those	configuration parameters that
	   do not have any other direct	command-line equivalent. It takes a
	   string as an	argument and this string is treated as if it were a
	   line	read from a configuration files	(including comments but
	   without "\" line continuation). So, for example:

	    zebedee -x " server	true # It's a server!"

	   is a	rather perverse	way of achieving the same effect as:

	    zebedee -s

   Quick-Reference Summary
       The following table lists the recognised	keywords, their	argument
       types, command-line equivalents,	validity for client, server or both
       and a brief description.

	acceptconnecttimeout
		       seconds	      CS  Timeout for connections to be	accepted
	checkidfile    filename	      CS  Checks peer identities against this file
	checksumlevel  level	 -K   CS  Sets data integrity checksum level (0	to 3)
	clienthost     hostname	 -c   S	  Server initiates connection to client	host
	command	       string	 -e   C	  Specified command to run connected to	tunnel
	compression    level	 -z   CS  Requested maximum compression	level
	connectattempts
		       number	 -C   S	  Number of attempts to	connect	to client
	debug	       boolean	      CS  Run in single-threaded "debug" mode
	detached       boolean	 -d   CS  Detach from the terminal/console
	dropunknownprotocol
		       boolean	      CS  Drop requests	for incompatible protocol
	generator      string	      CS  Hexadecimal Diffie-Hellman generator value
	httpproxy      host:port      CS  Make connections via the given HTTP proxy
	httpproxyauth  user:pass      CS  SUpply HTTP proxy authorisation details
	idletimeout    seconds	      CS  Inactivity timeout for all tunnels
	include	       filename	 -f   CS  Read in the named configuration file
	ipmode	       type	 -U   CS  Run in TCP, UDP or "both" mode (-U = both)
	keygencommand  string	      CS  Command to run to generate key
	keygenlevel    level	      CS  Key generation strength level	(0 to 2)
	keylength      bits	      CS  Requested maximum keylength in bits
	keylifetime    seconds	      CS  Lifetime of shared secret keys
	listenip       address	 -b   CS  Listens only on the specified	IP address
	listenmode     boolean	 -l   C	  Client listens for server connections
	localsource    boolean	      C	  Only accepts connections from	local machine
	lockprotocol   boolean	      CS  Allow	only current default protocol
	logfile	       filename	 -o   CS  Set the output log file
	maxbufsize     bytes	      CS  Specify buffer size for data reads
	maxconnections num	      CS  Specify maximum number of active connections
	message	       string	      CS  Output the specified string
	minchecksumlevel
		       level	      CS  Acceptable minimum checksum level
	minkeylength   bits	      CS  Acceptable minimum keylength in bits
	modulus	       string	      CS  Hexadecimal Diffie-Hellman modulus value
	multiuse       boolean	 -m   C	  Handle multiple connections
	name	       string	      CS  Specify the name of the program
	privatekey     string	      CS  Hexadecimal private key string
	redirect       ports	 -r   S	  Ports	to which server	will redirect traffic
	runasuser      user	 -N   CS  Switch to if running as root (UNIX only)
	server	       boolean	 -s   CS  Selects server-mode or client-mode
	serverconnecttimeout
		       seconds	      CS  Timeout for connection to server
	serverhost     hostname	      C	  Name of server host to which to connect
	serverport     port	 -T   CS  Set the port on which	the server listens
	sharedkey      string	      CS  Hexadecimal shared secret key	string
	sharedkeygencommand
		       string	      CS  Command to run to generate shared key
	target	       spec	      S	  Specifies allowed target host	and ports
	targetconnecttimeout
		       seconds	      S	  Timeout for connection to target
	tcptimeout     seconds	      CS  Inactivity timeout for TCP tunnels
	timestamplog   boolean	 -t   CS  Add timestamps to the	log file
	tunnel	       spec	      C	  Specifies client ports and matching targets
	udpmode	       boolean	 -u   CS  Handle UDP traffic only
	udptimeout     seconds	      CS  Inactivity timeout for UDP tunnels
	verbosity      level	 -v   CS  Set the message logging level

       Other options that have no keyword equivalents:

	-F char
	    Specify an additional field	separator (whitespace) character
	-p  Generate a private key
	-P  Generate a public "identity"
	-h file	...
	    Hash file contents and print results
	-H string ...
	    Hash string	arguments and print results
	-Sinstall=file
	    Install Windows service with specified configuration file
	-Sremove
	    Remove Windows service
	-x string
	    Parse option string

   Identity Checking
       By default Zebedee just establishes an encrypted	channel	between	two
       points. While you know that the data is protected from snooping "on the
       wire" there is no guarantee that	the tunnel ends	up where you think it
       does. By	default, and unless you	are applying any other kind of
       filtering or firewalling, a Zebedee server will accept connections from
       any client that can reach it. If	the service to which you are
       tunnelling does not provide any further authentication, or if it	relies
       on checking the source IP address, then it will be potentially open to
       attack.

       The simplest, but most basic check, that	you can	make is	to restrict
       the IP addresses	from which a server will accept, or to which a client
       will make, connections. You can do this by using	the checkaddress
       keyword.

       IP address checking is useful but not that secure. Zebedee is also open
       to open to "man-in-the-middle" attacks where an eavesdropper pretends
       to a client to be the server and	intercepts all traffic before
       forwarding it on	to the real server. If you are concerned primarily
       with using data compression or protecting against casual	"network
       sniffing" then you may be happy with this situation. If,	however, you
       want more assurance that	your connection	is not being "hijacked"	then
       Zebedee provides	some basic facilities for doing	so.

       A Zebedee server	can validate the identity of the client	at the other
       end of a	tunnel provided	that you are using an encrypted	connection. To
       do so the client	must use a fixed private key. The easiest way to
       generate	such a key is by using the -p option, like this:

	zebedee	-p

       This will output	a line something like this:

	privatekey "410dea0cbd9c10da057848c43a610f6bb859b769"

       The string of hexadecimal digits	will be	different every	time you run
       it. So, on your client system you should	generate a key and save	it in
       a file, for example:

	zebedee	-p > myclient.key

       The file	"myclient.key" now contains the	private	key that will be used
       by Zebedee on this system. The private key must be kept secret so you
       should apply appropriate	protection to this file	to stop	unauthorised
       users accessing it. You now need	to generate the	public "fingerprint"
       associated with this key, which you can do as follows:

	zebedee	-P -f myclient.key > myclient.id

       The contents of the file	"myclient.id" will look	something like this:

	135f04050961d37553731250d5c6f7495f088b32 myclient

       The text	after the string of hexadecimal	digits will be the name	of the
       machine on which	you run	this. It's just	a descriptive tag so you can
       change it to be,	for example:

	135f04050961d37553731250d5c6f7495f088b32 Neil's	PC

       You should now modify your client configuration file to add a line:

	include	"path-to-dir/myclient.key"

       where ""path-to-dir"" is	the directory in which the key file is being
       kept.  The "myclient.id"	file is	used by	any server that	wishes to
       validate	the identity of	"myclient". The	contents are not secret	and
       you should copy this file to the	Zebedee	server.

       On the server you should	add the	contents of "myclient.id" to a single
       file containing the identity "fingerprints" of all clients you wish to
       validate.  This file, for example called	"client.idlist", might look
       like this:

	ba077f6a42bea502f517cab5685e476a713d9621 Rebecca's PC
	3ad38cb1f16957d5c535272ce27557bdaa4389c6 Ben's PC
	135f04050961d37553731250d5c6f7495f088b32 Neil's	PC

       Now, to the server configuration	file add the following line:

	checkidfile "path-to-dir/client.idlist"

       That's it! Now only clients whose identities appear in this file	will
       be able to create tunnels to the	server.	If you remove a	line the
       client will be denied further access.

       At the moment you can only have a single	identity file and it is	an
       "all or nothing"	mechanism --- a	client can either create a tunnel to
       any valid target	or to none at all. This	may be enhanced	in future.

       It is also worth	noting that this mechanism can equally well be used
       for a client to validate	the identity of	a server, if the server	uses a
       fixed private key.

   How does this work?
       By default, Zebedee generates a new private key every time it is
       started.	 If the	same modulus, generator	and private key	are used they
       will always generate the	same public value for use in the Diffie-
       Hellman key exchange protocol. The "fingerprint"	is a hash of the
       modulus,	generator and public key. Only a person	knowing	the private
       key will	be able	to produce public key and successfully decrypt
       traffic.	So, if the same	combination of modulus,	generator and key are
       seen then the identity of the client can	be tied	to the owner of	that
       private key. The	modulus, generator and key strings are hashed together
       to produce the fingerprint merely for convenience and to	keep the size
       of the identity file small.

   Notes on Other Security Issues
       Message Integrity
	   Starting with version 2.5, Zebedee has the ability to perform data
	   integrity validation	on the transmitted data	stream.	This is
	   controlled by the checksumlevel and minchecksumlevel	keywords. This
	   integrity checking is on by default (although not set to the
	   highest level).

	   This	integrity checking does	give a greater assurance that data
	   packets have	not been corrupted "in flight",	but is does add	a
	   little overhead in terms of both data traffic and CPU effort.

       Replay and Insertion Attacks
	   One possible	attack on many networked systems is that of capturing
	   data	streams	that have a known effect --- for example, a telnet
	   session during which	an administrator was known to be performing
	   certain "dangerous" actions --- and then replaying it at some later
	   time. This does not require cracking	the encrypted data stream
	   itself, merely knowing that the same	network	packets	sent to	a
	   server will elicit the same response.

	   When	Zebedee	is operating in	"anonymous" mode the risk of such an
	   attack being	successful is low because different private keys will
	   be generated	every time Zebedee is used. However, if	the identity
	   checking features are used the keys will be fixed and replay	could
	   be a	possibility.  Zebedee protects against this by generating a
	   unique session key for each connection.  Following that, the	final
	   part	of the connection setup	also involves a	challenge-response
	   exchange that verifies that the system at the other end of the
	   connection really knows the shared secret key and is	not just
	   parrotting back previously recorded data.

	   In addition,	Zebedee	uses Blowfish encryption in "cipher feedback"
	   mode	which means that decryption of any part	of the data depends
	   upon	successful decryption of all the data packets that have	gone
	   before it. The challenge-response exchange "salts" the data-stream
	   so even if the protocol being tunnelled is determined a "known
	   plain-text" attack is made more difficult.

       Key Generation
	   A poorly-chosen key can compromise even the strongest encryption
	   mechanism.  When generating keys Zebedee attempts to	gather as much
	   hard-to-guess state data as possible	and then "stir"	it using the
	   SHA hashing algorithm. On modern UNIX systems this generation
	   process should give pretty good keys.

	   On Windows the available state data is somewhat more	predictable,
	   particularly	if an attacker has access to the system. Having	said
	   that, it should be quite acceptable for most	purposes. The comments
	   in the code explain this in more detail if you are interested.

	   If you are unhappy with the key generation mechanisms then you
	   should call out to an external key generation program using the
	   keygencommand option	in a configuration file.  Suggestions for
	   improving the built-in capabilities will also be gratefully
	   received!

       Default Server Configuration
	   By default, if you do not specify any target	ports either in	a
	   target specification	or with	a redirect keyword a Zebedee server
	   will	accept requests	to make	connections to any port. This is
	   almost certainly not	what you want in a production environment.

       Denial of Service Attacks
	   A "denial of	service" attack	is one where a malicious user does not
	   attempt to capture secret information but instead tries to render a
	   service unavailable or unusable. In common with many	network
	   service, Zebedee is somewhat	vulnerable to such attacks. If this is
	   a particular	concern	to you then you	may wish to employ the
	   readtimeout keyword in order	to reduce the susceptibility to	this
	   kind	of attack.

TROUBLESHOOTING
       Although	Zebedee	should work "out of the	box" you might encounter some
       problems. These are most	likely during connection setup --- once	that
       has been	accomplished the data transfer generally goes smoothly.	The
       eaisest way to see what is happening during the setup process is	to use
       the -v option. You will usually want to combine this with the -d	and -D
       options to stop Zebedee from the	terminal and to	force it to handle
       only a single connection	at a time. So, for example, you	might use the
       following command to start up a server:

	zebedee	-dD -v 3 -s

       Setting the logging level to 3 should show you the main exchanges
       during connection setup.	If you believe there is	a problem after	this
       then levels 4 and 5 will	show you what message traffic is being
       exchanged.

EXAMPLES
       In the Zebedee distribution there are a number of example configuration
       files. The following sections describe how they can be used as well as
       how to use Zebedee to tunnel some specific protocols.

   Example Server Configuration
       There is	an example server configuration	file (server.zbd) shipped with
       the Zebedee distribution. This shows most of the	common options.

	#
	# Sample Zebedee server	configuration file
	#
	# This shows the use of	many, but not all, of the configuration	file
	# options available for	use by a server.
	#

	verbosity 2    # Slightly more than basic messages

	# Comment out the following line once you have read the	comments
	# in this file and enabled or disabled the appropriate options!

	message	"DEFAULT CONFIGURATION FILE -- EDIT BEFORE USE"

	detached false # You will probably want	this 'true' for	normal
		       # use but I want	to make	sure that you see the
		       # preceding message if you haven't edited this.

	server true    # Yes, it's a server!
	ipmode both    # Operate in mixed TCP/UDP mode

	compression zlib:9     # Allow maximum zlib compression
	keylength 256	       # Allow keys up to 256 bits
	keylifetime 36000      # Shared	keys last 10 hours
	maxbufsize 16383       # Allow maximum possible	buffer size

	# Uncomment the	following line to log messages to a local file.
	#
	#  logfile './server.log'
	#
	# Or to	log to the system logging facility uncomment this:
	#
	#  logfile SYSLOG

	keygenlevel 2  # Generate maximum strength private keys

	# Uncomment the	following line if you want to use a fixed private
	# key stored in	a static file. The file	should contain a line of
	# the form "privatekey hexadecimal-key-string".	This file should
	# be readable by the user running Zebedee but no-one else.
	#
	#  include './server.key'

	# To validate the identity of clients use a line something like
	# the following:
	#
	#  checkidfile './clients.id'

	# The "redirect" expression can	be use to set the default ports
	# allowed when a target	specification consists of a hostname but
	# no other ports. The "redirect	none" statement	prohibits
	# tunnelling anywhere by default.

	redirect none

	# Set up allowed targets. Note that there are NO targets allowed
	# by this file by default. You must explicitly edit it to enable
	# them.

	# The following	are good for testing purposes. Either TCP or UDP
	# are allowed.
	#
	#  target localhost:daytime,echo,chargen

	# Basic	interactive services, TCP only.
	#
	#  target localhost:telnet/tcp,ftp/tcp

	# VNC traffic -- usually you will only need a subset of	this
	# range, perhaps 5900 or 5901.
	#
	#  target localhost:5900-5999/tcp

	# X Window System -- again, usually you	will only need
	# a subset of this range.
	#
	#  target localhost:6000-6010/tcp

	# Here is an example of	specifying targets using a subnet. In
	# this case allowing tunnels to	be established to VNC servers
	# on the 10.1.1.xx subnet.
	#
	#  target 10.1.1.0/24:5900/tcp

	# The following	line ensures that the default target host
	# is the local machine.	The last named host becomes the
	# default so leaving this here ensures that "localhost"	is,
	# the default unless overridden	on the command line.

	target localhost

       To test the identity checking facilities	you can	uncomment the
       checkidfile line	and then use one of the	supplied client1.key or
       client2.key files on the	client side.

   Use with VNC
       One of the reasons behind writing Zebedee was to	use it over dial-up
       lines with VNC. VNC is a	free system to provide remote display
       capabilities using a "remote frame-buffer" concept. You can use it to
       display Windows desktops	remotely or, with an "Xvnc" server to access
       an "X desktop" from any VNC client machine, or even a Java-enabled
       browser!	See http://www.uk.research.att.com/vnc/	for more details.

       The supplied sample server configuration	file server.zbd	has sample
       target statements (commented out	by default) that are configured	to
       allow redirection of ports 5900-5999 which will allow tunnelling	of VNC
       sessions. This file can be used on both UNIX and	Windows	but note that
       on Windows you must set the "AllowLoopback" flag	in the registry	in
       order for tunnelling to work. Saving the	following snippet (without any
       leading spaces) in file a and then importing it into regedit will do
       the trick:

	REGEDIT4

	[HKEY_LOCAL_MACHINE\SOFTWARE\ORL\WinVNC3]
	"AllowLoopback"=dword:00000001

	[HKEY_LOCAL_MACHINE\SOFTWARE\ORL\WinVNC3\Default]
	"AllowLoopback"=dword:00000001

       You will	find a file with these contents	in the Zebedee distribution by
       the name	vncloopback.reg. Having	set these registry entries then	the
       file vncviewer.zbd can be used to invoke	a VNC viewer tunnelled to the
       host named on the command line. Here are	the contents of	the file
       vncviewer.zbd:

	#
	# Zebedee configuration	file to	start up a tunnelled VNC session
	#
	# Usage: zebedee -f vncviewer.zbd remote-host:vnc-port
	#

	verbosity 1	    # Basic messages only

	server false	    # It's a client
	detached true	    # Detach from terminal

	message	"Starting VNC viewer"

	# On Windows systems you might use the following:

	command	'"c:\Program Files\ORL\VNC\vncviewer.exe" localhost:%d'

	# On UNIX systems you might use	the following:

	# command 'vncviewer localhost:%d'

	compression 6	    # Request normal Zlib compression

       So using	this file as follows:

	zebedee	-f vncviewer.zbd somehost:5901

       will start a VNC	viewer tunnelled to the	VNC server on somehost port
       5901 (the server	you would usually refer	to in VNC-parlance as
       "somehost:1").

       VNC also	supports a Java	viewer.	If the server is running on port 59xx
       then the	viewer can be downloaded via port 58xx.	However, it appears
       that the	Java viewer communicates the main VNC port number to the
       client. So, to tunnel traffic when using	the Java viewer	you must make
       sure that the local and remote ports use	the same numbers. So, for
       example,	to tunnel traffic to a VNC server using	port 5901 you should
       do something like:

	zebedee	5801,5901:remotehost:5801,5901

       This will be problematic	if you already have a VNC server running
       locally on port 5901, but you can usually arrange local and remote VNC
       servers so that there is	no clash.

       There is	one last point worth mentioning. If you	are using compression
       with VNC	it is worth experimenting a bit	with the VNC protocol
       encoding. I have	found that "raw" encoding often	compresses best	and
       sometimes gives better performance with Zebedee over slow links.	But,
       as they say, your mileage may vary!

   Use with the	X Window System
       The X Window System uses	ports in the range 6000	onwards.

       Let's assume that your local machine called xlocal is running an	X
       server on port 6000. This would be the port normally used by the
       display known as	xlocal:0. You now want to send a secure	xterm session
       back to your local display from a machine called	xremote. To do this
       you might run the following command on xlocal:

	zebedee	-s localhost:6000

       Then on xremote you could run:

	zebedee	6001:xlocal:6000

       This means that if the DISPLAY environment variable on xremote is set
       to "localhost:1"	then X traffic will end	up on xlocal. So, for example,
       to send a secured xterm session from xremote to xterm you would run a
       command like this on xremote:

	xterm -display localhost:1

       Note that in order for this to work correctly you must also add an
       entry for localhost to the access control list for the X	server on
       xlocal. You can do this by running the following	command	on xlocal:

	xhost +localhost

   Securing HTTP traffic
       Zebedee can be used to secure or	just compress all traffic to and from
       a Web server. So, for example, if a Web server is running on the
       machine webhost on port 80 and it is also running a Zebedee server then
       the command:

	zebedee	8000:webhost:80

       will set	up a tunnel via	port 8000 on the client	host. Now any URLs
       that previously were addressed via webhost, for example:

	http://webhost/private/index.html

       can now be accessed securely as follows:

	http://localhost:8000/private/index.html

       You could redirect all HTTP traffic via the secure tunnel by setting
       ""localhost:8000"" as your proxy. Be careful, however, only to set this
       as the proxy for	HTTP connections --- other protocols (including	Secure
       HTTP) should be directed	elsewhere. It is also possible to configure
       most browsers to	use different proxies for different domains and	so
       secure connections selectively. Consult your browser's documentation
       for details on how to do	this.

   Securing FTP	traffic
       It is possible to protect the FTP control connection (over which	the
       username	and password are sent) for many	FTP servers using Zebedee "out
       of the box" by following	the instructions below.	It may also be
       possible	to protect the control connection for other servers and	even
       "passive-mode" data connections by using	Zebedee	in conjunction with
       one of the techniques described below.

       The simplest approach, which will protect the control connection	and
       which works with	some FTP servers, is to	run the	Zebedee	server as
       follows:

	zebedee	-s ftpserverhost:ftp

       Note that even if you are running Zebedee on the	same machine as	the
       FTP server you should explictly name it on the command line (or using
       the target keyword). Do not refer to it as localhost. On	the client
       system you could	then run Zebedee as follows to set up a	tunnel via
       port 10000:

	zebedee	10000:ftpserverhost:ftp

       To connect to the FTP server you	would then use a command like:

	ftp clienthost 10000

       Again, use the local client host	name not, localhost. If	your FTP
       client does not support specifying the port on the command line,	as is
       the case	with the standard Windows FTP client program, you may be able
       to use the command ""open clienthost 10000"" from within	the program.
       If you are not running an FTP server on the client machine you could
       also try	running	Zebedee	as:

	zebedee	ftp:ftpserverhost:ftp

       and then	just invoking the FTP client program as:

	ftp clienthost

       The approach just described will	work for FTP servers that do not check
       that the	FTP control and	data connections appear	to come	from the same
       source.	However, some servers such as the widely-used wu-ftpd are more
       strict about this --- for good security reasons.	If you can apparently
       establish a connection to the server but	directory listing and file
       retrievals fail or hang then it is likely that your server is one of
       the strict ones.

       If you find yourself in this situation then a good approach (suggested
       by Magnus Wedburg) is to	investigate your FTP server's support for
       operating with firewalls	and Network Address Translation	(NAT). Many
       modern servers, including wu-ftpd, allow	you to specify the address
       that a server will report for itself in FTP requests. They will also
       allow you to specify a range of ports which will	be used	for "passive
       mode" connections. If you can specify these two values you should be
       able to use Zebedee to tunnel both control traffic and also data
       traffic for passive connections.	Support	for passive mode depends upon
       the particular FTP client being used. Netscape Navigator	and the
       Windows program "WS_FTP"	are examples of	clients	able to	do this.

       Assuming	that you have the capability to	specify	the server response
       address and range of ports you can the use Zebedee as follows. First,
       set the response	address	to the "localhost" address, that is,
       127.0.0.1. Then select a	range of ports to be used for tunnelling
       passive-mode data connections. The size of the range will limit the
       number of simultaneous connections that can be handled. In this case we
       will chose 30000-30010. Now, on the FTP server run:

	zebedee	-s localhost:ftp,30000-30010

       Then on the client run:

	zebedee	2121,30000-30010:ftpserverhost:ftp,30000-30010

       The value of 2121, for the FTP control connection, could	be any other
       convenient port.	The passive port range must, however, be the same as
       that on the server. To access the server	with both control and data
       connections secured using Netscape you would then supply	a URL of the
       form:

	ftp://username@clienthost:2121/

       where username is your user-name	on the FTP server host.

       If you can't configure the target FTP server as described above then
       there is	one more method	that you can try. The Zebedee distribution
       contains	an "FTP	gateway" script	called ftpgw.tcl. This is a program,
       written using the freely-available Tcl scripting	language (see
       <http://tcl.activestate.com>) that intercepts FTP requests and re-
       writes them so that a server is shielded	from the presence of Zebedee.
       You should run this on the same system as the Zebedee server.  Assuming
       that the	FTP server is also running on the same system you can just run
       this as:

	tclsh ftpgw.tcl

       This will start the gateway listening on	port 2121. Obviously, in real
       usage you will probably want to start this in the background. You then
       start the Zebedee server	as:

	zebedee	-s localhost:2121

       Note that in this case you do specify the local host as the target. On
       the client side you can now run:

	zebedee	2121:ftpserverhost:2121

       followed	by:

	ftp clienthost 2121

       You must	still, however,	use the	client host name here.

       This configuration will allow you to tunnel the FTP control connection
       but will	not affect any data connections. Using ftpgw.tcl it is,
       however,	also possible to secure	the passive-mode data channels in a
       similar manner to that described	above.

       To secure passive-mode data connections you must	choose a range of
       ports on	the server that	will be	used for data connections. In this
       example we will again use 30000 to 30010. You then start	ftpgw.tcl with
       the -p option to	specify	this port range:

	tclsh ftpgw.tcl	-p 30000-30100

       The Zebedee server would	then be	started	as:

	zebedee	-s localhost:2121,30000-30100

       and the client as

	zebedee	2121,30000-30100:ftpserverhost:2121,30000-30100

       To access the server with both control and data connections secured
       using Netscape you would	then supply a URL, identical to	that shown
       above, of the form:

	ftp://username@clienthost:2121/

CHANGES
       This section outlines the main user-visible changes since the previous
       "stable"	release, 2.4.1.	Full details, including	bug fixes and other
       non-visible enhancements, are in	the "CHANGES.txt" file in the Zebedee
       distribution.

       Backwards compatibility with Zebedee 1.x	versions of the	protocol
       (which is now more than 3 years old) has	been dropped. Compatibility is
       maintained for releases 2.0.0 and upward.

       New message integrity checking keywords (checksumlevel and
       minchecksumlevel) have been added. These	give assurance that messages
       have not	been tampered with in transit. Also the	keywords
       dropunknownprotocol and lockprotocol help enforce the use of these
       features, if required. These are	all derived from patches submitted by,
       Henrick Lund. Great work	Henrick!

       Added the ability to hand the peer address, target address and target
       port to key generation commands (add a ""+"" to the end of the command
       to get three extra arguments provided). See keygencommand and
       sharedkeygencommand for further details.

       Added httpproxyauth" -- thanks to James CE Johnson.

       Added runasuser|/item_runasuser>	(and the -N option) -- thanks to
       Thomas Melzer.

       The target specification	has been extended to allow per-target client
       identity	and address checking. The identity checking was	originally
       submitted by Alain Turbide and address checking by Henrik Lund (again!)

       The acceptconnecttimeout	connectattempts, serverconnecttimeout and
       targetconnecttimeout keywords have been added to	significantly improve
       the "reverse-mode" operation.

       Add maxconnections to alleviate potential denial	of service attacks.

CREDITS	AND LEGALITIES
       The following information can also be found in the file LICENCE.txt in
       the Zebedee distribution.

	Copyright (c) 1999-2003	by Neil	Winton.	All Rights Reserved.

	This program is	free software; you can redistribute it and/or modify
	it under the terms of the GNU General Public License as	published by
	the Free Software Foundation; either version 2 of the License, or
	(at your option) any later version.

	This program is	distributed in the hope	that it	will be	useful,
	but WITHOUT ANY	WARRANTY; without even the implied warranty of
	MERCHANTABILITY	or FITNESS FOR A PARTICULAR PURPOSE.  See the
	GNU General Public License for more details.

	You should have	received a copy	of the GNU General Public License
	along with this	program; if not, write to the Free Software
	Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307,
	USA.

       A copy of the GNU General Public	License	can be found in	the file
       GPL2.txt.

       You may obtain the latest copy of Zebedee, including full source	code
       from http://www.winton.org.uk/zebedee/ and other	enquiries about
       Zebedee can be e-mailed to the author at	zebedee@winton.org.uk

       Zebedee would not have been possible without the	use of a large amount
       of freely-available software to do all the really hard stuff. I
       gratefully acknowledge the contributions	made by	the authors of the
       following software packages.

       Zebedee uses the	"Blowfish" encryption algorithm	devised	by Bruce
       Schneier.  For more information on Blowfish see
       http://www.counterpane.com/blowfish.html	.  The implementation used is
       by Eric Young and is covered by the following copyright:

	Copyright (C) 1995-1997	Eric Young (eay@mincom.oz.au)
	All rights reserved.

	This package is	an Blowfish implementation written
	by Eric	Young (eay@mincom.oz.au).

	This library is	free for commercial and	non-commercial use as long as
	the following conditions are aheared to.  The following	conditions
	apply to all code found	in this	distribution.

	Copyright remains Eric Young's,	and as such any	Copyright notices in
	the code are not to be removed.

	Redistribution and use in source and binary forms, with	or without
	modification, are permitted provided that the following	conditions
	are met:
	1. Redistributions of source code must retain the copyright
	notice,	this list of conditions	and the	following disclaimer.
	2. Redistributions in binary form must reproduce the above copyright
	notice,	this list of conditions	and the	following disclaimer in	the
	documentation and/or other materials provided with the distribution.
	3. All advertising materials mentioning	features or use	of this	software
	must display the following acknowledgement:
	This product includes software developed by Eric Young (eay@mincom.oz.au)

	THIS SOFTWARE IS PROVIDED BY ERIC YOUNG	``AS IS'' AND
	ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
	IMPLIED	WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A	PARTICULAR PURPOSE
	ARE DISCLAIMED.	 IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
	FOR ANY	DIRECT,	INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
	DAMAGES	(INCLUDING, BUT	NOT LIMITED TO,	PROCUREMENT OF SUBSTITUTE GOODS
	OR SERVICES; LOSS OF USE, DATA,	OR PROFITS; OR BUSINESS	INTERRUPTION)
	HOWEVER	CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
	LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
	OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE	POSSIBILITY OF
	SUCH DAMAGE.

	The license and	distribution terms for any publically available	version	or
	derivative of this code	cannot be changed.  i.e. this code cannot simply be
	copied and put under another distrubution license
	[including the GNU Public License.]

	The reason behind this being stated in this direct manner is past
	experience in code simply being	copied and the attribution removed
	from it	and then being distributed as part of other packages. This
	implementation was a non-trivial and unpaid effort.

       Zebedee uses the	zlib compression library by Jean-loup Gailly and Mark
       Adler. It is covered by the following copyright notice:

	(C) 1995-1998 Jean-loup	Gailly and Mark	Adler

	This software is provided 'as-is', without any express or implied
	warranty.  In no event will the	authors	be held	liable for any damages
	arising	from the use of	this software.

	Permission is granted to anyone	to use this software for any purpose,
	including commercial applications, and to alter	it and redistribute it
	freely,	subject	to the following restrictions:

	1. The origin of this software must not	be misrepresented; you must not
	claim that you wrote the original software. If you use this software
	in a product, an acknowledgment	in the product documentation would be
	appreciated but	is not required.
	2. Altered source versions must	be plainly marked as such, and must not	be
	misrepresented as being	the original software.
	3. This	notice may not be removed or altered from any source distribution.

	Jean-loup Gailly	Mark Adler
	jloup@gzip.org		madler@alumni.caltech.edu

       Zebedee may use the bzip2 compression library by	Julian Seward which is
       covered by the following	licence:

	This program, "bzip2" and associated library "libbzip2", are
	copyright (C) 1996-1999	Julian R Seward.  All rights reserved.

	Redistribution and use in source and binary forms, with	or without
	modification, are permitted provided that the following	conditions
	are met:

	1. Redistributions of source code must retain the above	copyright
	   notice, this	list of	conditions and the following disclaimer.

	2. The origin of this software must not	be misrepresented; you must
	   not claim that you wrote the	original software.  If you use this
	   software in a product, an acknowledgment in the product
	   documentation would be appreciated but is not required.

	3. Altered source versions must	be plainly marked as such, and must
	   not be misrepresented as being the original software.

	4. The name of the author may not be used to endorse or	promote
	   products derived from this software without specific	prior written
	   permission.

	THIS SOFTWARE IS PROVIDED BY THE AUTHOR	``AS IS'' AND ANY EXPRESS
	OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
	WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A	PARTICULAR PURPOSE
	ARE DISCLAIMED.	 IN NO EVENT SHALL THE AUTHOR BE LIABLE	FOR ANY
	DIRECT,	INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
	DAMAGES	(INCLUDING, BUT	NOT LIMITED TO,	PROCUREMENT OF SUBSTITUTE
	GOODS OR SERVICES; LOSS	OF USE,	DATA, OR PROFITS; OR BUSINESS
	INTERRUPTION) HOWEVER CAUSED AND ON ANY	THEORY OF LIABILITY,
	WHETHER	IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
	NEGLIGENCE OR OTHERWISE) ARISING IN ANY	WAY OUT	OF THE USE OF THIS
	SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF	SUCH DAMAGE.

	Julian Seward, Cambridge, UK.
	jseward@acm.org
	bzip2/libbzip2 version 0.9.5 of	24 May 1999

       By default Zebedee is built using an aribtrary precision	integer
       arithmetic library derived from the sources to "mirrordir-0.10.49"
       which in	turn derived this from the Python sources. The copyright is as
       follows:

	huge-number.c: arbitrary precision integer library from	Python sources
	This has nothing to do with cryptography.
	Copyright (C) 1998 Paul	Sheer

	This program is	free software; you can redistribute it and/or modify
	it under the terms of the GNU General Public License as	published by
	the Free Software Foundation; either version 2 of the License, or
	(at your option) any later version.

	This program is	distributed in the hope	that it	will be	useful,
	but WITHOUT ANY	WARRANTY; without even the implied warranty of
	MERCHANTABILITY	or FITNESS FOR A PARTICULAR PURPOSE.  See the
	GNU General Public License for more details.

	You should have	received a copy	of the GNU General Public License
	along with this	program; if not, write to the Free Software
	Foundation, Inc., 675 Mass Ave,	Cambridge, MA 02139, USA.

	This file was taken from the Python source for `long' type
	integers. I have changed it to compile independently of	the
	Python source, and added the optimisation that GNU C can
	use 31 bit digits instead of Python's 15 bit. You can download
	the original from www.python.org. This file bears little
	resemblance to the original though - paul

	Copyright 1991-1995 by Stichting Mathematisch Centrum, Amsterdam,
	The Netherlands.

				All Rights Reserved

	Permission to use, copy, modify, and distribute	this software and its
	documentation for any purpose and without fee is hereby	granted,
	provided that the above	copyright notice appear	in all copies and that
	both that copyright notice and this permission notice appear in
	supporting documentation, and that the names of	Stichting Mathematisch
	Centrum	or CWI or Corporation for National Research Initiatives	or
	CNRI not be used in advertising	or publicity pertaining	to
	distribution of	the software without specific, written prior
	permission.

	While CWI is the initial source	for this software, a modified version
	is made	available by the Corporation for National Research Initiatives
	(CNRI) at the Internet address ftp://ftp.python.org.

	STICHTING MATHEMATISCH CENTRUM AND CNRI	DISCLAIM ALL WARRANTIES	WITH
	REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF
	MERCHANTABILITY	AND FITNESS, IN	NO EVENT SHALL STICHTING MATHEMATISCH
	CENTRUM	OR CNRI	BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL
	DAMAGES	OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
	PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
	TORTIOUS ACTION, ARISING OUT OF	OR IN CONNECTION WITH THE USE OR
	PERFORMANCE OF THIS SOFTWARE.

       Zebedee uses the	Secure Hash Algorith (SHA) the code for	which was
       derived from Uwe	Hollerbach's SHA module	for perl. The code contains
       the following statement:

	NIST Secure Hash Algorithm
	heavily	modified by Uwe	Hollerbach <uh@alumni.caltech edu>
	from Peter C. Gutmann's	implementation as found	in
	Applied	Cryptography by	Bruce Schneier

	This code is in	the public domain

       Under Windows, Zebedee uses an implementation of	the getopt function
       covered by the following	copyright:

	Copyright (c) 1987, 1993, 1994
       The Regents of the University of	California.  All rights	reserved.

	Redistribution and use in source and binary forms, with	or without
	modification, are permitted provided that the following	conditions
	are met:
	1. Redistributions of source code must retain the above	copyright
	notice,	this list of conditions	and the	following disclaimer.
	2. Redistributions in binary form must reproduce the above copyright
	notice,	this list of conditions	and the	following disclaimer in	the
	documentation and/or other materials provided with the distribution.
	3. All advertising materials mentioning	features or use	of this	software
	must display the following acknowledgement:
       This product includes software developed	by the University of
       California, Berkeley and	its contributors.
	4. Neither the name of the University nor the names of its contributors
	may be used to endorse or promote products derived from	this software
	without	specific prior written permission.

	THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
	ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
	IMPLIED	WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A	PARTICULAR PURPOSE
	ARE DISCLAIMED.	 IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
	FOR ANY	DIRECT,	INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
	DAMAGES	(INCLUDING, BUT	NOT LIMITED TO,	PROCUREMENT OF SUBSTITUTE GOODS
	OR SERVICES; LOSS OF USE, DATA,	OR PROFITS; OR BUSINESS	INTERRUPTION)
	HOWEVER	CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
	LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
	OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE	POSSIBILITY OF
	SUCH DAMAGE.

   Thanks
       Special thanks go to those people who have taken	the trouble to give me
       feedback	and suggestions	for improvement!

	$Id: zebedee.pod,v 1.31	2005/09/02 22:10:41 ndwinton Exp $

Zebedee	2.5.3			  2021-03-01			    ZEBEDEE(1)

NAME | SYNOPSIS | DESCRIPTION | TROUBLESHOOTING | EXAMPLES | CHANGES | CREDITS AND LEGALITIES

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=zebedee&sektion=1&manpath=FreeBSD+13.0-RELEASE+and+Ports>

home | help