Automated remote operation via the BSD rsh programs and
its relations requires that the user on the remote machine have a
.rhosts file. This permits anyone who can subvert the
network enough to spoof the user on the originating machine also has
the ability to gain access to the remote machine.
Automated remote operation via the ssh programs permits
paris@iliumwho wants to permit user
priam@spartato perform an rdist of some files (labelled
We presume that this is the free rdist originally from USC, not the rdist as supplied by most operating system/hardware vendors. This free rdist is a client/server application which uses rsh by default, but permits the specification of ssh as a non-default transport mechanism. The example could apply to any other client/server application such as CVS which also permits itself to use a non-default transport mechanism. It also applies to remote invocation of simple shell commands where there is no need for a client/server mechanism.
In the absence of ssh the command for running rdist would be
/path/to/sparta/rdist -f /path/to/distfile helenor, if the free rdistd server is not in the default path at the remote end
/path/to/sparta/rdist -f /path/to/distfile -p /path/to/ilium/rdistd helen
Priam must interactively test the ssh connection
ssh or slogin. This will verify
that the pieces are correctly installed. This also permits
priam@sparta to obtain and/or verify the public
key of the sshd on
attempting non-interactive tasks. Without this step
ssh will deny access because the default
configuration of ssh requires that the public key
of the remote machine be verified interactively.
priam@spartamust use ssh-keygen to create an RSA key pair
~priam/.ssh/nohorseas the name. Because it is to be used in a fully automatic fashion by cron, this private key should have no passphrase. (The lack of passphrase opens what may be the largest security hole in this scheme. All keys for interactive use should have passphrases. See appendix for a scheme by which a passphrase might be possible even with automatically-used keys such as this.)
priam@spartamust transmit his public key to
~priam/.ssh/nohorse.pubfile containing the public key must be securely transferred from
ilium. Typically this would be accomplished using scp, but it could also be done via e-mail with PGP.
paris@iliummust modify the public key for the specific use
NNNN MM 89012[bulk of huge decimal prime number omitted for the sake of example]34567 priam@spartawhere NNNN is the key length, MM is the encryption modulus, and the huge prime number is the public key.
Paris will want to modify this key and append it to his file of authorized RSA keys. The key is modified by prepending a restriction in the way it may be used.
command="/path/to/ilium/rdistd -S" NNNN MM 89012[bulk still gone for the sake of example]34567 priam@spartaAs soon as this modified key is appended to
ilium:~paris/.ssh/authorized_keysit will be possible for Priam, and only Priam, to invoke rdistd, and only rdistd, on
Further restrictions on this key are possible and highly advisable; e.g.
from="sparta",command="/path/to/ilium/rdistd -S",no-port-forwarding, no-pty NNNN MM 89012[bulk still gone for sake of example]34567 priam@spartaSee the man page on sshd for full details on restricting use of keys.
priam@spartashould create a ssh wrapper script
nohorsekey is not Priam's default ssh identity. Priam could modify his ssh configuration file (
~priam/.ssh/config) to assert that the
nohorsekey was to be used in transactions with
ilium, but this might befuddle interactive logins from
Fortunately, there is another way to specify the identity via a simple shell script wrapper:
#! /bin/sh unset SSH_AUTH_SOCK exec /path/to/sparta/ssh -x -a -i ~priam/.ssh/nohorse $*Here Priam has used the
-iswitch to specfy that the
nohorsekey should be used, and the
-aswitches to specify that no X11 forwarding or authentication agent forwarding should be performed.
Note that even with explicit specification of the
nohorse key ssh may fail if Priam
attempts to invoke this while also running
ssh-agent. It appears that ssh
always prefers an agent over the command line switch, and if
the agent does not contain an authorized identity
ssh gives up without even trying the
nohorse key. I'm not sure if this should be
considered a bug in ssh.
In order to avoid the use of the agent, Priam has used the
unset line to assure that any active
ssh-agent be ignored. If Priam typically uses
ssh-agent as part of his interactive session,
this will be very important for interactive tests of the
scheme with an unpassphrased
However, if Priam wants to use a passphrased key (as described
in the appendix) then he should ensure that the agent holds only
nohorse key and not do the
priam@spartamust set up cron job
/path/to/sparta/rdist -P /path/to/ssh_wrapper -f /path/to/distfile helenwhich asserts that rdist should use Priam's ssh wrapper script as its transport mechanism.
The wrapper is required because rdist does not
permit embedded spaces in the string following the
Things are simpler if
paris@sparta does not need
a client/server app, but merely a remote command invocation.
In such cases the cron job could simply directly invoke
ssh with the
ilium, which means that nobody can trick Priam's cron job into sending sensitive files to some other machine. The files are encrypted in transit. Paris can ensure that only Priam is permitted to send files.
Naturally, this presumes that the superusers on
ilium are trustworthy. A malicious or stupid
ilium could relax the security provisions in
~paris/.ssh/authorized_keys file to permit others in.
A malicious superuser on
sparta could steal Priam's
private key from
~priam/.ssh/nohorse and attempt to use
rdist to overwrite sensitive files on
The worst security hole is probably that routine backup tapes on
sparta contain Priam's un-passphrased
nohorse private key. This makes it somewhat more
important that backup tapes be handled securely (especially if Paris
is, in actuality, a superuser at
ilium). Otherwise some
poseidon@aegean, might just obtain a backup
tape containing the
nohorse key and deliver it to
odysseus@ithaca while he is walking along the beach.
nohorsekey. The cron job could be modified to set its environment such that it would find the authentication agent when it ran ssh. (Note that in this case the wrapper script described above should not do the
unsetand need not specify the name of the
nohorsekey. It is perhaps for this very reason that the behavior where ssh prefers an agent to the explicit command-line specification of a key is not a bug.)
So long as the ssh-agent process remained running Priam's
cron job would be able to perform the rdist. If that
ssh-agent were to terminate, then Priam would have to
re-start and re-authorize it interactively. A sufficiently
sophisticated cron job could detect the non-existence of the
authentication agent, and send mail to Priam reminding him to
get back over to
sparta and re-authorize it.
In this case, the
nohorse key cannot be as easily
compromised. Instead of simply having to capture the private key file
(which would happen routinely with backups), it becomes necessary for
the superuser on
sparta to locate and interrogate Priam's
In a manual test I have demonstrated that this idea does work. I have also written a smart shell script which hunts for the agent and sends mail if it cannot be found. (CAVEAT: The shell script has been in regular use for several months, but it has not been employed widely enough to be considered more than beta-level software.)
This scheme is probably worth adopting in cases where it is absolutely necessary to prevent backup tapes from compromising the keys.
The identities of the users and machines in this example are not intended to resemble anyone living or dead within the past 3 millennia, notwithstanding the mascot at the origin of the free version of rdist.