-This implementation of
-.Nm
-supports both SSH protocol version 1 and 2 simultaneously.
-.Nm
-works as follows.
-.Pp
-.Ss SSH protocol version 1
-.Pp
-Each host has a host-specific RSA key
-(normally 1024 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
-.Pa .rhosts
-authentication,
-.Pa .rhosts
-authentication combined with RSA host
-authentication, RSA challenge-response authentication, or password
-based authentication.
-.Pp
-Rhosts authentication is normally disabled
-because it is fundamentally insecure, but can be enabled in the server
-configuration file if desired.
-System security is not improved unless
-.Xr rshd 8 ,
-.Xr rlogind 8 ,
-.Xr rexecd 8 ,
-and
-.Xr rexd 8
-are disabled (thus completely disabling
-.Xr rlogin 1
-and
-.Xr rsh 1
-into the machine).
-.Pp
-.Ss SSH protocol version 2
-.Pp
-Version 2 works similarly:
-Each host has a host-specific DSA key 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.
-The rest of the session is encrypted
-using a symmetric cipher, currently
-Blowfish, 3DES or CAST128 in CBC mode or Arcfour.
-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 authentication method (DSAAuthentication)
-and conventional password authentication.
-.Pp
-.Ss Command execution and data forwarding
-.Pp
-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/IP 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.