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
     password authentication.

  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
     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 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:

     -b bits
           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.

     -f configuration_file
           Specifies the name  of  the  configuration  file.  The
           default is /etc/ssh/sshd_config. sshd refuses to start
           if there is no configuration file.

     -g login_grace_time
           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.

     -h host_key_file
           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.

     -k key_gen_time
           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.

     -p port
           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 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
           will fail).

  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/ 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/  and  adding the host names at
     the front.


     Example 1: authorized_key File Entries

     The following are examples of authorized_key file entries.

     1024 33 12121...312314325

     from="*,!" 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,,..., 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/ 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
           be world-readable.

           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
           be world-readable.


     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
     installed location.


     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
     and 2.0.

Man(1) output converted with man2html