*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->OpenBSD man pages -> sshd (8)              



NAME    [Toc]    [Back]

     sshd - OpenSSH SSH daemon

SYNOPSIS    [Toc]    [Back]

     sshd   [-46Ddeiqt]   [-b   bits]   [-f   config_file]    [-g
          [-h  host_key_file]  [-k  key_gen_time] [-o option] [-p
port] [-u len]

DESCRIPTION    [Toc]    [Back]

     sshd (SSH Daemon) is the daemon program for ssh(1).  Together these programs
  replace  rlogin and rsh, and provide secure encrypted
     between two untrusted hosts over an insecure  network.   The
programs are
     intended to be as easy to install and use as possible.

     sshd  is  the  daemon  that  listens  for  connections  from
clients.  It is normally
 started at boot from /etc/rc.  It forks a  new  daemon
for each incoming
  connection.  The forked daemons handle key exchange,
     authentication, command execution, and data exchange.   This
  of sshd supports both SSH protocol version 1 and 2 simultaneously.
     sshd works as follows:

   SSH protocol version 1    [Toc]    [Back]
     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
public 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 dialog.  The
     client tries to authenticate itself using rhosts authentication combined
     with RSA host authentication, RSA challenge-response authentication, or
     password based authentication.

     System  security  is  not improved unless rshd, rlogind, and
rexecd are disabled
 (thus completely disabling rlogin and rsh into the machine).

   SSH protocol version 2    [Toc]    [Back]
     Version 2 works similarly: Each host has a host-specific key
(RSA or DSA)
     used to identify the host.  However, when the daemon starts,
it does not
     generate a server key.  Forward security is provided through
a DiffieHellman
 key agreement.  This  key  agreement  results  in  a
shared session

     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-sha1 or

     Protocol version 2 provides a public key  based  user  (PubkeyAuthentication)
  or  client host (HostbasedAuthentication) authentication method,
     conventional password authentication and challenge  response
based methods.

   Command execution and data forwarding    [Toc]    [Back]
     If  the  client  successfully authenticates itself, a dialog
for preparing
     the session is entered.  At this time the client may request
things like
     allocating  a  pseudo-tty,  forwarding X11 connections, forwarding TCP/IP
     connections, or forwarding the authentication agent  connection over the
     secure channel.

     Finally,  the client either requests a shell or execution of
a command.
     The sides then enter session mode.   In  this  mode,  either
side may send
     data  at  any  time,  and such data is forwarded to/from the
shell or command
     on the server side, and the  user  terminal  in  the  client

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

     sshd  can be configured using command-line options or a configuration file
     (by default sshd_config(5)).  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
     with, e.g., /usr/sbin/sshd.

     The options are as follows:

     -4      Forces sshd to use IPv4 addresses only.

     -6      Forces sshd to use IPv6 addresses only.

     -b bits
             Specifies the number of bits in the ephemeral protocol version 1
             server key (default 768).

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

     -d      Debug mode.  The server sends verbose  debug  output
to the system
             log, 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      When this option is specified, sshd  will  send  the
output to the
             standard error instead of the system log.

     -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

     -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_key for protocol version 1, and
             /etc/ssh/ssh_host_rsa_key                        and
/etc/ssh/ssh_host_dsa_key for protocol
 version 2.  It is possible  to  have  multiple
host key files
             for the different protocol versions and host key algorithms.

     -i      Specifies that sshd  is  being  run  from  inetd(8).
sshd is normally
             not  run from inetd because it needs to generate the
server key
             before it can respond to the client,  and  this  may
take tens of
             seconds.  Clients would have to wait too long if the
key was regenerated
 every time.  However, with small key sizes
(e.g., 512)
             using sshd from inetd may be feasible.

     -k key_gen_time
             Specifies how often the ephemeral protocol version 1
server key
             is regenerated (default 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.

     -o option
             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 sshd_config(5).

     -p port
             Specifies  the  port on which the server listens for
             (default 22).  Multiple port options are  permitted.
Ports specified
  in  the  configuration file are ignored when a
             port is specified.

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

     -t      Test mode.  Only check the validity of the  configuration file and
             sanity  of  the  keys.   This is useful for updating
sshd reliably 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 overflow
 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
             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 DenyUsers.


     sshd reads configuration data from /etc/ssh/sshd_config  (or
the file
     specified with -f on the command line).  The file format and
 options are described in sshd_config(5).

LOGIN PROCESS    [Toc]    [Back]

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

           1.   If the login is on a tty, and no command has been
                prints last login time and /etc/motd (unless prevented in the
                configuration file or  by  $HOME/.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 $HOME/.ssh/environment, if it  exists, and users
                are allowed to change their environment.  See the
                PermitUserEnvironment option in sshd_config(5).

           7.   Changes to user's home directory.

           8.    If  $HOME/.ssh/rc  exists,  runs  it;  else   if
/etc/ssh/sshrc exists,
  runs it; otherwise runs xauth.  The ``rc''
files are
                given the X11 authentication protocol and  cookie
in standard

           9.   Runs user's shell or command.


     $HOME/.ssh/authorized_keys  is  the  default file that lists
the public keys
     that are permitted for RSA authentication in  protocol  version 1 and for
     public key authentication (PubkeyAuthentication) in protocol
version 2.
     AuthorizedKeysFile may be used  to  specify  an  alternative

     Each  line  of  the  file  contains one key (empty lines and
lines starting
     with a `#' are ignored as comments).  Each  RSA  public  key
consists of the
     following  fields, separated by spaces: options, bits, exponent, modulus,
     comment.  Each protocol version 2 public  key  consists  of:
options, keytype,
 base64 encoded key, comment.  The options field is optional; its
     presence is determined by whether the  line  starts  with  a
number or not
     (the  options  field never starts with a number).  The bits,
exponent, modulus
 and comment fields give the RSA key for  protocol  version 1; the comment
  field  is not used for anything (but may be convenient
for the user
     to identify the key).  For protocol version 2 the keytype is
     or ``ssh-rsa''.

     Note  that  lines  in  this file are usually several hundred
bytes long (because
 of the size of the public key  encoding).   You  don't
want to type
     them  in;  instead, copy the identity.pub, id_dsa.pub or the
     file and edit it.

     sshd enforces a minimum RSA key modulus size for protocol  1
and protocol
     2 keys of 768 bits.

     The  options  (if present) consist of comma-separated option
   No  spaces  are  permitted,  except  within  double
quotes.  The following
 option specifications are supported (note that option
keywords are

             Specifies that in addition to public key authentication, the
             canonical name of the remote host must be present in
the commaseparated
 list of patterns (`*'  and  `?'  serve  as
wildcards).  The
             list  may 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: 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

             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 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/IP and/or X11 forwarding
unless they
             are explicitly prohibited.  Note  that  this  option
applies to
             shell, command or subsystem execution.

             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.
             This option is automatically disabled if UseLogin is

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

             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

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

             Limit local ``ssh -L'' port forwarding such that  it
may only connect
 to the specified host and port.  IPv6 addresses
can be specified
 with an alternative syntax: host/port.  Multiple permitopen
             options may be applied separated by commas.  No pattern matching
             is performed on the specified hostnames,  they  must
be literal domains
 or addresses.

   Examples    [Toc]    [Back]
     1024 33 12121...312314325 ylo@foo.bar

     from="*.niksula.hut.fi,!pc.niksula.hut.fi" 1024 35 23...2334

     command="dump   /home",no-pty,no-port-forwarding   1024   33
23...2323 backup.hut.fi

     permitopen="",permitopen=""  1024 33


     The  /etc/ssh/ssh_known_hosts   and   $HOME/.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 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

     Hostnames is a comma-separated list of patterns (`*' and `?'
act as wildcards);
  each pattern in turn is matched against the canonical host name
     (when authenticating a client) or against the  user-supplied
name (when
     authenticating a server).  A pattern may also be preceded by
`!' to indicate
 negation: if the host name matches a  negated  pattern,
it is not accepted
  (by that line) even if it matched another pattern on
the line.

     Bits, exponent, and modulus are taken directly from the  RSA
host key;
     they  can be obtained, e.g., from /etc/ssh/ssh_host_key.pub.
The optional
     comment field continues to the end of the line, and  is  not

     Lines  starting with `#' and empty lines are ignored as comments.

     When performing host authentication, authentication  is  accepted if any
     matching  line  has  the proper key.  It is thus permissible
(but not recommended)
 to have several lines or different host keys for the
same names.
     This  will  inevitably happen when short forms of host names
from different
     domains are put in the file.  It is possible that the  files
contain conflicting
  information;  authentication  is accepted if valid
information can
     be found from either file.

     Note that the lines in these files are typically hundreds of
     long, and you definitely don't want to type in the host keys
by hand.
     Rather,  generate  them   by   a   script   or   by   taking
     and adding the host names at the front.

   Examples    [Toc]    [Back]

     closenet,..., 1024 37 159...93 closenet.hut.fi
     cvs.openbsd.org, ssh-rsa AAAA1234.....=

FILES    [Toc]    [Back]

             Contains configuration data for sshd.  The file format and configuration
  options are described in sshd_config(5).

     /etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key,
             These three 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
             this file is group/world-accessible.

     /etc/ssh/ssh_host_key.pub, /etc/ssh/ssh_host_dsa_key.pub,
             These  three  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 ssh-keygen(1).

             Contains Diffie-Hellman groups used for the "DiffieHellman Group
             Exchange".  The file format  is  described  in  moduli(5).

             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

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

             Lists the public keys (RSA or DSA) that can be  used
to log into
             the  user's  account.  This file must be readable by
root (which
             may on some machines imply it  being  world-readable
if the user's
             home  directory  resides  on  an NFS volume).  It is
recommended that
             it not be accessible by others.  The format of  this
file is described
  above.   Users  will  place the contents of
             identity.pub, id_dsa.pub and/or id_rsa.pub files into this file,
             as described in ssh-keygen(1).

     /etc/ssh/ssh_known_hosts, $HOME/.ssh/known_hosts
             These files are consulted when using rhosts with RSA
host authentication
 or protocol version 2 hostbased 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  it is connecting to the correct remote
host.  These
             files should be writable only by root/the owner.
             /etc/ssh/ssh_known_hosts should  be  world-readable,
             $HOME/.ssh/known_hosts  can, but need not be, worldreadable.

             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

     /etc/hosts.allow, /etc/hosts.deny
             Access controls that should be enforced by tcp-wrappers are defined
  here.   Further  details  are  described   in

             This file is used during RhostsRSAAuthentication and
             HostbasedAuthentication and  contains  host-username
pairs, separated
  by  a space, one per line.  The given user on
the corresponding
 host is permitted to log in without a 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

             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 RhostsRSAAuthentication and
             HostbasedAuthentication authentication.  In the simplest form,
             this  file contains host names, one per line.  Users
on those
             hosts are permitted to log in  without  a  password,
provided they
             have  the same user name on both machines.  The host
name may also
             be followed by a user name; such users are permitted
to log in as
             any user on this machine (except root).  Additionally, the syntax
             ``+@group''  can  be  used  to  specify   netgroups.
Negated entries
             start with `-'.

             If  the  client host/user is successfully matched in
this file, login
 is automatically permitted provided  the  client
and server user
  names  are  the  same.  Additionally, successful
client host key
             authentication  is  required.   This  file  must  be
writable only by
             root; it is recommended that it be world-readable.

             Warning:  It is almost never a good idea to use user
names in
             hosts.equiv.  Beware that it really means  that  the
named user(s)
             can  log  in as anybody, which includes bin, daemon,
adm, and other
             accounts that own critical binaries and directories.
Using a user
  name  practically  grants  the user root access.
The only valid
             use for user names that I can think of is  in  negative entries.

             Note that this warning also applies to rsh/rlogin.

             This is processed exactly as /etc/hosts.equiv.  However, this
             file may be useful in environments that want to  run
             rsh/rlogin and ssh.

             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.

             If  this  file  exists, it is run with /bin/sh 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 DISPLAY in
its environment).
  The script must call xauth(1)  because  sshd
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
                             # 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

             This file should be writable only by the  user,  and
need not be
             readable by anyone else.

             Like $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 ALSO    [Toc]    [Back]

     scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1),  ssh-keygen(1),
     chroot(2),    hosts_access(5),   login.conf(5),   moduli(5),
     inetd(8), sftp-server(8)

     T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S.  Lehtinen, SSH
     Protocol Architecture, draft-ietf-secsh-architecture-12.txt,
     2002, work in progress material.

     M. Friedl, N. Provos,  and  W.  A.  Simpson,  Diffie-Hellman
Group Exchange
     for  the  SSH Transport Layer Protocol, draft-ietf-secsh-dhgroupexchange-02.txt,
 January 2002, work in progress material.

AUTHORS    [Toc]    [Back]

     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.

OpenBSD      3.6                       September     25,     1999
[ Back ]
 Similar pages
Name OS Title
sshd_config FreeBSD OpenSSH SSH daemon configuration file
sshd_config OpenBSD OpenSSH SSH daemon configuration file
ssh_config OpenBSD OpenSSH SSH client configuration files
ssh_config FreeBSD OpenSSH SSH client configuration files
slogin OpenBSD OpenSSH SSH client (remote login program)
ssh FreeBSD OpenSSH SSH client (remote login program)
ssh OpenBSD OpenSSH SSH client (remote login program)
slogin FreeBSD OpenSSH SSH client (remote login program)
cslip HP-UX PPP daemon
ppl HP-UX PPP daemon
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service