packages icon
 (OpenSSH Daemon) is the daemon program for Together these programs  replace
 rlogin  and  rsh,  and  provide secure encrypted communications between two
 untrusted hosts over an insecure network.   listens  for  connections  from
 clients.   It  is  normally  started at boot from It forks a new daemon for
 each  incoming  connection.   The  forked  daemons  handle  key   exchange,
 encryption,  authentication,  command execution, and data exchange.  can be
 configured using command-line options or a configuration file  (by  default
 command-line  options  override values specified in the configuration file.
 rereads its configuration  file  when  it  receives  a  hangup  signal,  by
 executing  itself  with  the name and options it was started with, e.g. The
 options are as follows: Forces to use IPv4 addresses only.  Forces  to  use
 IPv6  addresses  only.   Specify  the  connection parameters to use for the
 extended test mode.  If provided, any directives in the configuration  file
 that  would  apply  to  the  specified  user, host, and address will be set
 before the configuration is written to  standard  output.   The  connection
 parameters  are  supplied as keyword=value pairs.  The keywords are and All
 are required and may be supplied in any order, either with multiple options
 or  as  a  comma-separated list.  Specifies a path to a certificate file to
 identify during key exchange.  The certificate file must match a  host  key
 file  specified using the option or the configuration directive.  When this
 option is specified, will not detach and does not become  a  daemon.   This
 allows  easy  monitoring  of  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  options
 increase  the debugging level.  Maximum is 3.  Append debug logs to instead
 of the system log.  Write debug logs  to  standard  error  instead  of  the
 system  log.  Specifies the name of the configuration file.  The default is
 refuses to start if there is no configuration file.  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.  Specifies a
 file from which a host key is read.  This option must be given  if  is  not
 run  as  root  (as  the  normal host key files are normally not readable by
 anyone but root).  The default is and It is possible to have multiple  host
 key  files  for the different host key algorithms.  Specifies that is being
 run  from  Can  be  used  to  give  options  in  the  format  used  in  the
 configuration  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  Specifies  the  port  on  which the server listens for
 connections (default 22).  Multiple  port  options  are  permitted.   Ports
 specified  in  the  configuration  file  with the option are ignored when a
 command-line port is specified.  Ports specified using the option  override
 command-line  ports.   Quiet  mode.   Nothing  is  sent  to the system log.
 Normally the beginning, authentication, and termination of each  connection
 is  logged.   Extended  test mode.  Check the validity of the configuration
 file,  output  the  effective  configuration  to  stdout  and  then   exit.
 Optionally,  rules  may  be applied by specifying the connection parameters
 using one or more options.  Test mode.  Only  check  the  validity  of  the
 configuration  file  and  sanity  of the keys.  This is useful for updating
 reliably as configuration options may  change.   This  option  is  used  to
 specify  the  size of the field in the structure that holds the remote host
 name.  If the resolved host name is longer than the  dotted  decimal  value
 will  be  used  instead.   This allows hosts with very long host names that
 overflow this field to still be uniquely identified.  Specifying  indicates
 that  only  dotted decimal addresses should be put into the file.  may also
 be used to prevent from  making  DNS  requests  unless  the  authentication
 mechanism or configuration requires it.  Authentication mechanisms that may
 require DNS include and using  a  option  in  a  key  file.   Configuration
 options  that  require  DNS  include  using  a  USER@HOST pattern in 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 connects, the
 daemon responds with its public host key.  The client compares 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,
 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-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 password 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 or its
 group  is  listed  in  .   The  definition  of  a  locked account is system
 dependant. Some platforms have their own account database (eg AIX) and some
 modify  the passwd field ( on Solaris and UnixWare, on HP-UX, containing on
 Tru64, a leading 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 or ).  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 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.  When a user
 successfully logs in, does the following: If the login is on a tty, and  no
 command has been specified, prints last login time and (unless prevented in
 the configuration file or by see the section).  If the login is on  a  tty,
 records login time.  Checks if it exists, prints contents and quits (unless
 root).  Changes  to  run  with  normal  user  privileges.   Sets  up  basic
 environment.   Reads the file if it exists, and users are allowed to change
 their environment.  See the option in Changes to user's home directory.  If
 exists  and  the option is set, runs it; else if exists, runs it; otherwise
 runs xauth.  The files are given the X11 authentication protocol and cookie
 in standard input.  See below.  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 exists, runs it after reading the environment 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  in
 its  environment).   The  script  must  call  because  will  not  run xauth
 automatically to add X11 cookies.  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 && [  -n  "$DISPLAY"
 ];  then          if  [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                 # X11UseLocalhost=yes                 echo  add  unix:`echo
 $DISPLAY  |                       cut  -c11-`  $proto  $cookie         else
                 #  X11UseLocalhost=no                  echo  add   $DISPLAY
 $proto  $cookie          fi | xauth -q - fi If this file does not exist, is
 run, and if that does not exist either, xauth is used to  add  the  cookie.
 specifies  the  files containing public keys for public key authentication;
 if this option is not specified, the default is and 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-separated  fields:
 options,  keytype,  base64-encoded  key,  comment.   The  options  field is
 optional.  The keytype is or 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 or the file and edit it.  enforces a minimum RSA
 key modulus size of 768 bits.  The options (if present) consist  of  comma-
 separated  option  specifications.   No spaces are permitted, except within
 double quotes.  The following option  specifications  are  supported  (note
 that  option  keywords  are  case-insensitive): Enable authentication agent
 forwarding previously disabled by the option.  Specifies  that  the  listed
 key  is  a  certification authority (CA) that is trusted to validate signed
 certificates for  user  authentication.   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 specify 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 key option.  The  command  originally
 supplied by the client is available in the environment variable.  Note that
 this option applies to shell, command or subsystem  execution.   Also  note
 that  this  command  may  be  superseded  by  a 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 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 for more information on patterns.  In addition to the wildcard
 matching that may be applied to hostnames or addresses, a 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 option.  Prevents tty allocation (a request to
 allocate a pty will fail).  Disables execution of  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 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  options
 may  be  applied  separated by commas.  No pattern 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 On a line, specifies  allowed  principals  for  certificate
 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  option.   Permits  tty  allocation
 previously  disabled  by the option.  Enable all restrictions, i.e. disable
 port, agent and X11 forwarding, as well as  disabling  PTY  allocation  and
 execution   of   If  any  future  restriction  capabilities  are  added  to
 authorized_keys files they will be included in this set.  Force a device on
 the server.  Without this option, the next available device will be used if
 the client requests a tunnel.  Enables execution of previously disabled  by
 the  option.  Permits X11 forwarding previously disabled by the option.  An
 example authorized_keys file: # Comments allowed at start of  line  ssh-rsa
 from="*,!"   ssh-rsa   AAAAB2...19Q==   command="dump  /home",no-pty,no-port-forwarding  ssh-dss
 permitopen="",permitopen=""  ssh-dss AAAAB5...21S==
 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  and  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  automatically:  whenever the user
 connects to 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 to indicate that the line contains a  certification  authority  (CA)
 key,  or 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
 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  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 marker at the
 beginning of the key line, and are never accepted for authentication or  as
 certification  authorities,  but  instead  will produce a warning from when
 they are encountered.  It is 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, for
 example, and adding the host names at the front.  also  offers  some  basic
 automated  editing  for  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,  ssh-rsa  AAAA1234.....=  #  A  hashed  hostname
 |1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM=        ssh-rsa
 AAAA1234.....=  #  A revoked key @revoked * ssh-rsa AAAAB5W...  # A CA key,
 accepted for any host in * or  *  @cert-authority
 *,*  ssh-rsa  AAAAB5W...   This  file  is used to
 suppress printing the last login time and if and respectively, are enabled.
 It  does not suppress printing of the banner specified by This file is used
 for host-based authentication (see for more information).  On some machines
 this  file may need to be world-readable if the user's home directory is on
 an NFS partition, because 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
 but  allows  host-based  authentication  without  permitting   login   with
 rlogin/rsh.   This  directory is the default location for all user-specific
 configuration  and  authentication  information.   There  is   no   general
 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 sensitive, but the
 recommended permissions are read/write for the user, and not accessible  by
 others.   If  this  file,  the  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, will not allow it to be used unless the
 option has been set to 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
 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
 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 If no usable groups are  found  in  this  file  then
 fixed  internal  groups  will be used.  See If this file exists, 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 but
 allows  host-based authentication without permitting login with rlogin/rsh.
 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 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 convenience of the user so their contents can  be
 copied to known hosts files.  These files are created using Systemwide list
 of  known  host  keys.   This  file  should  be  prepared  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 The file format and  configuration  options
 are  described  in  Similar  to  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.  directory used by 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-
 writable.  Contains the process ID of the  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-readable.  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 contributed support for privilege separation.