I've just spent some time trying to work out why I couldn't rsh to our F740 from some newly installed machines even though I had added them to /etc/hosts.equiv.
It turns out, apparently, that the option telnet.hosts list gets into the act:
if the rsh'ing host isn't in the telnet.hosts list, then it gets a prompt rejection, and nothing is logged in /etc/messages;
if it gets past that, then /etc/hosts.equiv is checked for host and (possibly implied) userid, and if *this* check fails then a "[rshd_0]: Permission denied to rsh request from ... at ..." is logged to /etc/messages.
This is with 5.3.5. Has it always been like this? I could have sworn not, but the two lists have been in step here for a long time, so I could be wrong.
There's nothing in the hosts.equiv(5), rshd(8), or options(1) man pages to suggest that telnet.hosts affects anything except telnet, or that rsh'ing is affected by anything except /etc/hosts.equiv. It also seems to me very counter-intuitive, and quite inconvenient because the telnet.hosts list is restricted to so few elements.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
I agree it doesn't make sense. Another example where features get implemented over time without a coherent plan.
I would advocate:
1. Add support for an /etc/hosts.allow and .deny files that allow the user to specify telnet, rsh, and so on specifically. These files would override hosts.equiv and telnet.hosts.
2. Deprecate the telnet.hosts option, but continue to honor it for at least a year. Post big warning messages on all releases telling people it's going away. Then yank the option entirely.
3. Retain hosts.equiv as an rsh-only file only for tradition, but have the other files override it.
Bruce
On Mon, 22 May 2000, Chris Thompson wrote:
I've just spent some time trying to work out why I couldn't rsh to our F740 from some newly installed machines even though I had added them to /etc/hosts.equiv.
This was changed in one of the 5.x releases and I found out about it the same way you did, all of a sudden everything broke. The big problem that I had with it was that I was using the NetApp as a tape server and therefore had well over a hundred clients that needed to be able to "rsh" to it to access the tape drive. In my original configuration I had only two of those hosts listed as being able to telnet to the NetApp but now I had to allow them all. To make things worse, the telnet.hosts option does not allow me to list 100+ hostnames so I had to resort to specifying "telnet.hosts *" so I have now opened up the NetApp to being telnetted to from any host on my local network. Admitted, they still have to be able to guess the password but I just didn't like the thought of opening up the box to potenetial hackery.
<cheerful-sarcasm>
This is yet another example of NetApp's fervent commitment to change command syntax, behaviour and output between releases! Through their hard-work and dedication to this cause we can be assured that it will be nearly impossible to consistantly automate any part filer adimistration! And since they diligently ensure not to document any of these changes, us customers can be sure that every ONTAP upgrade will have some annoying SNAFU! Hip Hip Hooray!
</cheerful-sarcasm>
We agree that rsh hosts shouldn't need to be in "options telnet.hosts" - this is ridiculous. NetApp needs to revert this behaviour so that hosts.equiv is all that is necessary for rsh access.
In general, NetApp should think before changing stuff like this as it can lead to many unhappy customers.
-- Jeff
-- ---------------------------------------------------------------------------- Jeff Krueger E-Mail: jeff@qualcomm.com NetApp File Server Lead Phone: 858-651-6709 IT Engineering and Support Fax: 858-651-6627 QUALCOMM, Incorporated Web: www.qualcomm.com
From "David H. Brierley" on Mon, 22 May 2000 15:17:29 EDT:
On Mon, 22 May 2000, Chris Thompson wrote:
I've just spent some time trying to work out why I couldn't rsh to our F740 from some newly installed machines even though I had added them to /etc/hosts.equiv.
This was changed in one of the 5.x releases and I found out about it the same way you did, all of a sudden everything broke. The big problem that I had with it was that I was using the NetApp as a tape server and therefore had well over a hundred clients that needed to be able to "rsh" to it to access the tape drive. In my original configuration I had only two of those hosts listed as being able to telnet to the NetApp but now I had to allow them all. To make things worse, the telnet.hosts option does not allow me to list 100+ hostnames so I had to resort to specifying "telnet.hosts *" so I have now opened up the NetApp to being telnetted to from any host on my local network. Admitted, they still have to be able to guess the password but I just didn't like the thought of opening up the box to potenetial hackery.
-- David H. Brierley Raytheon Electronic Systems, Naval & Maritime Integrated Systems Engineering Technology, Operating Systems Support Group
-
Bruce Sterling Woodcock -
Chris Thompson -
David H. Brierley -
Jeff Krueger