Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
permission denied issuing rsh 1
- Thread starter jrb23
- Start date
Hello jrb23,
This sounds likes something that has happened to me a couple of times when a programmer has attempted to "troubleshoot" what they thought was a comm issue by crowbaring some permissions.
Per IBM, the following files must have there permissions, owners and groups set in the following manner or the system will fail the operation in an attempt to save you from yourself:
-r-sr-xr-x 3 root system /usr/bin/tftp
-r-sr-xr-x 3 root system /usr/bin/utftp
-r-xr-xr-x 1 root system /usr/sbin/tftpd
-r-sr-xr-x 1 root system /usr/bin/rcp
-r-sr-xr-x 1 root bin /usr/bin/rlogin
-r-sr-xr-- 1 root system /usr/sbin/rlogind
-r-sr-xr-x 2 root system /usr/bin/rsh
-r-sr-xr-- 1 root system /usr/sbin/rshd
Hope this helps! Took me forever to work this out the first time it happened because the error message is less than enlightening.
This sounds likes something that has happened to me a couple of times when a programmer has attempted to "troubleshoot" what they thought was a comm issue by crowbaring some permissions.
Per IBM, the following files must have there permissions, owners and groups set in the following manner or the system will fail the operation in an attempt to save you from yourself:
-r-sr-xr-x 3 root system /usr/bin/tftp
-r-sr-xr-x 3 root system /usr/bin/utftp
-r-xr-xr-x 1 root system /usr/sbin/tftpd
-r-sr-xr-x 1 root system /usr/bin/rcp
-r-sr-xr-x 1 root bin /usr/bin/rlogin
-r-sr-xr-- 1 root system /usr/sbin/rlogind
-r-sr-xr-x 2 root system /usr/bin/rsh
-r-sr-xr-- 1 root system /usr/sbin/rshd
Hope this helps! Took me forever to work this out the first time it happened because the error message is less than enlightening.
-
1
- Thread starter
- #3
thanks noober for the reply ..
Our system have the same permissions exactly the same as what you have listed on both the target and destination hosts.
There is another host that can rsh with no problem.
e.g. source host1 can rsh to targethost
source host2 cannot rsh to targethost.
source host1 & host2 have similar permissions and other settings the same.
Our system have the same permissions exactly the same as what you have listed on both the target and destination hosts.
There is another host that can rsh with no problem.
e.g. source host1 can rsh to targethost
source host2 cannot rsh to targethost.
source host1 & host2 have similar permissions and other settings the same.
Does it fail both ways between target and host2? For instance can you do an rsh from the target TO host2 but not from host2 TO the target?
Also, does user account come into play at all...as in will it work when you are logged on as root where it fails for others? Or not work for root but does work for another account?
Also, does user account come into play at all...as in will it work when you are logged on as root where it fails for others? Or not work for root but does work for another account?
- Thread starter
- #5
noober --
1. from TARGETHOST to HOST2 rsh/rcp is fine
2. from HOST2 to TARGETHOST rsh is failing. So there is something on HOST2 that is different to HOST1. This is where i am trying to figure out. Permissions on the programs as you suggested have been check and all identical. /etc/host.equiv has been edited to include host + username
3. HOST1 to TARGETHOST and vice versa is fine.
4. Root is the user we have been using.
- Thread starter
- #6
Noober --
I have resolved this issue now. the /etc/hosts does not have the entry of the HOST2 name on the TARGETHOST and vice versa.
our /etc/netsvc.conf --- does resolution local first then bind. dsn resolution on both machines points to correct hostnames. - i expected that if hostname is not in the /etc/hosts file it should have interrogated DNS. but looks like not the case.
so resolving permission issue with rsh -- you have to look into these files
a. .rhosts
b. /etc/hosts
c. /etc/netsvc.conf, and the NSORDER enviroment (if necessary)
d. permission sets of the programs (.e.g /usr/bin/rsh)
e. /etc/hosts.equiv -- is NOT needed
I have resolved this issue now. the /etc/hosts does not have the entry of the HOST2 name on the TARGETHOST and vice versa.
our /etc/netsvc.conf --- does resolution local first then bind. dsn resolution on both machines points to correct hostnames. - i expected that if hostname is not in the /etc/hosts file it should have interrogated DNS. but looks like not the case.
so resolving permission issue with rsh -- you have to look into these files
a. .rhosts
b. /etc/hosts
c. /etc/netsvc.conf, and the NSORDER enviroment (if necessary)
d. permission sets of the programs (.e.g /usr/bin/rsh)
e. /etc/hosts.equiv -- is NOT needed
- Status