rshd(8)rshd(8)NAMErshd - The remote shell server daemon
The addresses for the hostname are requested, verifying that the name
and address correspond. Causes rshd to check for the /etc/nolo‐
gin_hostname and /etc/nologin files. If either exists, rshd prints its
contents and exits. Prevents the ruserok command from doing any vali‐
dation 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 connec‐
tions 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 connec‐
tions 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 connec‐
tions 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 connec‐
tion is also in the range 512 to 1023. The server checks the client's
source address and requests the corresponding hostname (see gethost‐
byaddr(3), hosts(4), and named(8)). If the hostname cannot be deter‐
mined, 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 ini‐
tial 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 authentica‐
tion, 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 connec‐
tions 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.
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
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.
A secure connection is one where the rshd daemon authenticates a user
by using Kerberos. Kerberos is a client/server application that authen‐
ticate the client, server, and user; encrypt data; and ensure data
integrity and nonrepudiation. See your system administrator to deter‐
mine 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 Ker‐
beros 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 key‐
word 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 host-based 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 authentica‐
tion and communication between the client and server will use the
Secure Shell connection. A connection is not established if a user can‐
not 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 asso‐
ciated 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 con‐
figuring 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
Commands: kinit(1), kdestroy(1), klist(1), rcp(1), rlogin(1), rsh(1),
Functions: rcmd(3), ruserok(3)
Files: hosts.equiv(4), rhosts(4), ssh2_config(4)
Guides: Security Administration