rshd - The remote shell server daemon
rshd [-aelnxK]
The addresses for the hostname are requested, verifying
that the name and address correspond. Causes rshd to
check for the /etc/nologin_hostname and /etc/nologin
files. If either exists, rshd prints its contents and
exits. Prevents the ruserok command from doing any validation
based on the user's file, unless the user is the
root user. Disables transport-level, keep-alive messages.
Encrypts the data transmitted between the local host and
the remote host. This option requires that the local and
remote hosts be configured to use Kerberos authentication
in the same or trusting Kerberos realms.
If the rshd daemon is started with the -x option,
only connections initiated with the -x option from
a remote host will be accepted. All communications
between the two hosts will be encrypted. Specifies
that only Kerberos authenticated connections will
be accepted. This option requires that the local
and remote hosts be configured to use Kerberos
authentication in the same or trusting Kerberos
realms.
If the rshd daemon is started with the -K option,
only connections initiated from a host in the same
or trusting Kerberos domain will be accepted. All
communications between the two hosts will be
encrypted.
The rshd daemon is the server for the rcmd(3) routine and
for the rsh(1) program. The server provides remote execution
facilities with authentication based on privileged
port numbers from trusted hosts.
The rshd daemon listens for service requests at the port
indicated in the cmd service specification; see services(4). When a service request is received, the following
protocol is initiated: The server checks the client's
source port. If the port is not in the range 512 to 1023,
the server aborts the connection. The server reads bytes
from the socket up to a null (`\0') byte. The resultant
string is interpreted as an ASCII number, base 10. If the
number received in step 2 is nonzero, it is interpreted as
the port number of a secondary stream to be used for the
stderr option. A second connection is then created to the
specified port on the client's machine. The source port
of this second connection is also in the range 512 to
1023. The server checks the client's source address and
requests the corresponding hostname (see gethostbyaddr(3),
hosts(4), and named(8)). If the hostname cannot be determined,
the dot-notation representation of the host address
is used. If the hostname is in the same domain as the
server (according to the last two components of the domain
name), or if the -a option is given, the addresses for the
hostname are requested, verifying that the name and
address correspond. If address verification fails, the
connection is aborted with the message Host address mismatch.
A null-terminated username of at most 16 bytes is
retrieved on the initial socket. This username is interpreted
as the user identity on the client 's machine. A
null-terminated username of at most 16 bytes is retrieved
on the initial socket. This username is interpreted as a
user identity to use on the server's machine. A null-terminated
command to be passed to a shell is retrieved on
the initial socket. The length of the command is limited
by the upper bound on the size of the system's argument
list. The rshd daemon then validates the user. The way
in which the rshd daemon authenticates a user and transmits
data depends on if the local and remote hosts are
using a basic connection or a secure connection (Kerberos).
Basic and secure connections provide user authentication,
however a secure connection also provides client
and server authentication, data encryption, data
integrity, and nonrepudiation. A null byte is returned on
the initial socket and the command line is passed to the
normal login shell of the user. The shell inherits the
network connections established by rshd.
Transport-level, keep-alive messages are enabled unless
the -n option is present. The use of keep-alive messages
allows sessions to be timed out if the client crashes or
becomes unreachable.
Basic Connection [Toc] [Back]
A basic connection is one where the rshd daemon validates
the user using ruserok(3), which uses the file
/etc/hosts.equiv and the file found in the user's home
directory. The -l option prevents ruserok(3) from doing
any validation based on the user's file, unless the user
is the superuser.
If rshd was started with the -e option, the user is not
the superuser, and either the /etc/nologin_hostname or
/etc/nologin file exists, rshd prints the contents of the
first file found and aborts the connection. If the file
has a zero length, rshd prints a logins disabled message.
Secure Connection [Toc] [Back]
A secure connection is one where the rshd daemon authenticates
a user by using Kerberos. Kerberos is a
client/server application that authenticate the client,
server, and user; encrypt data; and ensure data integrity
and nonrepudiation. See your system administrator to
determine if your system is running Kerberos. See Security
Administration for more information about Kerberos.
Kerberos authenticates by using secret-key cryptography
and tickets between Kerberos clients and Kerberos server
in the same or trusting Kerberos realms. Once authenticated
by Kerberos, users receive a Kerberos Ticket Granting
Ticket (TGT). Users with a valid TGT are not prompted
for a username or password when the remote host is in the
same or trusting Kerberos realm.
Alternatively, you can configure the rsh, rlogin, and rcp
commands and applications that use the rcmd function to
automatically use a Secure Shell connection by enabling
the Secure Shell EnforceSecureRutils keyword in the
/etc/ssh2/ssh2_config file or in a user's
$HOME/.ssh2/ssh2_config file. When the EnforceSecureRutils
keyword is enabled: The rsh command can use only hostbased
authentication to authenticate users. Secure Shell
host-based authentication uses the file as described in
Basic Connection, but also requires additional configuration
as described in Security Administration. The sshd
daemon runs and spawns the srcmd child process; the rshd
and rlogind daemons do not run.
See Security Administration for more information about
Secure Shell authentication and the EnforceSecureRutils
keyword.
After it is determined that Secure Shell will be used, all
authentication and communication between the client and
server will use the Secure Shell connection. A connection
is not established if a user cannot be authenticated.
Except for the last diagnostic message listed, all diagnostic
messages are returned on the initial socket, after
which any network connections are closed. An error is
indicated by a leading byte with a value of 1 (0 is
returned in step 9 above upon successful completion of all
the steps prior to the execution of the login shell). The
name of the user on the client's machine is longer than 16
characters. The name of the user on the remote machine is
longer than 16 characters. The command line passed
exceeds the size of the argument list (as configured into
the system). No password file entry for the username
existed. The server is currently not accepting connections.
The chdir command to the home directory failed.
The authentication procedure previously described failed.
The pipe needed for the stderr option, but it was not created.
A fork by the server failed. The user's login
shell could not be started. This message is returned on
the connection associated with the stderr option, and is
not preceded by a option byte. An attempt was made to
start rshd using the -K flag without first configuring the
system as part of a Kerberos realm or domain.
Specifies the command path Stops logins. In a cluster,
there is also /etc/nologin_hostname. Specifies Secure
Shell client configuration information.
Commands: kinit(1), kdestroy(1), klist(1), rcp(1),
rlogin(1), rsh(1), ssh2(1)
Functions: rcmd(3), ruserok(3)
Files: hosts.equiv(4), rhosts(4), ssh2_config(4)
Guides: Security Administration
rshd(8)
[ Back ] |
