SUMMARY: Security implications of rdist

From: Peter Schauss x 2014 (
Date: Fri Jun 27 1997 - 15:53:49 CDT

My original post was:

>From reading the documentation and a bit of experimentation it
seems that using rdist requires entries in /etc/hosts.equiv and
.rhosts (for the remote system). Does anyone have any ideas on
how to use this utility with minimal risks to system security?



I received several helpfull replies from

Arthur Darren Dunham <>
Dan Bell <>
Rich Pieri <>
Dan Pritts <>

Most suggested using the ssh instead of rsh.

Dan Pritts provided a detailed description of how he implemented
this which I have included below.

Thanks for the quick response

Peter Schauss
Gull Electronic Systems Division
Parker Hannifin Corporation
Smithtown, NY


From: Dan Pritts <>

I built usc rdist to use ssh instead of rsh.

With ssh you can do RSA public key authentication on the connection.
(although to automate it you would have to keep your public key in an
unencrypted file on your rdist master host...having it readable only
by root should provide moderate security)

I am running ssh on a different tcp port than normal for use with rdist,
and I tcp-wrapped this tcp port such that only the master host can
connect. My standard ssh port disallows root logins.

I consider this moderately secure.

below is my writeup for the other admins here.

dan pritts
Unix System Admin First Virtual Holdings, Inc. 313-213-3791

rdist at FV
danno 4/12/97


 files to install on client
 files to install on server
 modifications to rdist source
 modifications to sshd configuration
 possible improvements

files to install on a client host (most hosts):

 man pages

These files will need to be installed, but need to be customized for
each site so that only the master rdist host will have ssh as root
access. This involves replacing the authorized_keys and known_hosts
files entirely and modifying hosts.allow and sshd_config_rdist as
appropriate to allow only the master host to connect.


Additionally, there are /etc/services and /etc/inetd.conf mods (done
via custom script) so that service ssh-rdist via port 40 gets you
an tcp-wrapped sshd using /etc/sshd_config_rdist as its config file.

   ssh-rdist stream tcp nowait root /usr/sbin/sshd /usr/sbin/sshd
    -f /etc/sshd_config_rdist -i

   ssh-rdist 40/tcp ssh-rdist

and of course any distfiles you want.

files to install on a server host:

 man pages

Generate a public/private ssh key pair via ssh-keygen, with no
password. you'll get the message "only do this if you really
understand what you are doing." from ssh-keygen; this is to remind you
that using no password means that file security is the only important

The "/.ssh/identity" file is the keys to the kingdom for this
public/private key pair; if it is compromised, root access (from that
host only) will be available to any client host. The file
should go into authorized_keys on this host's clients.

Changing this behavior to require a password to do an rdist (ie, to
decode the identity file) would require non-trivial modifications to

Rdist itself:
using rdist 6.1.3 from usc (

defined PATH_REMSH to /usr/bin/ssh in config/config.h
files to install:

minor modiifcations to src/rshrcmd.c to pass extra arguments to ssh
if _SSH_ARGS set; see the end fo the file and the defines at the end
of config.h

increased # of parallel connections to 6; this is because there is a
long (~20sec) delay starting sshd from inetd; should probably go higher
(command line option for this). For interactive use this would suck,
but the 20 second delay is fine in this case.

sshd configuration for rdist:

Using port 40 for alternative sshd; this is tcp wrapped down to only
the "master" rdist host (in ann arbor, mailrus). Additionally sshd
config for that sshd instance is configured to only accept connections
from that ip address. I'm using sshd spawned from inetd with tcpd,
rather than the libtcpwrap stuff for sshd, to avoid any problems with
sshd's implementation.

um# diff sshd_config sshd_config_rdist
< Port 22

> # this is for root@server -> root@client (eg, rdist) ssh's only
> Port 40
< ServerKeyBits 1024
< LoginGraceTime 600
> ServerKeyBits 768
> LoginGraceTime 150
< PermitRootLogin no
> PermitRootLogin yes
< X11Forwarding yes
> X11Forwarding no
< PasswordAuthentication yes
> PasswordAuthentication no
< # AllowHosts *
< # DenyHosts *
> #DenyHosts *
> AllowHosts

This should be reasonably secure; AllowHosts shoudln't even matter since tcpd should prevent any other than the real host from getting through, but whatever. Will change serverKeyBits to 1024 for deployment; this increases the time for each remote host's sshd to start up so bad for testing. (on sparc 4, 768 bits starts up in about 7 seconds; 1024 bits starts up in about 20 secs).

Use a large number of concurrent connections so all of your 20-second waits occur simultaneously.

ssh configuration for rdist: ----------------------------

no changes from stock.

Possible improvements: ----------------------

Rebuild ssh/sshd with hardcoded configuration file paths that are different from stock and install these new ssh/sshd binaries on each machine; also necessary to rebuild rdist to use this new ssh program (redefine _PATH_REMSH).

this could be an issue on the off chance someone accidentally changes the standard /etc/sshd_config file to allow ssh logins as root (since that would open up the standard ssh port to any host, not just the one specified in the hosts.allow file and the sshd_config_rdist file).

This would be at the cost of maintainability; each new upgrade of ssh would require a double rebuild and install.

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:58 CDT