SSH Tectia 
PreviousNextUp[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 >>
    Authentication >>
    System Administration >>
    File Transfer Using SFTP >>
    Secure File Transfer Using Transparent FTP Security >>
    Tunneling >>
    Troubleshooting SSH Tectia Server for IBM z/OS >>
    Man Pages and Default Configuration Files >>
        Default sshd2_config Configuration File
        Default ssh_certd_config Configuration File
    Log Messages >>


SSHD2(8)                       SSH2                      SSHD2(8)

       sshd2 - Secure Shell server daemon on z/OS

       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]

       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 can be started manually  from  USS  or  by  using  a
       started  task.   It  forks  a new daemon for each incoming
       connection.   The  forked  daemons  handle  key  exchange,
       encryption,  authentication,  command  execution, and data

       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 /opt/tectia/etc/sshd2_config (or the file
       specified 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 with the restart command:

       # /opt/tectia/etc/init.d/sshd2 restart

       -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 /opt/tectia/etc/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 /opt/tectia/etc/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.

       sshd2    reads    configuration    data   from   /opt/tec-
       tia/etc/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 comments.

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

       When  a  user logs in successfully, sshd2 does the follow-

       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.

              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-

              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-keygen-g3(1).  This file contains vital crypto-
              graphic information and may only be read  or  modi-
              fied by root.

              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.

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

              Contains  information on how the server will verify
              the identity of an user.  See SSH Tectia Server for
              IBM z/OS Administrator Manual for more information.

              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

              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.

              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).

              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.

              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

              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-

              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.

              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.

              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  /opt/tec-
              tia/etc/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's host-key algorithm
              is ssh-dss, the host key is contained in  the  file
      in  the knownhosts direc-

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

              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.

       SSH Communications Security Corp.

       For more information, see

       sshd2_config(5),    ssh-broker-g3(1),    ssh-keygen-g3(1),
       sshg3(1),  scpg3(1),  sftpg3(1),  rlogin(1),  rsh(1), tel-

PreviousNextUp[Contents] [Index]

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

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