| SSHD(8) | System Manager's Manual | SSHD(8) |
sshd —
sshd |
[-diqQ] [-b
bits] [-f
config_file] [-g
login_grace_time] [-h
host_key_file] [-k
key_gen_time] [-p
port] [-V
client_protocol_id] |
sshd (Secure Shell Daemon) is the daemon program for
ssh(1). Together these programs replace rlogin and rsh
programs, 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.
sshd is the daemon that 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, command execution, and data exchange.
sshd works as follows. 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.
Whenever a client connects the daemon, the daemon sends its host and server public keys to the client. The client compares the 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 start to 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 and 3DES, with 3DES being is used by default. The client selects the encryption algorithm to use from those offered by the server.
Next, the server and the client enter an authentication dialog. The client tries to authenticate itself using .rhosts authentication, .rhosts authentication combined with RSA host authentication, RSA challenge-response authentication, or password based authentication.
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 rshd(8), rlogind(8), rexecd(8), and rexd(8) are disabled (thus completely disabling rlogin(1) and rsh(1) into that machine).
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.
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 connections have been closed, the server sends command exit status to the client, and both sides exit.
sshd can be configured using command-line
options or a configuration file. Command-line options override values
specified in the configuration file.
sshd rereads its configuration file when
it receives a hangup signal, SIGHUP.
The options are as follows:
-b
bits-d-f
configuration_filesshd
refuses to start if there is no configuration file.-g
login_grace_time-h
host_key_filesshd is not run as root (as the normal host
file is normally not readable by anyone but root).-isshd is being run from inetd.
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 regenerated every time. However, with small key sizes (e.g. 512)
using sshd from inetd may be feasible.-k
key_gen_time-p
port-q-Q-V
client_protocol_idsshd assumes the client has sent the given version
string and skips the Protocol Version Identification Exchange.sshd reads configuration data from
/etc/ssh/sshd_config (or the file specified with
-f on the command line). The file contains
keyword-value pairs, one per line. Lines starting with
‘#’ and empty lines are interpreted as
comments.
The following keywords are possible.
AFSTokenPassingAllowGroups*’ and
‘AllowUsers*’ and
‘CheckMailsshd should check for new mail
for interactive logins. The default is “no”.DenyGroups*’ and
‘DenyUsers*’ and
‘HostKeysshd does not start if this file is
group/world-accessible.IgnoreRhostsIgnoreUserKnownHostssshd should ignore the user's
$HOME/.ssh/known_hosts during
RhostsRSAAuthentication. The default is
“no”.KeepAliveThe default is “yes” (to send keepalives), and the server will notice if the network goes down or the client host reboots. This avoids infinitely hanging sessions.
To disable keepalives, the value should be set to “no” in both the server and the client configuration files.
KerberosAuthenticationPasswordAuthentication is yes, the password
provided by the user will be validated through the Kerberos KDC. Default
is “yes”.KerberosOrLocalPasswdKerberosTgtPassingKerberosTicketCleanupKeyRegenerationIntervalListenAddresssshd should listen
on. The default is to listen to all local addresses.LoginGraceTimeLogLevelsshd. The possible values are: QUIET, FATAL,
ERROR, INFO, VERBOSE and DEBUG. The default is INFO. Logging with level
DEBUG violates the privacy of users and is not recommended.PasswordAuthenticationPermitEmptyPasswordsPermitRootLoginRoot login with RSA authentication when the command option has been specified will be allowed regardless of the value of this setting (which may be useful for taking remote backups even if root login is normally not allowed).
Portsshd listens on.
The default is 22.PrintMotdsshd should print
/etc/motd when a user logs in interactively. (On
some systems it is also printed by the shell,
/etc/profile, or equivalent.) The default is
“yes”.RandomSeedRhostsAuthenticationRhostsRSAAuthentication should be used
instead, because it performs RSA-based host authentication in addition to
normal rhosts or /etc/hosts.equiv authentication. The default is
“no”.RhostsRSAAuthenticationRSAAuthenticationServerKeyBitsSkeyAuthenticationPasswordAuthentication is allowed,
too.StrictModessshd should check file modes and
ownership of the user's files and home directory before accepting login.
This is normally desirable because novices sometimes accidentally leave
their directory or files world-writable. The default is
“yes”.SyslogFacilitysshd. The possible values are: DAEMON, USER, AUTH,
LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The
default is AUTH.UseLoginX11ForwardingX11DisplayOffsetsshd's X11 forwarding. This prevents
sshd from interfering with real X11 servers.sshd does the
following:
#’ are ignored as comments). Each line
consists of the following fields, separated by spaces: options, bits,
exponent, modulus, comment. The options field is optional; its presence is
determined by whether the line starts with a number or not (the option field
never starts with a number). The bits, exponent, modulus and comment fields
give the RSA key; the comment field is not used for anything (but may be
convenient for the user to identify the key).
Note that lines in this file are usually several hundred bytes long (because of the size of the RSA key modulus). You don't want to type them in; instead, copy the identity.pub file and edit it.
The options (if present) consists of comma-separated option specifications. No spaces are permitted, except within double quotes. The following option specifications are supported:
from="pattern-list"command="command"environment="NAME=value"no-port-forwardingcommand
option.no-X11-forwardingno-agent-forwardingno-ptyfrom="*.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 backup.hut.fi
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 wildcards); 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 indicate negation: if the host
name matches a negated pattern, it is not accepted (by that line) even if it
matched another pattern on the line.
Bits, exponent, and modulus are taken directly from the 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 recommended) 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 conflicting 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.
sshd. This file
should be writable by root only, but it is recommended (though not
necessary) that it be world-readable.sshd does not start if this file is
group/world-accessible.sshd listening for
connections (if there are several daemons running concurrently for
different ports, this contains the pid of the one started last). The
contents of this file are not sensitive; it can be world-readable.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.If 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.
-’.
If the client host/user is successfully matched in this file, login is automatically permitted provided the client and server user names are the same. Additionally, successful RSA host authentication is normally 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 user 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.
#’), 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.DISPLAY in environment). This must call
xauth(1) in that case.
The primary purpose of this file is to run any initialization routines which may be needed before the user's home directory becomes accessible; AFS is a particular example of such an environment.
This file will probably contain some initialization code followed by something similar to: "if read proto cookie; then echo add $DISPLAY $proto $cookie | 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 store the cookie.
This file should be writable only by the user, and need not be readable by anyone else.
Information about new releases, mailing lists, and other related issues can be found from the SSH WWW home page:
http://www.cs.hut.fi/ssh.OpenSSH is a derivative of the original (free) ssh 1.2.12 release, but with bugs removed and newer features re-added. Rapidly after the 1.2.12 release, newer versions bore successively more restrictive licenses. This version of OpenSSH
The libraries described in ssl(8) are required for proper operation.
| September 25, 1999 | BSD |