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 config_file] [-h host_key_file] [-o options] [-4|-6]
[-p port] [-F] [-v] [-V] [-g login_grace_time] [-i] [-q]
DESCRIPTION
Sshd2 (Secure Shell Daemon) is the server counterpart of
sshg3. 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
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 /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
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 /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.
-4 Specifies that sshd2 will only use IPv4 addresses.
IPv6 addresses from ListenAddress configuration
statements, name resolution and port forwarding
will be ignored.
-6 Specifies that sshd2 will only use IPv6 addresses.
IPv4 addresses from ListenAddress configuration
statements, name resolution and port forwarding
will be ignored.
-p port
Specifies the port on which the server listens for
connections. Note that when -p is specified, the
server will ignore any defined ListenAddress and
AddressFamily configuration statements and listen
on all available IPv4 and IPv6 interfaces. -p is
intended for testing - for greater control use the
sshd2_config configuration file. The value of the
Port configuration variable can be specified on the
command line with the -o option. However, explicit
port numbers on ListenAddress statements will over-
ride -oPort.
-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 /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).
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
/opt/tectia/etc/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.
/opt/tectia/etc/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-keygen-g3(1). This file contains vital crypto-
graphic information and may only be read or modi-
fied by root.
/opt/tectia/etc/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.
/opt/tectia/etc/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 Tectia Server for
IBM z/OS Administrator Manual 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 sshg3, 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 sshg3
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 sshg3 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 /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 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.
/opt/tectia/etc/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.
AUTHORS
SSH Communications Security Corporation
For more information, see http://www.ssh.com.
SEE ALSO
sshd2_config(5), ssh-broker-g3(1), ssh-keygen-g3(1),
sshg3(1), scpg3(1), sftpg3(1), rlogin(1), rsh(1), tel-
net(1)
2014 SSH Communications Security Corporation