On Wed, 21 Jan 2009, Honest Guvnor wrote:

> On Wed, Jan 21, 2009 at 12:18 PM, Jan Iven <[log in to unmask]> wrote:
>> rsh and rlogin use two different ports (513, 514), check whether the
>> appropriate holes are in your server firewall (/etc/syconfig/iptables).
>> Then make sure the client accepts the callback traffic (on some random
>> port) from the server.
>
> Thanks for the input. The problem was that the random port was
> blocked. A google of red hat rsh pages suggested a range of 1016-1022.
> Manually unblocking these ports enabled rsh to work at least for a
> quick test. Not that I know anything about the subject but I thought
> high port numbers were supposed to be unblocked for uses like this?

The rsh protocol requires thet the server make a connection back to the 
client.  Once upon a time there was an iptables module which parsed the 
data stream and opened the hole needed but I doubt that anyone is 
maintaining that any more.

>> And then forget about it and use ssh :-) , unless you'll never have any
>> untrusted machine on your network..
>
> Ssh is used to connect to the host. The computational nodes can see no
> untrusted machines and as much security as possible is turned off. Our
> current task is to get the host to have normal security when accessing
> outside without losing the connection to the computational cluster.
> Now we have rsh functioning we can at least use the machines to do
> some work.
>
> Ssh was sort of working but generating and installing keys for
> millions of machine combinations when you are prompted for a password
> every time you try to install them was sufficiently difficult to
> prompt the reversion to rsh to get some work done. Getting ssh working
> more reasonably will now be revisited in a more leisurely manner.

If you can live with hostbased security then you just need to put all the 
public keys into the /etc/ssh/ssh_known_hosts{,2} files, and the hostnames 
into /etc/hosts.equiv

There are scripts for collecting ssh public keys from a set of hosts, 
though we do something a bit different.  We store a copy of the ssh keys 
for all hosts on a server so we can re-use them if a machine needs to be 
re-installed (after say a disk failure) and from that we can trivially 
generate the ssh_known_hosts files - we also generate files suitable for 
importing into putty and a list of expected fingerprints which we put on a 
web page.  Hmm having said that they seems to have gone away in our recent 
web-server re-jig I'd better find out why...

  -- Jon

-- 
/--------------------------------------------------------------------\
| "Computers are different from telephones.  Computers do not ring." |
|       -- A. Tanenbaum, "Computer Networks", p. 32                  |
---------------------------------------------------------------------|
| Jon Peatfield, _Computer_ Officer, DAMTP,  University of Cambridge |
| Mail:  [log in to unmask]     Web:  http://www.damtp.cam.ac.uk/ |
\--------------------------------------------------------------------/