Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

RSH PERMISSION DENIED????

154 views
Skip to first unread message

Martian

unread,
Apr 8, 1996, 3:00:00 AM4/8/96
to

I am trying to use rsh to exec a command on one of my other boxes,
essentially, I have a 386 Linux box setup as a camera server. It's
only function in life is to take pictures with a digital cam upon demand.
usu I do it by telnet or rlogin. I want so set up a script on the main
linux box that does a rsh to the camserver and takes a pic.
I've tried (as root) :

rsh camhost picture.command
I get permission denied.
I edited /etc/hosts.allow and /etc/hosts.equiv and added the main machine
in (actually did it on both hosts.) and nuttin.

both root and normal accounts on BOTH machines are the same (passwords too)

Thanks!

Mehmet H Aksu

unread,
Apr 10, 1996, 3:00:00 AM4/10/96
to
Martian--

If security isn't an issue.
create /.rhosts on your camhost
with an entry of the remote host followed by root.

hosts.equiv should work, make sure camhost:/etc/hosts
has an entry for remote host in it.

-- mha

--
___________________________________________________________________________

Mehmet H. Aksu email: m...@cc.bellcore.com

Tom Ryan

unread,
Apr 12, 1996, 3:00:00 AM4/12/96
to
If you read the man pages you will see that rlogin will work fine for all
users based on entries in /etc/hosts.equiv However, for root, extra
security is in place.

It must be specified in root's .rhosts that access is allowed...

think about the security problem here... you are making it very easy to
gain access to your machine... Especially if it is on a valid internet
address.

Why not give the appropriate permissions to the user who needs to rlogin..
maybe change ownership of the files??

tom

Mehmet H Aksu (m...@cc.bellcore.com) wrote:
: Martian--

Jerry Sweet

unread,
Apr 13, 1996, 3:00:00 AM4/13/96
to

There's an extra dimension to the "rsh" problem if you're using NIS/YP
in your environment. In this environment, I've had reasonable success
with using rsh to and from properly configured Slackware hosts; less
success with Red Hat 2.1.

Red Hat 2.1 uses the "NYS" variant of NIS/YP. Unfortunately, NYS, as
distributed with Red Hat (2.2beta4?), doesn't appear to work well in a
heterogeneous environment. Besides exhibiting problems with matching
host names for the r* program authentications, NYS's "ypcat" program
doesn't work. However, as I'll report below, NYS can be configured to
permit rsh operations between _some_ types of hosts.

NYS's configuration files are /etc/yp.conf and /etc/nsswitch.conf.
The yp.conf file specifies which NIS/YP master to consult. The
nsswitch.conf file's "hosts:" entry specifies the order in which to
consult the various name-to-IP maps: dns, nis, and hosts.

The order _DOES_ matter, and the _type_ of NIS/YP master matters.
The choices are:

1. To make HP-UX 9.x hosts interoperate with Red Hat Linux 2.1
(in terms of rsh operations--or "remsh" on the HP-UX hosts)
you have to specify an HP-UX master in yp.conf, and you have
to specify the order "dns files nis" in the nsswitch.conf
"hosts" entry. Unfortunately, this means that none of your Red Hat
hosts will interoperate with each other.

2. To make Red Hat hosts interoperate with each other, you have
to specify a SunOS master in yp.conf. This is required
_possibly_ because SunOS uses some filthy hack (apparently
missing in HP-UX 9.x's NIS/YP implementation) in its NIS'd hosts
table in order to permit its resolver to perform DNS lookups.
The nsswitch order "nis files dns" appears to work best here.

Apparently, you can't have both 1 and 2, so you have to choose which
set of hosts you want to allow to interoperate with each other. I
haven't figured out yet why NYS cares about where it's getting its
hosts information--particularly since, at least in my environment, the
DNS, NIS/YP, and hosts tables are built automatically from a common
source and all provide the same information. Also, I haven't tried
creating a Red Hat Linux NIS/YP master to see if that solves the
problem on the Linux side--that's the next thing to try.


0 new messages