sshd - secure shell daemon
sshd [-diqQ46] [-b bits] [-f config_file] [-g
login_grace_time] [-h host_key_file] [-k key_gen_time] [-p
port] [-V client_protocol_id]
The sshd (Secure Shell daemon) is the daemon program for
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.
sshd is the daemon that listens for connections from
clients. It forks a new daemon for each incoming connection.
The forked daemons handle key exchange, encryption, authen-
tication, command execution, and data exchange.
This implementation of sshd supports both SSH protocol ver-
sions 1 and 2 simultaneously. Because of security weaknesses
in the v1 protocol, sites should run only v2, if possible.
In the default configuration, only protocol v2 is enabled
for the server. To enable v1 and v2 simultaneously, see the
instructions in sshd_config(4).
Support for v1 is provided to help sites with existing ssh
v1 clients and servers to transition to v2. v1 might not be
supported in a future release.
SSH Protocol Version 1
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 responds with its pub-
lic 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.
Next, the server and the client enter an authentication dia-
log. 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(1M), rlogind(1M), rexecd(1M), and
rexd(1M) are disabled (thus completely disabling rlogin(1)
and rsh(1) into the machine).
SSH Protocol Version 2
Version 2 works similarly to version 1: Each host has a
host-specific DSA/RSA key. However, when the daemon starts,
it does not generate a server key. Forward security is pro-
vided 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 AES. The client selects the encryption
algorithm to use from those offered by the server. Addition-
ally, session integrity is provided through a cryptographic
message authentication code (hmac-sha1 or hmac-md5).
Protocol version 2 provides a public key based user authen-
tication method (PubKeyAuthentication) and conventional
Command Execution and Data Forwarding
If the client successfully authenticates itself, a dialog
for preparing the session is entered. At this time the
client can request things like allocating a pseudo-tty, for-
warding X11 connections, forwarding TCP/IP connections, or
forwarding the authentication agent connection over the
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 for-
warded to/from the shell or command on the server side, and
the user terminal on 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 the
configuration files /etc/ssh/ssh_config and ~/.ssh/config,
both described in ssh_config(4). Command-line options over-
ride values specified in the configuration file.
sshd rereads its configuration file when it receives a
hangup signal, SIGHUP.
Host Access Control
The sshd daemon uses TCP Wrappers to restrict access to
hosts. It uses the service name of sshd for hosts_access().
For more information on TCP Wrappers see tcpd(1M) and
hosts_access(3) man pages, which are part of the SUNWsfman
package (they are not SunOS man pages). TCP wrappers
binaries, including libwrap, are in SUNWtcpd, a required
package for SUNWsshdu, the package containing sshd.
The options for sshd are as follows:
Specifies the number of bits in the server key (the
default is 768).
-d Debug mode. The server sends verbose debug output to
the system log, and does not put itself in the back-
ground. The server also will not fork and will only
process one connection. This option is only intended
for debugging for the server. Multiple -d options
increase the debugging level. Maximum is 3.
Specifies the name of the configuration file. The
default is /etc/ssh/sshd_config. sshd refuses to start
if there is no configuration file.
Gives the grace time for clients to authenticate them-
selves (the default is 300 seconds). If the client
fails to authenticate the user within this number of
seconds, the server disconnects and exits. A value of
zero indicates no limit.
Specifies the file from which the host key is read
(the default is /etc/ssh/ssh_host_key). This option
must be given if sshd is not run as root (as the nor-
mal host file is normally not readable by anyone but
-i Specifies that sshd is being run from inetd. sshd is
normally not run from inetd because it needs to gen-
erate 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 (for exam-
ple, 512) using sshd from inetd may be reasonable.
Specifies how often the server key is regenerated (the
default is 3600 seconds, or one hour). The motivation
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 zero
indicates that the key will never be regenerated.
Specifies the port on which the server listens for
connections (the default is 22).
-q Quiet mode. Nothing is sent to the system log. Nor-
mally the beginning, authentication, and termination
of each connection is logged.
-4 Forces sshd to use IPv4 addresses only.
-6 Forces sshd to use IPv6 addresses only.
authorized_keys File Format
The $HOME/.ssh/authorized_keys file lists the public keys
that are permitted for RSA authentication. Each line of the
file contains one key (empty lines and lines starting with a
hash mark [#] 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).
Lines in this file are usually several hundred bytes long
(because of the size of the RSA key modulus). You will find
it very inconvenient to type them in; instead, copy the
identity.pub file and edit it.
Permissions of this file must be set so that it is not world
or group writable. See the StrickModes option of
The options (if present) consist of comma-separated option
specifications. No spaces are permitted, except within dou-
ble quotes. The following option specifications are sup-
Specifies that in addition to RSA authentication, the
canonical name of the remote host must be present in
the comma-separated list of patterns (* and ? serve as
wildcards). The list can 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: RSA authentication by itself does not trust
the network or name servers or anything (but the key);
however, if somebody somehow steals the key, the key
permits an intruder to log in from anywhere in the
world. This additional option makes using a stolen key
more difficult (name servers and/or routers would have
to be compromised in addition to just the key).
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 connection requests a pty; otherwise it
is run without a tty. A quote can be included in the
command by quoting it with a backslash. This option
might be useful to restrict certain RSA keys to per-
form only a specific operation. An example might be a
key that permits remote backups but nothing else. The
client might specify TCP/IP and/or X11 forwarding
unless they are explicitly prohibited.
Specifies that the string NAME=value 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.
Forbids TCP/IP forwarding when this key is used for
authentication. Any port forward requests by the
client will return an error. This might be used, for
example, in connection with the command option.
Forbids X11 forwarding when this key is used for
authentication. Any X11 forward requests by the client
will return an error.
Forbids authentication agent forwarding when this key
is used for authentication.
Prevents tty allocation (a request to allocate a pty
ssh_known_hosts File Format
The /etc/ssh/ssh_known_hosts and $HOME/.ssh/known_hosts
files contain host public keys for all known hosts. The glo-
bal file should be prepared by the administrator (optional),
and the per-user file is maintained automatically: 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 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 can 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 pat-
tern on the line.
Bits, exponent, and modulus are taken directly from the RSA
host key; they can be obtained, for example, from
/etc/ssh/ssh_host_rsa_key.pub. The optional comment field
continues to the end of the line, and is not used.
Lines starting with a hash mark (#) 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.
The lines in these files are typically hundreds of charac-
ters long.You should definitely not type in the host keys by
hand. Rather, generate them by a script or by taking
/etc/ssh/ssh_host_rsa_key.pub and adding the host names at
Example 1: authorized_key File Entries
The following are examples of authorized_key file entries.
1024 33 12121...312314325 firstname.lastname@example.org
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
Example 2: ssh_known_hosts File Entries
The following are examples of ssh_known_hosts file entries.
closenet,closenet.hut.fi,...,188.8.131.52 1024 37 159...93
The following exit values are returned:
0 Successful completion.
>0 An error occurred.
Contains configuration data for sshd. This file should
be writable by root only, but it is recommended
(though not necessary) that it be world-readable.
Contains the private part of the host key. This file
should only be owned by root, readable only by root,
and not accessible to others. sshd does not start if
this file is group/world-accessible.
Contains the public part of the host key. This file
should be world-readable but writable only by root.
Its contents should match the private part. This file
is not used for encryption; it is provided only for
the convenience of the user so its contents can be
copied to known hosts files. These two files are
created using ssh-keygen(1).
Contains the process ID of the sshd listening for con-
nections. If there are several daemons running con-
currently for different ports, this contains the pid
of the one started last. The content of this file is
not sensitive; it can be world-readable. You can use
the PidFile keyword in sshd_config to specify a file
other than /var/run/sshd.pid. See sshd_config(4).
/etc/ssh/ssh_known_hosts and $HOME/.ssh/known_hosts
These files are consulted when using rhosts with RSA
host 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 the remote host is the one it intended to con-
nect. These files should be writable only by root or
the owner. /etc/ssh/ssh_known_hosts should be world-
readable, and $HOME/.ssh/known_hosts can but need not
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.
This file contains host-username pairs, separated by a
space, one per line. The given user on the correspond-
ing host is permitted to log in without 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.
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.
This file is used during .rhosts authentication. In
its simplest form, this file contains host names, one
per line. Users on these hosts are permitted to log in
without a password, provided they have the same user
name on both machines. The host name can also be fol-
lowed by a user name; such users are permitted to log
in as any user on this machine (except root). Addi-
tionally, the syntax +@group can be used to specify
netgroups. Negated entries start with a hyphen (-).
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. Addi-
tionally, successful RSA host authentication is nor-
mally 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. For practical pur-
poses, using a user name grants the user root access.
Probably the only valid use for user names is in nega-
tive entries. This warning also applies to rsh/rlogin.
This file is processed exactly as /etc/hosts.equiv.
However, this file might be useful in environments
that want to run both rsh/rlogin and ssh.
This file is read into the environment at login (if it
exists). It can contain only 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.
If this file exists, it is run with /bin/sh after
reading the environment files but before starting the
user's shell or command. If X11 spoofing is in use,
this will receive the "proto cookie" pair in standard
input (and DISPLAY in environment). This must call
xauth(1) in that case.
The primary purpose of $HOME/.ssh/rc is to run any
initialization routines that might 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 -;
If this file does not exist, /etc/ssh/sshrc is run, and
if that does not exist, xauth is used to store the
cookie. $HOME/.ssh/rc should be writable only by the
user, and need not be readable by anyone else.
Similar to $HOME/.ssh/rc. This can be used to specify
machine-specific login-time initializations globally.
This file should be writable only by root, and should
See attributes(5) for descriptions of the following attri-
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
| Availability | SUNWsshdu |
scp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1),
sftp-server(1M), sshd(1M), sshd_config(4), attributes(5)
To view license terms, attribution, and copyright for
OpenSSH, the default path is
/var/sadm/pkg/SUNWsshdr/install/copyright. If the Solaris
operating environment has been installed anywhere other than
the default, modify the given path to access the file at the
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, added newer features and created Open SSH. Markus
Friedl contributed the support for SSH protocol versions 1.4
Man(1) output converted with