zebedee

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:

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

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

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

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

       ·   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:

       ·   Zlib compression

       ·   Blowfish encryption and

       ·   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                     2014-01-07                        ZEBEDEE(1)