Executing Remote Commands at a System Level

Before delving into the fine points of RPCs from a programming standpoint, it is instructive to look at the execution of remote commands at a system (command-line) level. Most UNIX systems offer several commands that allow the user to execute commands on a remote system. Historically, the most commonly supported remote execution command is rsh (the r emote sh ell command).

The rsh command connects to a specified host and executes the indicated command. Standard input from the local host is copied to standard input on the remote host. The remote host's standard output and error will be copied to the local host's standard output and error respectively. Signals such as interrupt, quit, and terminate are passed on to the remote host. As the rsh command has proven to be a security risk, users are encouraged to use, in its place, the ssh command found in the OpenSSH suite of tools. The ssh command provides secure encrypted communication between two hosts and supports more secure methods for authenticating a user (more on this will follow in a bit).

The general syntax for the ssh command is

linux$ ssh remote_host_name the_command

Figure 9.2 demonstrates using ssh on a system called linux to run the who command on the remote system called morpheus .

Figure 9.2 A typical ssh command .

linux$ ssh morpheus who
gray@morpheus's password:

<-- 1

root console Feb 18 11:54 (:0)
root pts/6 Mar 28 14:03 (:0.0)
gray pts/2 Apr 8 11:29 (zeus)
root pts/7 Apr 5 12:37 (:0.0)
root pts/8 Mar 28 13:02 (:0.0)
root pts/3 Mar 14 12:11 (:0.0)
root pts/9 Apr 4 12:10 (:0.0)
root pts/10 Apr 4 12:15 (:0.0)

(1) No echo of password when entered.

The remote system (in this case morpheus ) prompts for the user's password (as required for the remote system). The output of the command is displayed on the local host linux . It is possible to redirect the output produced by the remote command. However, there are some interesting wrinkles that we should be aware of when we specify I/O redirection with the command to be remotely executed. For example, the two command sequences that follow appear to be very similar:

linux$ ssh morpheus who > /tmp/whoosie
linux$ ssh morpheus who ">" /tmp/whoosie

The first command sequence places the output of the who command in the file whoosie in the tmp directory of the local host linux . The second command sequence places the output of the who command in the file whoosie in the tmp directory of the remote host morpheus ! This occurs because in the second command sequence the redirection, which has been placed in quotes, is passed as part of the remote command and is not acted upon by the local host. If ssh is passed just the host name and not passed a command to execute, it will log into the specified host and provide the shell specified in the user's password entry. All communications with the remote shell are encrypted.

For ssh to execute a remote command, the user issuing the command must be authenticated. [2] This can be accomplished in a number of ways. Similar to rsh , if the host the user is logging in from is listed in the remote host's /etc/hosts.equiv (or /etc/shosts.equiv ) file, and the user's login name is the same on both systems, the user is permitted access. Failing this, if the user's $HOME/.rhosts (or $HOME/.shosts ) file on the remote host has the name of the local host and user's login name, then the user is are granted access. However, as this sort of authentication is inherently insecure (due to IP, DNS, and routing spoofing), it is normally combined with publicprivate key encryption authentication.

[2] The need for system security today is much different than it was, say, even 5 years ago. An in-depth discussion of security is beyond the scope of this text.

For ssh publicprivate authentication can be specified in a number of ways (the following is an overviewsee the manual page on ssh for the all the gory details). The configuration file sshd_config (which is most often in the / etc/ssh directory) designates the authentication method. While four different approaches are available, most system administrators opt to let the system authenticate a request either by checking the user's public key or by prompting the user for his or her normal login password (the default).

The publicprivate key approach deserves some additional discussion. A user generates a publicprivate key pair by running the ssh-keygen utility. Newer versions of this utility permit the user to specify the type ( -t ) of key to be created. The choices are protocol version 1 (specified as rsa1 ) or protocol version 2 (specified as rsa or dsa ). If rsa1 is specified, the keys are placed in separate files (usually called identity and identity.pub for private and public keys respectively) in the $HOME/.ssh directory. While permission-wise the identity.pub file is accessible to all, the identity file should not be readable by anyone other than its owner. The first time ssh is used to access a remote system, authentication information is added by ssh to the user's $HOME/.ssh/known_hosts file. Figure 9.3 shows the process of generating a publicprivate key and then using ssh to connect from a remote host back to the author's base system (linux.hartford.edu).

Figure 9.3 Creating a publicprivate key and using ssh to access a system for the first time.

[View full width]

[gray@remote_sys ~]$ ssh-keygen -t rsa1

<-- 1

Generating public/private rsa1 key pair.
Enter file in which to save the key (/home/gray/.ssh/identity):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/gray/.ssh/identity.
Your public key has been saved in /home/gray/.ssh/identity.pub.
The key fingerprint is:
6b:8d:a5:32:7d:8e:cc:66:56:c2:60:5b:a3:76:23:10 gray@remote_sys.somewhere.edu

[gray@remote_sys ~] ssh linux.hartford.edu

<-- 2

The authenticity of host 'linux.hartford.edu(137.49.6.1)' can't be established.
RSA key fingerprint is 4b:a4:ac:a6:4f:22:43:e1:1a:35:6d:b9:19:41:fd:ba.
Are you sure you want to continue connecting (yes/no)? yes
Warning:Permanently added 'linux.hartford.edu,137.49.6.1' (RSA) to the list of known

hosts.
[e-mail]'s password:
Last login: Tue Apr 9 08:20:26 2002 from remote_sys.somewhere.edu
Red Hat Linux Thu Mar 29 18:44:10 CST 2001
[gray@linux ~]$

(1) Create a rsa1 type public and private key pair.

(2) From remote system, use ssh to access home system.