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?
Thanks,
------------------------------------------------------------------
I received several helpfull replies from
Arthur Darren Dunham <add@is.rice.edu>
Dan Bell <dbell@blaze.cs.jhu.edu>
Rich Pieri <rich.pieri@prescienttech.com>
Dan Pritts <danno@aa.fv.com>
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
ps4330@okc01.jccbi.gov
Gull Electronic Systems Division
Parker Hannifin Corporation
Smithtown, NY
------------------------------------------------------------------
From: Dan Pritts <danno@aa.fv.com>
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.
danno@aa.fv.com 313-213-3791
rdist at FV
danno 4/12/97
abstract:
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):
-----------------------------------------------
/usr/bin/rdist
/usr/bin/rdistd
/etc/hosts.deny
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.
/etc/hosts.allow
/etc/sshd_config_rdist
/.ssh/authorized_keys
/.ssh/known_hosts
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.
inetd:
ssh-rdist stream tcp nowait root /usr/sbin/sshd /usr/sbin/sshd
-f /etc/sshd_config_rdist -i
services:
ssh-rdist 40/tcp ssh-rdist
and of course any distfiles you want.
files to install on a server host:
----------------------------------
/usr/bin/rdist
/usr/bin/rdistd
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
piece.
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 identity.pub 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.
Rdist itself:
-------------
using rdist 6.1.3 from usc (ftp://ftp.usc.edu/pub/rdist)
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
3c3,5
< Port 22
--- > # this is for root@server -> root@client (eg, rdist) ssh's only > > Port 40 7,8c9,10 < ServerKeyBits 1024 < LoginGraceTime 600 --- > ServerKeyBits 768 > LoginGraceTime 150 10c12 < PermitRootLogin no --- > PermitRootLogin yes 14c16 < X11Forwarding yes --- > X11Forwarding no 22c24 < PasswordAuthentication yes --- > PasswordAuthentication no 25,26c27,28 < # AllowHosts *.our.com friend.other.com < # DenyHosts lowsecurity.theirs.com *.evil.org evil.org --- > #DenyHosts * > AllowHosts 206.252.4.26This 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