SSH Tectia  
Previous Next Up [Contents] [Index]

    About This Document >>
    Installing SSH Tectia Server for IBM z/OS >>
    Getting Started with SSH Tectia Server for IBM z/OS >>
    Configuring the Server >>
    Configuring the Client >>
    Authentication >>
    File Transfer Using SFTP >>
    File Transfer Using Transparent FTP Tunneling >>
    Tunneling on the Command Line >>
    Troubleshooting SSH Tectia Server for IBM z/OS >>
    Advanced Information >>
    Man Pages >>
        scp2
        sftp2
        ssh-add2
        ssh-agent2
        ssh-socks-proxy >>
        ssh-socks-proxy-config >>
        ssh-socks-proxy-ctl >>
        ssh-certd
        ssh_certd_config
        ssh-certview >>
        ssh-cmpclient >>
        ssh-dummy-shell
        ssh-ekview
        ssh-externalkeys
        ssh-keydist2 >>
        ssh-keygen2
        ssh-probe2
        ssh-scepclient >>
        ssh-sft-stage
        ssh2
        ssh2_config
        sshd-check-conf
        sshd2
        sshd2_config
        sshd2_subconfig
        sshregex
    Log Messages >>

sshd2

SSHD2(8)                       SSH2                      SSHD2(8)


NAME
       sshd2 - Secure Shell server daemon on z/OS


SYNOPSIS
       sshd2 [-d debug_level_spec] [-D debug_level_spec] [-f con-
       fig_file] [-h host_key_file] [-o options] [-p port] [-F]
       [-v] [-V] [-g login_grace_time] [-i] [-q]


DESCRIPTION
       Sshd2  (Secure  Shell Daemon) is the server counterpart of
       ssh2.  Together, these two programs replace and extend the
       services rlogin and rsh, and provide secure encrypted com-
       munication channels between two hosts  connected  over  an
       unsecured  network.   They  are  intended to be as easy to
       install and use as possible.

       sshd2 is normally started at boot time from  /etc/rc.local
       or  equivalent.   It  forks a new daemon for each incoming
       connection.   The  forked  daemons  handle  key  exchange,
       encryption,  authentication,  command  execution, and data
       exchange.

       sshd2 can be configured using command-line  options  or  a
       configuration  file.  Command-line options override values
       specified in the configuration file.  sshd2 reads configu-
       ration data from /etc/ssh2/sshd2_config (or the file spec-
       ified with -f on the command line).

       Subconfiguration files can also be specified in  the  main
       configuration  file.  Note that if changes are made in the
       main configuration file, sshd2 will have to be  restarted,
       for example by sending a signal to it:

       # kill -HUP `cat /var/run/sshd2_22.pid`

       or, if the directory /var/run/ does not exist:

       # kill -HUP `cat /etc/ssh2/sshd2_22.pid`


OPTIONS
       -d debug_level_spec
              Runs  the server in one-shot debug mode. The server
              process accepts only one connection and exits after
              the  connection  has disconnected. The server sends
              verbose debug output to stderr. The debugging level
              is  either  a  number, or a comma-separated list of
              assignments    of     the     format     ModulePat-
              tern=debug_level,  for example "*=10,sshd2=2". This
              should be the first argument on the command line.

       -D debug_level_spec
              Runs the server in continuous debug  mode.  As  -d,
              but  the  server  accepts  several  connections and
              needs to be stopped manually when you want to  fin-
              ish the debugging.

       -f configuration_file
              Specifies the name of the configuration file.   The
              default  is  /etc/ssh2/sshd2_config.  Note: If this
              is specified, the default configuration file is not
              read at all.

       -h host_key_file
              Specifies  the file from which the host key is read
              (default /etc/ssh2/hostkey).  If sshd2 is  not  run
              as    root,    the   default   host-key   file   is
              $HOME/.ssh2/hostkey.

       -o 'option'
              Can be used to give options in the format  used  in
              the configuration files.  This is useful for speci-
              fying options for which there is no  separate  com-
              mand-line  flag.  The option has the same format as
              a line in the configuration  file.   Comment  lines
              are  not  accepted.   Where  applicable,  the egrep
              regex format is used.

       -p port
              Specifies the port to which the server listens  for
              connections.  The default port is 22. Note that the
              server will listen to all  addresses  when  started
              with  -p.  It  will  also cause sshd2 to ignore any
              defined ListenAddress statements (this is  to  make
              this  switch  useful for debugging purposes again).
              If you want to use a  different  listen  addresses,
              use ListenAddress (complementing with Port, if nec-
              essary) configuration options.

       -F     Disables daemon mode.  The server does not spawn a
              new process to the background.

       -v     Enables verbose mode.  Displays  verbose  debugging
              messages.   Equivalent  to  -d  2.  This option can
              also be specified in the configuration file.

       -V     Displays version string.

       -q     Quiet mode.  Nothing is sent  to  the  system  log.
              Normally  the beginning, authentication, and termi-
              nation of each connection is logged.   This  option
              can also be specified in the configuration file.

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

       -i     Specifies that sshd is invoked via inetd.


CONFIGURATION FILE
       sshd2 reads configuration data from /etc/ssh2/sshd2_config
       (or the file specified with -f on the command line).   The
       file  contains  keyword-value  pairs, one per line.  Lines
       starting with '#' and empty lines are interpreted as  com-
       ments.

       For the format of sshd2_config, see sshd2_config(5).


LOGIN PROCESS
       When  a  user logs in successfully, sshd2 does the follow-
       ing:

       1.     Changes process to run with normal user privileges.

       2.     Sets up the basic environment.

       3.     Reads /etc/environment if it exists.

       4.     Changes to the user's home directory.

       5.     Runs the user's shell or command.


FILES
       /etc/ssh2/sshd2_config
              Contains configuration data for sshd2.   This  file
              should  be  writable by root only, but it is recom-
              mended (though not necessary)  that  it  be  world-
              readable.

       /etc/ssh2/hostkey
              Contains  the  private  part of the host key.  This
              file is normally  created  automatically  by  "make
              install",  but  can  also be created manually using
              ssh-keygen2(1).  This file contains  vital  crypto-
              graphic  information  and may only be read or modi-
              fied by root.

       /etc/ssh2/hostkey.pub
              Contains the public part of  the  host  key.   This
              file  is  normally  created  automatically by "make
              install", but can also be created  manually.   This
              file  should  be  world-readable  but  must  not be
              writable by anyone but root.  If it does not  match
              the  private counterpart, clients probably get con-
              fused about the server's identity.

       /etc/ssh2/random_seed
              This file contains a seed  for  the  random  number
              generator.   This  file  must  not be accessible by
              anyone but root.

       $HOME/.ssh2/authorization
              Contains information on how the server will  verify
              the  identity  of  an  user.   See ssh2(1) for more
              information.

       $HOME/.hushlogin
              If this file exists, sshd2 will not print  informa-
              tion  during  login.   (This is normally the user's
              last login  time,  message  of  the  day  and  mail
              check.)


       /etc/nologin
              If  this  file  exists, sshd2 refuses to let anyone
              except root log in.  The contents of the  file  are
              displayed  to  anyone  trying  to log in.  The file
              should be world-readable.


       /etc/nologin_<hostname>
              As above, but the file name is constructed from the
              name  of  the host. Check output of hostname to see
              which name you should use in the  file  name.  This
              functionality  is  supposed to be used by clustered
              machines (which share /etc).


       $HOME/.rhosts
              This file contains host-username  pairs,  separated
              by  a  whitespace, one per line.  The given user is
              permitted to log in from the given host  without  a
              password.   The  same  file  is used by rlogind and
              rshd.  sshd2 differs from rlogind and rshd in  that
              it requires public host-key authentication from the
              ssh2 server running on this  host  in  addition  to
              validating the host name retrieved from domain name
              servers.  The file must be  writable  only  by  the
              user;  it  is recommended that it is not 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.

       $HOME/.shosts
              For  ssh2,  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 ssh2
              only.

       /etc/hosts.equiv
              This file is used  during  .rhosts  authentication.
              In  its  simplest  form,  this  file  contains host
              names, one per line.  Users on those hosts are per-
              mitted  to log in without a password, provided they
              have the same username on both machines.  The host-
              name may also be followed by a username; 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  pro-
              vided the client and server usernames are the same.
              Additionally, successful host-based  authentication
              is  normally  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
              usernames in  hosts.equiv.   Note  that  it  really
              means that the named user(s) can log in as anybody,
              including bin, daemon, adm, and other accounts that
              own  critical  binaries  and  directories.  Using a
              username practically grants the user  root  access.
              The only valid use for usernames should be in nega-
              tive entries.  Note that this warning also  applies
              to rsh/rlogin.

       /etc/shosts.equiv
              This  is  processed  exactly  as  /etc/hosts.equiv.
              However, this file is not used by rlogin and  rshd,
              so using this permits access using ssh2 only.

       $HOME/.ssh2/knownhosts/xxxxyyyy.pub
              These are the public host keys of hosts that a user
              wants to log in from using hostbased authentication
              (equivalent  to  RhostsRSAAuthentication  in ssh1).

              Also, users have  to  set  up  their  $HOME/.shosts
              (only  used  by  ssh) or $HOME/.rhosts files (inse-
              cure, as it is used by the r* commands  also).   If
              the  username is the same on both hosts, it is ade-
              quate   to   put   the   public   host    key    to
              /etc/ssh2/knownhosts   and   add  the  hostname  to
              /etc/shosts.equiv (or /etc/hosts.equiv).

              xxxx denotes the host name (FQDN) and yyyy  denotes
              the public-key algorithm of the key.

              For  example,  if zappa.foo.fi's host-key algorithm
              is ssh-dss, the host key is contained in  the  file
              zappa.foo.fi.ssh-dss.pub  in  the knownhosts direc-
              tory.

              Possible names for public-key algorithms  are  ssh-
              dss and ssh-rsa.


       /etc/ssh2/knownhosts/xxxxyyyy.pub
              As  above,  but system-wide.  These settings can be
              overridden by the user by putting a file  with  the
              same  name to the $HOME/.ssh2/knownhosts directory.


INSTALLATION
       sshd2 is normally run as root.  If it is not run as  root,
       it can only log in as the user it is running as, and pass-
       word authentication may not work if the system uses shadow
       passwords.   An  alternative  host-key  file  must also be
       used.


AUTHORS
       SSH Communications Security Corp.

       For more information, see http://www.ssh.com.


SEE ALSO
       sshd2_config(5), ssh2(1),  ssh-keygen2(1),  ssh-agent2(1),
       ssh-add2(1),  scp2(1),  sftp2(1)  rlogin(1),  rsh(1), tel-
       net(1)

Previous Next Up [Contents] [Index]


[ Contact Information | Support | Feedback | SSH Home Page | SSH Products ]

Copyright © 2007 SSH Communications Security Corp.
This software is protected by international copyright laws. All rights reserved.
Copyright Notice