- jmc@cvs.openbsd.org 2006/01/25 09:04:34

     [sshd.8]
     move the options description up the page, and a few additional tweaks
     whilst in here;
     ok markus

2 files changed, 121 insertions, 117 deletions

diff --git a/ChangeLog b/ChangeLog
index ada3d3ae8..5ec6e615d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -4,6 +4,11 @@
      [ssh_config.5]
      - word change, agreed w/ markus
      - consistency fixes
+   - jmc@cvs.openbsd.org 2006/01/25 09:04:34
+     [sshd.8]
+     move the options description up the page, and a few additional tweaks
+     whilst in here;
+     ok markus
 
 20060129
  - (dtucker) [configure.ac opensshd.init.in] Bug #1144: Use /bin/sh for the
@@ -3729,4 +3734,4 @@
    - (djm) Trim deprecated options from INSTALL. Mention UsePAM
    - (djm) Fix quote handling in sftp; Patch from admorten AT umich.edu
 
-$Id: ChangeLog,v 1.4095 2006/01/31 10:39:03 djm Exp $
+$Id: ChangeLog,v 1.4096 2006/01/31 10:45:53 djm Exp $
diff --git a/sshd.8 b/sshd.8
index 241aefd43..3ca929d50 100644
--- a/sshd.8
+++ b/sshd.8
@@ -34,7 +34,7 @@
 .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 .\"
-.\" $OpenBSD: sshd.8,v 1.211 2006/01/12 22:20:00 jmc Exp $
+.\" $OpenBSD: sshd.8,v 1.212 2006/01/25 09:04:34 jmc Exp $
 .Dd September 25, 1999
 .Dt SSHD 8
 .Os
@@ -56,16 +56,14 @@
 .Ek
 .Sh DESCRIPTION
 .Nm
-(SSH Daemon) is the daemon program for
+(OpenSSH Daemon) is the daemon program for
 .Xr ssh 1 .
 Together these programs replace rlogin and rsh, and
 provide secure encrypted communications between two untrusted hosts
 over an insecure network.
-The programs are intended to be as easy to
-install and use as possible.
 .Pp
 .Nm
-is the daemon that listens for connections from clients.
+listens for connections from clients.
 It is normally started at boot from
 .Pa /etc/rc .
 It forks a new
@@ -73,122 +71,13 @@ daemon for each incoming connection.
 The forked daemons handle
 key exchange, encryption, authentication, command execution,
 and data exchange.
-This implementation of
-.Nm
-supports both SSH protocol version 1 and 2 simultaneously.
-.Nm
-works as follows:
-.Ss SSH protocol version 1
-Each host has a host-specific RSA key
-(normally 2048 bits) used to identify the host.
-Additionally, when
-the daemon starts, it generates a server RSA key (normally 768 bits).
-This key is normally regenerated every hour if it has been used, and
-is never stored on disk.
-.Pp
-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 generates 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 encryption algorithm
-to use from those offered by the server.
-.Pp
-Next, the server and the client enter an authentication dialog.
-The client tries to authenticate itself using
-.Em .rhosts
-authentication combined with RSA host
-authentication, RSA challenge-response authentication, or password
-based authentication.
-.Pp
-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
-.Cm DenyUsers
-or its group is listed in
-.Cm DenyGroups
-\&.  The definition of a locked account is system dependant. Some platforms
-have their own account database (eg AIX) and some modify the passwd field (
-.Ql \&*LK\&*
-on Solaris and UnixWare,
-.Ql \&*
-on HP-UX, containing
-.Ql Nologin
-on Tru64,
-a leading
-.Ql \&*LOCKED\&*
-on FreeBSD and a leading
-.Ql \&!!
-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 something other than these values (eg
-.Ql NP
-or
-.Ql \&*NP\&*
-).
-.Pp
-.Nm rshd ,
-.Nm rlogind ,
-and
-.Nm rexecd
-are disabled (thus completely disabling
-.Xr rlogin
-and
-.Xr rsh
-into the machine).
-.Ss SSH protocol version 2
-Version 2 works similarly:
-Each host has a host-specific key (RSA or DSA) used to identify the host.
-However, when the daemon starts, it does not generate a server key.
-Forward security is provided through a Diffie-Hellman key agreement.
-This key agreement results in a shared session key.
-.Pp
-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 cryptographic message authentication code
-(hmac-sha1 or hmac-md5).
-.Pp
-Protocol version 2 provides a public key based
-user (PubkeyAuthentication) or
-client host (HostbasedAuthentication) authentication method,
-conventional password authentication and challenge response based methods.
-.Ss 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 connections, or forwarding the authentication agent
-connection over the secure channel.
-.Pp
-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.
-.Pp
-When the user program terminates and all forwarded X11 and other
-connections have been closed, the server sends command exit status to
-the client, and both sides exit.
 .Pp
 .Nm
 can be configured using command-line options or a configuration file
 (by default
-.Xr sshd_config 5 ) .
-Command-line options override values specified in the
+.Xr sshd_config 5 ) ;
+command-line options override values specified in the
 configuration file.
-.Pp
 .Nm
 rereads its configuration file when it receives a hangup signal,
 .Dv SIGHUP ,
@@ -338,6 +227,116 @@ USER@HOST pattern in
 or
 .Cm DenyUsers .
 .El
+.Pp
+This implementation of
+.Nm
+supports both SSH protocol version 1 and 2 simultaneously.
+.Nm
+works as follows:
+.Ss SSH protocol version 1
+Each host has a host-specific RSA key
+(normally 2048 bits) used to identify the host.
+Additionally, when
+the daemon starts, it generates a server RSA key (normally 768 bits).
+This key is normally regenerated every hour if it has been used, and
+is never stored on disk.
+.Pp
+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 generates 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 encryption algorithm
+to use from those offered by the server.
+.Pp
+Next, the server and the client enter an authentication dialog.
+The client tries to authenticate itself using
+.Em rhosts
+authentication combined with RSA host
+authentication, RSA challenge-response authentication, or password
+based authentication.
+.Pp
+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
+.Cm DenyUsers
+or its group is listed in
+.Cm DenyGroups
+\&.  The definition of a locked account is system dependant. Some platforms
+have their own account database (eg AIX) and some modify the passwd field (
+.Ql \&*LK\&*
+on Solaris and UnixWare,
+.Ql \&*
+on HP-UX, containing
+.Ql Nologin
+on Tru64,
+a leading
+.Ql \&*LOCKED\&*
+on FreeBSD and a leading
+.Ql \&!!
+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 something other than these values (eg
+.Ql NP
+or
+.Ql \&*NP\&*
+).
+.Pp
+System security is not improved unless
+.Nm rshd ,
+.Nm rlogind ,
+and
+.Nm rexecd
+are disabled (thus completely disabling
+.Xr rlogin
+and
+.Xr rsh
+into the machine).
+.Ss SSH protocol version 2
+Version 2 works similarly:
+Each host has a host-specific key (RSA or DSA) used to identify the host.
+However, when the daemon starts, it does not generate a server key.
+Forward security is provided through a Diffie-Hellman key agreement.
+This key agreement results in a shared session key.
+.Pp
+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 cryptographic message authentication code
+(hmac-sha1 or hmac-md5).
+.Pp
+Protocol version 2 provides a public key based
+user (PubkeyAuthentication) or
+client host (HostbasedAuthentication) authentication method,
+conventional password authentication and challenge response based methods.
+.Ss 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 connections, or forwarding the authentication agent
+connection over the secure channel.
+.Pp
+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.
+.Pp
+When the user program terminates and all forwarded X11 and other
+connections have been closed, the server sends command exit status to
+the client, and both sides exit.
 .Sh CONFIGURATION FILE
 .Nm
 reads configuration data from