- 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
This commit is contained in:
Damien Miller
parent
ddfddf1ba3
commit
99cc4a8f1e
|
|
@ -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 $
|
||||
|
|
|
|||
231
sshd.8
231
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
|
||||
|
|
|
|||
Loading…
Reference in New Issue