Import OpenSSH 4.3p2.

1 files changed, 566 insertions, 0 deletions

diff --git a/sshd.0 b/sshd.0
new file mode 100644
index 000000000..040be6cad
--- /dev/null
+++ b/sshd.0
@@ -0,0 +1,566 @@
+SSHD(8)                 OpenBSD System Manager's Manual                SSHD(8)
+
+NAME
+     sshd - OpenSSH SSH daemon
+
+SYNOPSIS
+     sshd [-46Ddeiqt] [-b bits] [-f config_file] [-g login_grace_time]
+          [-h host_key_file] [-k key_gen_time] [-o option] [-p port] [-u len]
+
+DESCRIPTION
+     sshd (OpenSSH Daemon) is the daemon program for ssh(1).  Together these
+     programs replace rlogin and rsh, and provide secure encrypted communica-
+     tions between two untrusted hosts over an insecure network.
+
+     sshd listens for connections from clients.  It is normally started at
+     boot from /etc/rc.  It forks a new daemon for each incoming connection.
+     The forked daemons handle key exchange, encryption, authentication, com-
+     mand execution, and data exchange.
+
+     sshd can be configured using command-line options or a configuration file
+     (by default sshd_config(5)); command-line options override values speci-
+     fied in the configuration file.  sshd rereads its configuration file when
+     it receives a hangup signal, SIGHUP, by executing itself with the name
+     and options it was started with, e.g., /usr/sbin/sshd.
+
+     The options are as follows:
+
+     -4      Forces sshd to use IPv4 addresses only.
+
+     -6      Forces sshd to use IPv6 addresses only.
+
+     -b bits
+             Specifies the number of bits in the ephemeral protocol version 1
+             server key (default 768).
+
+     -D      When this option is specified, sshd will not detach and does not
+             become a daemon.  This allows easy monitoring of sshd.
+
+     -d      Debug mode.  The server sends verbose debug output to the system
+             log, and does not put itself in the background.  The server also
+             will not fork and will only process one connection.  This option
+             is only intended for debugging for the server.  Multiple -d op-
+             tions increase the debugging level.  Maximum is 3.
+
+     -e      When this option is specified, sshd will send the output to the
+             standard error instead of the system log.
+
+     -f configuration_file
+             Specifies the name of the configuration file.  The default is
+             /etc/ssh/sshd_config.  sshd refuses to start if there is no con-
+             figuration file.
+
+     -g login_grace_time
+             Gives the grace time for clients to authenticate themselves (de-
+             fault 120 seconds).  If the client fails to authenticate the user
+             within this many seconds, the server disconnects and exits.  A
+             value of zero indicates no limit.
+
+     -h host_key_file
+             Specifies a file from which a host key is read.  This option must
+             be given if sshd is not run as root (as the normal host key files
+             are normally not readable by anyone but root).  The default is
+             /etc/ssh/ssh_host_key for protocol version 1, and
+             /etc/ssh/ssh_host_rsa_key and /etc/ssh/ssh_host_dsa_key for pro-
+             tocol version 2.  It is possible to have multiple host key files
+             for the different protocol versions and host key algorithms.
+
+     -i      Specifies that sshd is being run from inetd(8).  sshd is normally
+             not run from inetd because it needs to generate the server key
+             before it can respond to the client, and this may take tens of
+             seconds.  Clients would have to wait too long if the key was re-
+             generated every time.  However, with small key sizes (e.g., 512)
+             using sshd from inetd may be feasible.
+
+     -k key_gen_time
+             Specifies how often the ephemeral protocol version 1 server key
+             is regenerated (default 3600 seconds, or one hour).  The motiva-
+             tion for regenerating the key fairly often is that the key is not
+             stored anywhere, and after about an hour it becomes impossible to
+             recover the key for decrypting intercepted communications even if
+             the machine is cracked into or physically seized.  A value of ze-
+             ro indicates that the key will never be regenerated.
+
+     -o option
+             Can be used to give options in the format used in the configura-
+             tion file.  This is useful for specifying options for which there
+             is no separate command-line flag.  For full details of the op-
+             tions, and their values, see sshd_config(5).
+
+     -p port
+             Specifies the port on which the server listens for connections
+             (default 22).  Multiple port options are permitted.  Ports speci-
+             fied in the configuration file with the Port option are ignored
+             when a command-line port is specified.  Ports specified using the
+             ListenAddress option override command-line ports.
+
+     -q      Quiet mode.  Nothing is sent to the system log.  Normally the be-
+             ginning, authentication, and termination of each connection is
+             logged.
+
+     -t      Test mode.  Only check the validity of the configuration file and
+             sanity of the keys.  This is useful for updating sshd reliably as
+             configuration options may change.
+
+     -u len  This option is used to specify the size of the field in the utmp
+             structure that holds the remote host name.  If the resolved host
+             name is longer than len, the dotted decimal value will be used
+             instead.  This allows hosts with very long host names that over-
+             flow this field to still be uniquely identified.  Specifying -u0
+             indicates that only dotted decimal addresses should be put into
+             the utmp file.  -u0 may also be used to prevent sshd from making
+             DNS requests unless the authentication mechanism or configuration
+             requires it.  Authentication mechanisms that may require DNS in-
+             clude RhostsRSAAuthentication, HostbasedAuthentication, and using
+             a from="pattern-list" option in a key file.  Configuration op-
+             tions that require DNS include using a USER@HOST pattern in
+             AllowUsers or DenyUsers.
+
+AUTHENTICATION
+     The OpenSSH SSH daemon supports SSH protocols 1 and 2.  Both protocols
+     are supported by default, though this can be changed via the Protocol op-
+     tion in sshd_config(5).  Protocol 2 supports both RSA and DSA keys; pro-
+     tocol 1 only supports RSA keys.  For both protocols, each host has a
+     host-specific key, normally 2048 bits, used to identify the host.
+
+     Forward security for protocol 1 is provided through an additional server
+     key, normally 768 bits, generated when the server starts.  This key is
+     normally regenerated every hour if it has been used, and is never stored
+     on disk.  Whenever a client connects, the daemon responds with its public
+     host and server keys.  The client compares the RSA host key against its
+     own database to verify that it has not changed.  The client then gener-
+     ates a 256-bit random number.  It encrypts this random number using both
+     the host key and the server key, and sends the encrypted number to the
+     server.  Both sides then use this random number as a session key which is
+     used to encrypt all further communications in the session.  The rest of
+     the session is encrypted using a conventional cipher, currently Blowfish
+     or 3DES, with 3DES being used by default.  The client selects the encryp-
+     tion algorithm to use from those offered by the server.
+
+     For protocol 2, forward security is provided through a Diffie-Hellman key
+     agreement.  This key agreement results in a shared session key.  The rest
+     of the session is encrypted using a symmetric cipher, currently 128-bit
+     AES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AES, or 256-bit AES.  The
+     client selects the encryption algorithm to use from those offered by the
+     server.  Additionally, session integrity is provided through a crypto-
+     graphic message authentication code (hmac-sha1 or hmac-md5).
+
+     Finally, the server and the client enter an authentication dialog.  The
+     client tries to authenticate itself using host-based authentication, pub-
+     lic key authentication, challenge-response authentication, or password
+     authentication.
+
+     Regardless of the authentication type, the account is checked to ensure
+     that it is accessible.  An account is not accessible if it is locked,
+     listed in DenyUsers or its group is listed in DenyGroups .  The defini-
+     tion of a locked account is system dependant. Some platforms have their
+     own account database (eg AIX) and some modify the passwd field ( `*LK*'
+     on Solaris and UnixWare, `*' on HP-UX, containing `Nologin' on Tru64, a
+     leading `*LOCKED*' on FreeBSD and a leading `!!' on Linux).  If there is
+     a requirement to disable password authentication for the account while
+     allowing still public-key, then the passwd field should be set to some-
+     thing other than these values (eg `NP' or `*NP*' ).
+
+     System security is not improved unless rshd, rlogind, and rexecd are dis-
+     abled (thus completely disabling rlogin and rsh into the machine).
+
+COMMAND EXECUTION AND DATA FORWARDING
+     If the client successfully authenticates itself, a dialog for preparing
+     the session is entered.  At this time the client may request things like
+     allocating a pseudo-tty, forwarding X11 connections, forwarding TCP con-
+     nections, or forwarding the authentication agent connection over the se-
+     cure channel.
+
+     Finally, the client either requests a shell or execution of a command.
+     The sides then enter session mode.  In this mode, either side may send
+     data at any time, and such data is forwarded to/from the shell or command
+     on the server side, and the user terminal in the client side.
+
+     When the user program terminates and all forwarded X11 and other connec-
+     tions have been closed, the server sends command exit status to the
+     client, and both sides exit.
+
+LOGIN PROCESS
+     When a user successfully logs in, sshd does the following:
+
+           1.   If the login is on a tty, and no command has been specified,
+                prints last login time and /etc/motd (unless prevented in the
+                configuration file or by ~/.hushlogin; see the FILES section).
+
+           2.   If the login is on a tty, records login time.
+
+           3.   Checks /etc/nologin; if it exists, prints contents and quits
+                (unless root).
+
+           4.   Changes to run with normal user privileges.
+
+           5.   Sets up basic environment.
+
+           6.   Reads the file ~/.ssh/environment, if it exists, and users are
+                allowed to change their environment.  See the
+                PermitUserEnvironment option in sshd_config(5).
+
+           7.   Changes to user's home directory.
+
+           8.   If ~/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists,
+                runs it; otherwise runs xauth.  The ``rc'' files are given the
+                X11 authentication protocol and cookie in standard input.
+
+           9.   Runs user's shell or command.
+
+AUTHORIZED_KEYS FILE FORMAT
+     ~/.ssh/authorized_keys is the default file that lists the public keys
+     that are permitted for RSA authentication in protocol version 1 and for
+     public key authentication (PubkeyAuthentication) in protocol version 2.
+     AuthorizedKeysFile may be used to specify an alternative file.
+
+     Each line of the file contains one key (empty lines and lines starting
+     with a `#' are ignored as comments).  Each RSA public key consists of the
+     following fields, separated by spaces: options, bits, exponent, modulus,
+     comment.  Each protocol version 2 public key consists of: options, key-
+     type, base64 encoded key, comment.  The options field is optional; its
+     presence is determined by whether the line starts with a number or not
+     (the options field never starts with a number).  The bits, exponent, mod-
+     ulus and comment fields give the RSA key for protocol version 1; the com-
+     ment field is not used for anything (but may be convenient for the user
+     to identify the key).  For protocol version 2 the keytype is ``ssh-dss''
+     or ``ssh-rsa''.
+
+     Note that lines in this file are usually several hundred bytes long (be-
+     cause of the size of the public key encoding) up to a limit of 8 kilo-
+     bytes, which permits DSA keys up to 8 kilobits and RSA keys up to 16
+     kilobits.  You don't want to type them in; instead, copy the
+     identity.pub, id_dsa.pub or the id_rsa.pub file and edit it.
+
+     sshd enforces a minimum RSA key modulus size for protocol 1 and protocol
+     2 keys of 768 bits.
+
+     The options (if present) consist of comma-separated option specifica-
+     tions.  No spaces are permitted, except within double quotes.  The fol-
+     lowing option specifications are supported (note that option keywords are
+     case-insensitive):
+
+     from="pattern-list"
+             Specifies that in addition to public key authentication, the
+             canonical name of the remote host must be present in the comma-
+             separated list of patterns (`*' and `?' serve as wildcards).  The
+             list may also contain patterns negated by prefixing them with
+             `!'; if the canonical host name matches a negated pattern, the
+             key is not accepted.  The purpose of this option is to optionally
+             increase security: public key authentication by itself does not
+             trust the network or name servers or anything (but the key); how-
+             ever, if somebody somehow steals the key, the key permits an in-
+             truder to log in from anywhere in the world.  This additional op-
+             tion makes using a stolen key more difficult (name servers and/or
+             routers would have to be compromised in addition to just the
+             key).
+
+     command="command"
+             Specifies that the command is executed whenever this key is used
+             for authentication.  The command supplied by the user (if any) is
+             ignored.  The command is run on a pty if the client requests a
+             pty; otherwise it is run without a tty.  If an 8-bit clean chan-
+             nel is required, one must not request a pty or should specify no-
+             pty.  A quote may be included in the command by quoting it with a
+             backslash.  This option might be useful to restrict certain pub-
+             lic keys to perform just a specific operation.  An example might
+             be a key that permits remote backups but nothing else.  Note that
+             the client may specify TCP and/or X11 forwarding unless they are
+             explicitly prohibited.  Note that this option applies to shell,
+             command or subsystem execution.
+
+     environment="NAME=value"
+             Specifies that the string is to be added to the environment when
+             logging in using this key.  Environment variables set this way
+             override other default environment values.  Multiple options of
+             this type are permitted.  Environment processing is disabled by
+             default and is controlled via the PermitUserEnvironment option.
+             This option is automatically disabled if UseLogin is enabled.
+
+     no-port-forwarding
+             Forbids TCP forwarding when this key is used for authentication.
+             Any port forward requests by the client will return an error.
+             This might be used, e.g., in connection with the command option.
+
+     no-X11-forwarding
+             Forbids X11 forwarding when this key is used for authentication.
+             Any X11 forward requests by the client will return an error.
+
+     no-agent-forwarding
+             Forbids authentication agent forwarding when this key is used for
+             authentication.
+
+     no-pty  Prevents tty allocation (a request to allocate a pty will fail).
+
+     permitopen="host:port"
+             Limit local ``ssh -L'' port forwarding such that it may only con-
+             nect to the specified host and port.  IPv6 addresses can be spec-
+             ified with an alternative syntax: host/port.  Multiple permitopen
+             options may be applied separated by commas.  No pattern matching
+             is performed on the specified hostnames, they must be literal do-
+             mains or addresses.
+
+     tunnel="n"
+             Force a tun(4) device on the server.  Without this option, the
+             next available device will be used if the client requests a tun-
+             nel.
+
+   Examples
+     1024 33 12121...312314325 ylo@foo.bar
+
+     from="*.niksula.hut.fi,!pc.niksula.hut.fi" 1024 35 23...2334 ylo@niksula
+
+     command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323 back-
+     up.hut.fi
+
+     permitopen="10.2.1.55:80",permitopen="10.2.1.56:25" 1024 33 23...2323
+
+     tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...== reyk@openb-
+     sd.org
+
+SSH_KNOWN_HOSTS FILE FORMAT
+     The /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts files contain host
+     public keys for all known hosts.  The global file should be prepared by
+     the administrator (optional), and the per-user file is maintained auto-
+     matically: whenever the user connects from an unknown host its key is
+     added to the per-user file.
+
+     Each line in these files contains the following fields: hostnames, bits,
+     exponent, modulus, comment.  The fields are separated by spaces.
+
+     Hostnames is a comma-separated list of patterns (`*' and `?' act as wild-
+     cards); each pattern in turn is matched against the canonical host name
+     (when authenticating a client) or against the user-supplied name (when
+     authenticating a server).  A pattern may also be preceded by `!' to indi-
+     cate negation: if the host name matches a negated pattern, it is not ac-
+     cepted (by that line) even if it matched another pattern on the line.
+
+     Alternately, hostnames may be stored in a hashed form which hides host
+     names and addresses should the file's contents be disclosed.  Hashed
+     hostnames start with a `|' character.  Only one hashed hostname may ap-
+     pear on a single line and none of the above negation or wildcard opera-
+     tors may be applied.
+
+     Bits, exponent, and modulus are taken directly from the RSA host key;
+     they can be obtained, e.g., from /etc/ssh/ssh_host_key.pub.  The optional
+     comment field continues to the end of the line, and is not used.
+
+     Lines starting with `#' and empty lines are ignored as comments.
+
+     When performing host authentication, authentication is accepted if any
+     matching line has the proper key.  It is thus permissible (but not recom-
+     mended) to have several lines or different host keys for the same names.
+     This will inevitably happen when short forms of host names from different
+     domains are put in the file.  It is possible that the files contain con-
+     flicting information; authentication is accepted if valid information can
+     be found from either file.
+
+     Note that the lines in these files are typically hundreds of characters
+     long, and you definitely don't want to type in the host keys by hand.
+     Rather, generate them by a script or by taking /etc/ssh/ssh_host_key.pub
+     and adding the host names at the front.
+
+   Examples
+
+     closenet,...,130.233.208.41 1024 37 159...93 closenet.hut.fi
+     cvs.openbsd.org,199.185.137.3 ssh-rsa AAAA1234.....=
+
+     # A hashed hostname
+     |1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
+     AAAA1234.....=
+
+FILES
+     /etc/ssh/sshd_config
+             Contains configuration data for sshd.  The file format and con-
+             figuration options are described in sshd_config(5).
+
+     /etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key,
+             /etc/ssh/ssh_host_rsa_key
+             These three files contain the private parts of the host keys.
+             These files should only be owned by root, readable only by root,
+             and not accessible to others.  Note that sshd does not start if
+             this file is group/world-accessible.
+
+     /etc/ssh/ssh_host_key.pub, /etc/ssh/ssh_host_dsa_key.pub,
+             /etc/ssh/ssh_host_rsa_key.pub
+             These three files contain the public parts of the host keys.
+             These files should be world-readable but writable only by root.
+             Their contents should match the respective private parts.  These
+             files are not really used for anything; they are provided for the
+             convenience of the user so their contents can be copied to known
+             hosts files.  These files are created using ssh-keygen(1).
+
+     /etc/moduli
+             Contains Diffie-Hellman groups used for the "Diffie-Hellman Group
+             Exchange".  The file format is described in moduli(5).
+
+     /var/empty
+             chroot(2) directory used by sshd during privilege separation in
+             the pre-authentication phase.  The directory should not contain
+             any files and must be owned by root and not group or world-
+             writable.
+
+     /var/run/sshd.pid
+             Contains the process ID of the sshd listening for connections (if
+             there are several daemons running concurrently for different
+             ports, this contains the process ID of the one started last).
+             The content of this file is not sensitive; it can be world-read-
+             able.
+
+     ~/.ssh/authorized_keys
+             Lists the public keys (RSA or DSA) that can be used to log into
+             the user's account.  This file must be readable by root (which
+             may on some machines imply it being world-readable if the user's
+             home directory resides on an NFS volume).  It is recommended that
+             it not be accessible by others.  The format of this file is de-
+             scribed above.  Users will place the contents of their
+             identity.pub, id_dsa.pub and/or id_rsa.pub files into this file,
+             as described in ssh-keygen(1).
+
+     /etc/ssh/ssh_known_hosts, ~/.ssh/known_hosts
+             These files are consulted when using rhosts with RSA host authen-
+             tication or protocol version 2 hostbased authentication to check
+             the public key of the host.  The key must be listed in one of
+             these files to be accepted.  The client uses the same files to
+             verify that it is connecting to the correct remote host.  These
+             files should be writable only by root/the owner.
+             /etc/ssh/ssh_known_hosts should be world-readable, and
+             ~/.ssh/known_hosts can, but need not be, world-readable.
+
+     /etc/motd
+             See motd(5).
+
+     ~/.hushlogin
+             This file is used to suppress printing the last login time and
+             /etc/motd, if PrintLastLog and PrintMotd, respectively, are en-
+             abled.  It does not suppress printing of the banner specified by
+             Banner.
+
+     /etc/nologin
+             If this file exists, sshd refuses to let anyone except root log
+             in.  The contents of the file are displayed to anyone trying to
+             log in, and non-root connections are refused.  The file should be
+             world-readable.
+
+     /etc/hosts.allow, /etc/hosts.deny
+             Access controls that should be enforced by tcp-wrappers are de-
+             fined here.  Further details are described in hosts_access(5).
+
+     ~/.rhosts
+             This file is used during RhostsRSAAuthentication and
+             HostbasedAuthentication and contains host-username pairs, sepa-
+             rated by a space, one per line.  The given user on the corre-
+             sponding host is permitted to log in without a password.  The
+             same file is used by rlogind and rshd.  The file must be writable
+             only by the user; it is recommended that it not be accessible by
+             others.
+
+             It is also possible to use netgroups in the file.  Either host or
+             user name may be of the form +@groupname to specify all hosts or
+             all users in the group.
+
+     ~/.shosts
+             For ssh, this file is exactly the same as for .rhosts.  However,
+             this file is not used by rlogin and rshd, so using this permits
+             access using SSH only.
+
+     /etc/hosts.equiv
+             This file is used during RhostsRSAAuthentication and
+             HostbasedAuthentication authentication.  In the simplest form,
+             this file contains host names, one per line.  Users on those
+             hosts are permitted to log in without a password, provided they
+             have the same user name on both machines.  The host name may also
+             be followed by a user name; such users are permitted to log in as
+             any user on this machine (except root).  Additionally, the syntax
+             ``+@group'' can be used to specify netgroups.  Negated entries
+             start with `-'.
+
+             If the client host/user is successfully matched in this file, lo-
+             gin is automatically permitted provided the client and server us-
+             er names are the same.  Additionally, successful client host key
+             authentication is required.  This file must be writable only by
+             root; it is recommended that it be world-readable.
+
+             Warning: It is almost never a good idea to use user names in
+             hosts.equiv.  Beware that it really means that the named user(s)
+             can log in as anybody, which includes bin, daemon, adm, and other
+             accounts that own critical binaries and directories.  Using a us-
+             er name practically grants the user root access.  The only valid
+             use for user names that I can think of is in negative entries.
+
+             Note that this warning also applies to rsh/rlogin.
+
+     /etc/shosts.equiv
+             This is processed exactly as /etc/hosts.equiv.  However, this
+             file may be useful in environments that want to run both
+             rsh/rlogin and ssh.
+
+     ~/.ssh/environment
+             This file is read into the environment at login (if it exists).
+             It can only contain empty lines, comment lines (that start with
+             `#'), and assignment lines of the form name=value.  The file
+             should be writable only by the user; it need not be readable by
+             anyone else.  Environment processing is disabled by default and
+             is controlled via the PermitUserEnvironment option.
+
+     ~/.ssh/rc
+             If this file exists, it is run with /bin/sh after reading the en-
+             vironment files but before starting the user's shell or command.
+             It must not produce any output on stdout; stderr must be used in-
+             stead.  If X11 forwarding is in use, it will receive the "proto
+             cookie" pair in its standard input (and DISPLAY in its environ-
+             ment).  The script must call xauth(1) because sshd will not run
+             xauth automatically to add X11 cookies.
+
+             The primary purpose of this file is to run any initialization
+             routines which may be needed before the user's home directory be-
+             comes accessible; AFS is a particular example of such an environ-
+             ment.
+
+             This file will probably contain some initialization code followed
+             by something similar to:
+
+             if read proto cookie && [ -n "$DISPLAY" ]; then
+                     if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
+                             # X11UseLocalhost=yes
+                             echo add unix:`echo $DISPLAY |
+                                 cut -c11-` $proto $cookie
+                     else
+                             # X11UseLocalhost=no
+                             echo add $DISPLAY $proto $cookie
+                     fi | xauth -q -
+             fi
+
+             If this file does not exist, /etc/ssh/sshrc is run, and if that
+             does not exist either, xauth is used to add the cookie.
+
+             This file should be writable only by the user, and need not be
+             readable by anyone else.
+
+     /etc/ssh/sshrc
+             Like ~/.ssh/rc.  This can be used to specify machine-specific lo-
+             gin-time initializations globally.  This file should be writable
+             only by root, and should be world-readable.
+
+SEE ALSO
+     scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1),
+     chroot(2), hosts_access(5), login.conf(5), moduli(5), sshd_config(5),
+     inetd(8), sftp-server(8)
+
+     T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen, SSH
+     Protocol Architecture, draft-ietf-secsh-architecture-12.txt, January
+     2002, work in progress material.
+
+     M. Friedl, N. Provos, and W. A. Simpson, Diffie-Hellman Group Exchange
+     for the SSH Transport Layer Protocol, draft-ietf-secsh-dh-group-
+     exchange-02.txt, January 2002, work in progress material.
+
+AUTHORS
+     OpenSSH is a derivative of the original and free ssh 1.2.12 release by
+     Tatu Ylonen.  Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo
+     de Raadt and Dug Song removed many bugs, re-added newer features and
+     created OpenSSH.  Markus Friedl contributed the support for SSH protocol
+     versions 1.5 and 2.0.  Niels Provos and Markus Friedl contributed support
+     for privilege separation.
+
+OpenBSD 3.9                   September 25, 1999                             9