The command fanout tools support both remote shell (rsh or rcmd) and ssh transports.
Each requires specific security setup steps in order to authorize
the user initiating the command fanout operation to execute a command
on the remote target systems. The command fanout tools require that
the remote system not prompt for a password. Both rsh and ssh transports must be preconfigured on each
remote system to allow non-interactive access. The following sections
describe the required setup steps to enable command fanout operations
for each transport.
Remote Shell Security Setup |
 |
When using the remote shell command transport,
the local user must have a $HOME/.rhosts file
configured on each remote target system. Refer to the rhosts(4) reference manpage for details on configuring the $HOME/.rhosts file.
ssh Security Setup |
|
ssh uses public host keys to
authenticate remote hosts and supports public key authentication to
authenticate users. When users’ public keys are properly configured
on a set of remote systems, they can access those systems without
being prompted for a password. Manually configuring ssh for non-interactive access is a multistep process where ssh configuration files are edited on each system. The csshsetup tool greatly simplifies configuring ssh trust
relationships. For example, when using the command fanout tools in
a Serviceguard cluster, you typically want to be able to issue commands
from any member and target any other member. This requires an n^2
distribution of ssh public keys. Start by creating
a text file listing the members the cluster, one per line. Invoke csshsetup using this file. Note that this command needs
to be issued only once since it configures each member of the cluster:
# csshsetup -r -f members_list.txt
The -r option instructs csshsetup to distribute the
keys in a round-robin or n^2 fashion. The user will be prompted for
his password on each remote host. csshsetup then
automates the entire public key distribution process.
Note that csshsetup is not
specific to Serviceguard clusters; it can be used for arbitrary groups
of systems. Also, the trust relationship does not have to be bidirectional.
Omit the -r option when setting up a one-way trust
relationship between the current host and a set of remote target hosts.
For additional details, refer to the csshsetup(1) reference
manpage.
Security Notes |
|
The remote shell protocol is an inherently insecure
protocol. It is the protocol used by the Berkeley “r commands,” rlogin, rcp, remsh, and so on. Many
system administrators disable the use of the “r” commands
as a matter of policy. For example, the Bastille security hardening
tool offers a default option to disable these insecure services. If
disabled, the pdsh -R rsh option to use the remote shell transport will not work.
If the “r” services are not disabled,
use of the pdsh -R rsh option by unprivileged users is still disabled by default
because of the inherent security risk. By default, only users with
root privileges can use the pdsh -R rsh option. This is because the remote shell rcmd library call requires the use of a privileged port.
Even though privileged users can use -R rsh, the ssh transport is still preferred.
If the hosts and users are trusted in your environment,
you can enable the use of the pdsh -R rsh option
for unprivileged users with the following commands:
# cd /opt/dsau/bin/pdsh
# chown root:bin pdsh
# chmod u+s pdsh
Printable version
