Go to main content

man pages section 1M: System Administration Commands

Exit Print View

Updated: July 2017

sshd.openssh (1m)


sshd.openssh - OpenSSH SSH daemon


sshd  [-46DdeiqTt]  [-C connection_spec] [-c host_certificate_file] [-E
log_file] [-f config_file] [-g login_grace_time] [-h host_key_file] [-o
option] [-p port] [-u len]


SSHD(8)                     System Manager's Manual                    SSHD(8)

       sshd - OpenSSH SSH daemon

       sshd  [-46DdeiqTt]  [-C connection_spec] [-c host_certificate_file] [-E
       log_file] [-f config_file] [-g login_grace_time] [-h host_key_file] [-o
       option] [-p port] [-u len]

       sshd (OpenSSH Daemon) is the daemon program for ssh(1).  Together these
       programs replace rlogin and rsh, and provide secure encrypted  communi-
       cations between two untrusted hosts over an insecure network.

       sshd  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 can be configured using command-line options  or  a  configuration
       file (by default sshd_config(4)) ; command-line options override values
       specified in the configuration file.  sshd  rereads  its  configuration
       file when it receives a hangup signal, SIGHUP, by executing itself with
       the name and options it was started with, e.g. /usr/sbin/sshd.

       If sshd links with FIPS-capable OpenSSL, sshd runs  in  FIPS-140  mode.
       In  FIPS-140  mode non-FIPS approved ciphers, MACs and digests are dis-

       The options are as follows:

       -4     Forces sshd to use IPv4 addresses only.

       -6     Forces sshd to use IPv6 addresses only.

       -C connection_spec
              Specify the connection parameters to use  for  the  -T  extended
              test  mode.  If provided, any Match directives in the configura-
              tion file that would apply to  the  specified  user,  host,  and
              address will be set before the configuration is written to stan-
              dard output.  The connection parameters  are  supplied  as  key-
              word=value   pairs.    The   keywords  are  ``user'',  ``host'',
              ``laddr'', ``lport'', and ``addr''.  All are required and may be
              supplied  in  any order, either with multiple -C options or as a
              comma-separated list.

       -c host_certificate_file
              Specifies a path to a certificate file to identify  sshd  during
              key  exchange.   The certificate file must match a host key file
              specified using the  -h  option  or  the  HostKey  configuration

       -D     When this option is specified, sshd will not detach and does not
              become a daemon.  This allows easy monitoring of sshd.

       -d     Debug mode.  The server sends verbose debug output  to  standard
              error,  and  does  not put itself in the background.  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.

       -E log_file
              Append debug logs to log_file instead of the system log.

       -e     Write debug logs to standard error instead of the system log.

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

       -g login_grace_time
              Gives the grace time  for  clients  to  authenticate  themselves
              (default  120 seconds).  If the client fails to authenticate the
              user within this many seconds, the server disconnects and exits.
              A value of zero indicates no limit.

       -h host_key_file
              Specifies  a  file  from  which a host key is read.  This option
              must be given if sshd is not run as root (as the normal host key
              files  are  normally  not  readable  by  anyone  but root).  The
              default              is               /etc/ssh/ssh_host_dsa_key,
              /etc/ssh/ssh_host_ecdsa_key,  /etc/ssh/ssh_host_ed25519_key  and
              /etc/ssh/ssh_host_rsa_key.  It is possible to have multiple host
              key files for the different host key algorithms.

       -i     Specifies that sshd is being run from inetd(8).

       -o option
              Can be used to give options in the format used in the configura-
              tion file.  This is useful  for  specifying  options  for  which
              there is no separate command-line flag.  For full details of the
              options, and their values, see sshd_config(4).

       -p port
              Specifies the port on which the server listens  for  connections
              (default 22).  Multiple port options are permitted.  Ports spec-
              ified in the configuration file with the Port option are ignored
              when  a  command-line  port is specified.  Ports specified using
              the ListenAddress option override command-line ports.

       -q     Quiet mode.  Nothing is sent to the system  log.   Normally  the
              beginning, authentication, and termination of each connection is

       -T     Extended test mode.  Check the  validity  of  the  configuration
              file,  output  the  effective  configuration  to stdout and then
              exit.  Optionally, Match rules may be applied by specifying  the
              connection parameters using one or more -C options.

       -t     Test  mode.   Only  check the validity of the configuration file
              and sanity of the keys.  This is useful for updating sshd  reli-
              ably as configuration options may change.

       -u len This option is used to specify the size of the field in the utmp
              structure that holds the remote host name.  If the resolved host
              name  is  longer than len, the dotted decimal value will be used
              instead.  This allows hosts with very long host names that over-
              flow this field to still be uniquely identified.  Specifying -u0
              indicates that only dotted decimal addresses should be put  into
              the utmp file.  -u0 may also be used to prevent sshd from making
              DNS requests unless the authentication mechanism  or  configura-
              tion  requires  it.   Authentication mechanisms that may require
              DNS include HostbasedAuthentication and using  a  from="pattern-
              list"  option in a key file.  Configuration options that require
              DNS  include  using  a  USER@HOST  pattern  in   AllowUsers   or

       The  OpenSSH  SSH daemon supports SSH protocol 2 only.  Each host has a
       host-specific key, used to identify the host.  Whenever a  client  con-
       nects,  the  daemon responds with its public host key.  The client com-
       pares the host key against its own database to verify that it  has  not
       changed.   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
       128-bit AES, Blowfish, 3DES, 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-md5,  hmac-sha1,
       umac-64, umac-128, hmac-ripemd160, hmac-sha2-256 or hmac-sha2-512).

       Finally, the server and the client enter an authentication dialog.  The
       client  tries  to  authenticate itself using host-based authentication,
       public key authentication, challenge-response authentication, or  pass-
       word authentication.

       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 DenyUsers or its group is listed in DenyGroups .  The defini-
       tion of a locked account is system dependant. Some platforms have their
       own account database (eg AIX) and some modify the passwd field ( `*LK*'
       on Solaris and UnixWare, `*' on HP-UX, containing `Nologin' on Tru64, a
       leading  `*LOCKED*' on FreeBSD and a leading `!'  on most Linuxes).  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 `NP' or `*NP*' ).

       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.

       After this, the client either requests a shell or execution of  a  com-
       mand.   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

       When the user program terminates and all forwarded X11 and  other  con-
       nections  have been closed, the server sends command exit status to the
       client, and both sides exit.

       When a user successfully logs in, sshd does the following:

       1.     If the login is on a tty, and no  command  has  been  specified,
              prints  last  login  time and /etc/motd (unless prevented in the
              configuration file or by ~/.hushlogin; see the FILES section).

       2.     If the login is on a tty, records login time.

       3.     Checks /etc/nologin; if it exists,  prints  contents  and  quits
              (unless root).

       4.     Changes to run with normal user privileges.

       5.     Sets up basic environment.

       6.     Reads  the  file ~/.ssh/environment, if it exists, and users are
              allowed to change their environment.  See the PermitUserEnviron-
              ment option in sshd_config(4).

       7.     Changes to user's home directory.

       8.     If  ~/.ssh/rc  exists and the sshd_config(4) PermitUserRC option
              is set, runs it; else if /etc/ssh/sshrc exists, runs it;  other-
              wise runs xauth.  The ``rc'' files are given the X11 authentica-
              tion protocol and cookie in standard input.  See SSHRC , below.

       9.     Runs user's shell or command.  All commands are  run  under  the
              user's login shell as specified in the system password database.

       If  the file ~/.ssh/rc exists, sh(1) runs it after reading the environ-
       ment files but before starting the user's shell or  command.   It  must
       not  produce any output on stdout; stderr must be used instead.  If X11
       forwarding is in use, it will receive the "proto cookie"  pair  in  its
       standard  input (and DISPLAY in its environment).  The script must call
       xauth(1) because sshd will not run xauth automatically to add X11 cook-

       The  primary purpose of this file is to run any initialization routines
       which may be needed before the user's home directory  becomes  accessi-
       ble; 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 && [ -n "$DISPLAY" ]; then
            if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                 # X11UseLocalhost=yes
                 echo add unix:`echo $DISPLAY |
                     cut -c11-` $proto $cookie
                 # X11UseLocalhost=no
                 echo add $DISPLAY $proto $cookie
            fi | xauth -q -

       If this file does not exist, /etc/ssh/sshrc is run, and  if  that  does
       not exist either, xauth is used to add the cookie.

       AuthorizedKeysFile  specifies the files containing public keys for pub-
       lic key authentication; if this option is not specified, the default is
       ~/.ssh/authorized_keys  and  ~/.ssh/authorized_keys2.  Each line of the
       file contains one key (empty lines and lines starting with  a  `#'  are
       ignored as comments).  Public keys consist of the following space-sepa-
       rated fields:  options,  keytype,  base64-encoded  key,  comment.   The
       options  field  is  optional.   The keytype is ``ecdsa-sha2-nistp256'',
       ``ecdsa-sha2-nistp384'',   ``ecdsa-sha2-nistp521'',    ``ssh-ed25519'',
       ``ssh-dss'' or ``ssh-rsa ;'' 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 can be several hundred bytes long (because
       of  the  size of the public key encoding) up to a limit of 8 kilobytes,
       which permits DSA keys up to 8 kilobits and RSA keys up to 16 kilobits.
       You  don't  want  to  type  them  in;  instead,  copy  the  id_dsa.pub,
       id_ecdsa.pub, id_ed25519.pub, or the id_rsa.pub file and edit it.

       sshd enforces a minimum RSA key modulus size of 768 bits.

       The options (if present) consist of comma-separated  option  specifica-
       tions.  No spaces are permitted, except within double quotes.  The fol-
       lowing option specifications are supported (note that  option  keywords
       are case-insensitive):

              Enable  authentication  agent  forwarding previously disabled by
              the restrict option.

              Specifies that the listed key is a certification authority  (CA)
              that is trusted to validate signed certificates for user authen-

              Certificates may encode access restrictions similar to these key
              options.   If  both certificate restrictions and key options are
              present, the most restrictive union of the two is applied.

              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 client  requests
              a  pty;  otherwise  it  is run without a tty.  If an 8-bit clean
              channel is required, one must not request a pty or should  spec-
              ify  no-pty.   A quote may be included in the command by quoting
              it with a backslash.

              This option might be useful to restrict certain public  keys  to
              perform  just  a  specific operation.  An example might be a key
              that permits remote backups but nothing  else.   Note  that  the
              client  may  specify  TCP  and/or X11 forwarding unless they are
              explicitly prohibited, e.g. using the restrict key option.

              The command originally supplied by the client  is  available  in
              the  SSH_ORIGINAL_COMMAND  environment variable.  Note that this
              option applies to shell, command or subsystem  execution.   Also
              note  that  this  command  may be superseded by a sshd_config(4)
              ForceCommand directive.

              If a command is specified and a forced-command is embedded in  a
              certificate  used  for authentication, then the certificate will
              be accepted only if the two commands are identical.

              Specifies that the string 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.  Environment processing is disabled by
              default and is controlled via the PermitUserEnvironment option.

              Specifies that in addition to public key authentication,  either
              the  canonical name of the remote host or its IP address must be
              present in the comma-separated list of patterns.   See  PATTERNS
              in ssh_config(4) for more information on patterns.

              In  addition  to  the  wildcard  matching that may be applied to
              hostnames or addresses, a from stanza  may  match  IP  addresses
              using CIDR address/masklen notation.

              The  purpose  of this option is to optionally increase security:
              public key 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).

              Forbids  authentication  agent  forwarding when this key is used
              for authentication.

              Forbids TCP forwarding when this key is used for authentication.
              Any  port  forward  requests by the client will return an error.
              This might be used, e.g. in connection with the command option.

       no-pty Prevents tty allocation (a request to allocate a pty will fail).

              Disables execution of ~/.ssh/rc.

              Forbids X11 forwarding when this key is used for authentication.
              Any X11 forward requests by the client will return an error.

              Limit local port forwarding with ssh(1) -L such that it may only
              connect to the specified host and port.  IPv6 addresses  can  be
              specified by enclosing the address in square brackets.  Multiple
              permitopen options may be applied separated by commas.  No  pat-
              tern matching is performed on the specified hostnames, they must
              be literal domains or addresses.   A  port  specification  of  *
              matches any port.

              Enable port forwarding previously disabled by the restrict

              On  a cert-authority line, specifies allowed principals for cer-
              tificate authentication as a comma-separated list.  At least one
              name  from  the  list  must  appear in the certificate's list of
              principals for the certificate to be accepted.  This  option  is
              ignored  for  keys  that  are  not marked as trusted certificate
              signers using the cert-authority option.

       pty    Permits tty  allocation  previously  disabled  by  the  restrict

              Enable  all  restrictions, i.e. disable port, agent and X11 for-
              warding, as well as disabling PTY allocation  and  execution  of
              ~/.ssh/rc.   If any future restriction capabilities are added to
              authorized_keys files they will be included in this set.

              Force a tun(4) device on the server.  Without this  option,  the
              next available device will be used if the client requests a tun-

              Enables  execution  of  ~/.ssh/rc  previously  disabled  by  the
              restrict option.

              Permits  X11  forwarding  previously  disabled  by  the restrict

       An example authorized_keys file:

       # Comments allowed at start of line
       ssh-rsa AAAAB3Nza...LiPk== user@example.net
       from="*.sales.example.net,!pc.sales.example.net" ssh-rsa
       AAAAB2...19Q== john@example.net
       command="dump /home",no-pty,no-port-forwarding ssh-dss
       AAAAC3...51R== example.net
       permitopen="",permitopen="" ssh-dss
       tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...==
       restrict,command="uptime" ssh-rsa AAAA1C8...32Tv==
       restrict,pty,command="nethack" ssh-rsa AAAA1f8...IrrC5==

       The /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts files contain  host
       public keys for all known hosts.  The global file should be prepared by
       the administrator (optional), and the per-user file is maintained auto-
       matically:  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:  markers
       (optional),  hostnames,  keytype,  base64-encoded  key,  comment.   The
       fields are separated by spaces.

       The marker is optional, but if it is present then it  must  be  one  of
       ``@cert-authority'', to indicate that the line contains a certification
       authority (CA) key, or ``@revoked'', to indicate that the key contained
       on  the line is revoked and must not ever be accepted.  Only one marker
       should be used on a key line.

       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.  A hostname or address may optionally be enclosed within `['  and
       `]' brackets then followed by `:' and a non-standard port number.

       Alternately,  hostnames may be stored in a hashed form which hides host
       names and addresses should the file's contents  be  disclosed.   Hashed
       hostnames  start  with  a  `|' character.  Only one hashed hostname may
       appear on a single line and none of  the  above  negation  or  wildcard
       operators may be applied.

       The  keytype  and  base64-encoded  key are taken directly from the 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 `#' and empty lines are ignored as comments.

       When performing host authentication, authentication is accepted if  any
       matching  line  has the proper key; either one that matches exactly or,
       if the server has presented a certificate for authentication,  the  key
       of  the certification authority that signed the certificate.  For a key
       to be trusted as a certification authority, it must  use  the  ``@cert-
       authority'' marker described above.

       The  known hosts file also provides a facility to mark keys as revoked,
       for example when it is known that the associated private key  has  been
       stolen.   Revoked  keys  are  specified  by  including the ``@revoked''
       marker at the beginning of the key line, and  are  never  accepted  for
       authentication  or  as certification authorities, but instead will pro-
       duce a warning from ssh(1) when they are encountered.

       It is permissible (but not recommended) to have several lines  or  dif-
       ferent  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; authen-
       tication is accepted if valid information  can  be  found  from  either

       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, ssh-keyscan(1) or by taking, for
       example, /etc/ssh/ssh_host_rsa_key.pub and adding the host names at the
       front.   ssh-keygen(1)  also  offers  some  basic automated editing for
       ~/.ssh/known_hosts including removing hosts matching a  host  name  and
       converting all host names to their hashed representations.

       An example ssh_known_hosts file:

       # Comments allowed at start of line
       closenet,..., 1024 37 159...93 closenet.example.net
       cvs.example.net, ssh-rsa AAAA1234.....=
       # A hashed hostname
       |1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
       # A revoked key
       @revoked * ssh-rsa AAAAB5W...
       # A CA key, accepted for any host in *.mydomain.com or *.mydomain.org
       @cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W...

              This  file  is used to suppress printing the last login time and
              /etc/motd, if  PrintLastLog  and  PrintMotd,  respectively,  are
              enabled.   It does not suppress printing of the banner specified
              by Banner.

              This file is used for host-based authentication (see ssh(1)  for
              more  information).   On  some machines this file may need to be
              world-readable if the user's home directory is on an NFS  parti-
              tion,  because  sshd  reads it as root.  Additionally, this file
              must be owned by the user, and must not have  write  permissions
              for  anyone  else.  The recommended permission for most machines
              is read/write for the user, and not accessible by others.

              This file is used in exactly the same way as .rhosts, but allows
              host-based   authentication   without   permitting   login  with

              This directory is the default  location  for  all  user-specific
              configuration  and authentication information.  There is no gen-
              eral requirement to keep the entire contents of  this  directory
              secret,  but  the recommended permissions are read/write/execute
              for the user, and not accessible by others.

              Lists the public keys (DSA, ECDSA, Ed25519,  RSA)  that  can  be
              used  for  logging  in as this user.  The format of this file is
              described above.  The content of the file is not  highly  sensi-
              tive,  but  the  recommended  permissions are read/write for the
              user, and not accessible by others.

              If this file, the ~/.ssh directory, or the user's home directory
              are  writable by other users, then the file could be modified or
              replaced by unauthorized users.  In this  case,  sshd  will  not
              allow  it  to be used unless the StrictModes option has been set
              to ``no''.

              This file is read into the environment at login (if it  exists).
              It  can only contain 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.  Environment processing is disabled by default  and
              is controlled via the PermitUserEnvironment option.

              Contains  a  list of host keys for all hosts the user has logged
              into that are not already in the systemwide list of  known  host
              keys.   The  format  of this file is described above.  This file
              should be writable only by root/the owner and can, but need  not
              be, world-readable.

              Contains  initialization  routines  to  be run before the user's
              home directory becomes accessible.  This file should be writable
              only by the user, and need not be readable by anyone else.

              This  file  is  for host-based authentication (see ssh(1)) .  It
              should only be writable by root.

              Contains Diffie-Hellman  groups  used  for  the  "Diffie-Hellman
              Group  Exchange"  key  exchange  method.   The  file  format  is
              described in moduli(4).  If no usable groups are found  in  this
              file then fixed internal groups will be used.

              See motd(5).

              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 is used in exactly the same way  as  hosts.equiv,  but
              allows  host-based  authentication without permitting login with




              These files contain the private parts of the host  keys.   These
              files  should  only be owned by root, readable only by root, and
              not accessible to others.  Note that  sshd  does  not  start  if
              these files are group/world-accessible.




              These  files  contain  the public parts of the host keys.  These
              files should be world-readable but writable only by root.  Their
              contents should match the respective private parts.  These files
              are not really used for anything; they are provided for the con-
              venience  of  the  user so their contents can be copied to known
              hosts files.  These files are created using ssh-keygen(1).

              Systemwide list of known host keys.  This file  should  be  pre-
              pared  by  the  system  administrator to contain the public host
              keys of all machines in the organization.  The  format  of  this
              file  is  described above.  This file should be writable only by
              root/the owner and should be world-readable.

              Contains configuration data for sshd.  The file format and  con-
              figuration options are described in sshd_config(4).

              Similar to ~/.ssh/rc, it can be used to specify machine-specific
              login-time  initializations  globally.   This  file  should   be
              writable only by root, and should be world-readable.

              chroot(2)  directory used by sshd during privilege separation in
              the pre-authentication phase.  The directory should not  contain
              any  files  and  must  be  owned by root and not group or world-

              Contains the process ID of the sshd  listening  for  connections
              (if there are several daemons running concurrently for different
              ports, this contains the process ID of the  one  started  last).
              The content of this file is not sensitive; it can be world-read-

       sshd uses pam(3PAM) for password and  keyboard-interactive  methods  as
       well  as  for  account management, session management, and the password
       management for all authentication methods.

       Each SSHv2 userauth type has its own PAM service name:

       | SSHv2 Userauth       | PAM Service Name     |
       | none                 | sshd-none            |
       | password             | sshd-password        |
       | keyboard-interactive | sshd-kbdint          |
       | pubkey               | sshd-pubkey          |
       | hostbased            | sshd-hostbased       |
       | gssapi-with-mic      | sshd-gssapi          |

       See attributes(5) for descriptions of the following attributes:

       |Availability   | network/openssh          |
       |Stability      | Pass-through uncommitted |
       scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1),  ssh-
       keyscan(1),   chroot(2),   login.conf(5),   moduli(4),  sshd_config(4),
       inetd(8), sftp-server(1M)

       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, re-added  newer  features
       and  created  OpenSSH.   Markus  Friedl contributed the support for SSH
       protocol versions 1.5 and 2.0.  Niels Provos and Markus Friedl contrib-
       uted support for privilege separation.

       This     software     was    built    from    source    available    at
       https://java.net/projects/solaris-userland.   The  original   community
       source    was   downloaded   from    http://mirrors.sonic.net/pub/Open-

       Further information about this software can be found on the open source
       community website at http://www.openssh.org/.

                               November 30 2016                        SSHD(8)