RSH Problem 3

[Moose467]

Hi to all,
We have been using RSH successfully for several years now, to stop a couple of application servers while the database server does an offline backup.
However I recently went on holiday and responsibility was passed to someone else. On my return I find that the machines are not talking via rsh, the error, rshd: 0826-813 Permission is denied, is produced. He denies doing anything to affect this, (although he somehow managed to delete the root cron!).

I have checked everything I can think of and most of the suggestions on tek-tips, including the .rhosts file, hosts.equiv, /etc/hosts etc and it all looks ok.
Can anyone suggest some alternative places to look?

The strange thing is I can rsh fine from the application servers to the database, but not the other way around.

Thanks in advance for any help you can provide

Phil

P.S. I'm running 4.3.3 on a M80 (database) and 2 x H80 (application severs)

 

[MoshiachNow]

Were any user accounts altered on the involved machines - username/passwd/etc. ?

Long live king Moshiach !

http://www.7for70.com/

 

[Moose467]

Hi Moshiach,
Thanks for getting back to me, as far as I know, no.
I'm using a user called p30adm (yes we're using SAP), there is definately an entry in the target .rhosts for this user from the host. I've tried altering it to allow all connections from that host and even all p30adm users from any host. I've tried doing this with both .rhosts and hosts.equiv with no joy.
we're not using DNS, just the hosts table, but have checked and all the relevent entrys exist and I can ping them via the hostname.
I've read that ssh can disable rsh and rlogin, but as far as I can see it's not even installed!
Any other idea's would be welcomed

Phil

 

[columb]

We had problems with rsh when the host name was not the first after the inet address in /etc/hosts

i.e. command

rsh myhost ls

did work when /etc/hosts looked like

10.1.1.1 myhost myalias

but NOT when it looked like

10.1.1.1 myalias myhost

It took us a while to find that one!

Columb Healy
Living with a seeker after the truth is infinitely preferable to living with one who thinks they've found it.

 

[Moose467]

Thanks Columb,
unfortunately we're not using aliases,
its just IP <hostname>. Like I said we've had this running for years, before this problem.

I've just tried a quick test and found I can rsh fine between the application servers and from the application servers to the database. This makes me think there is something wrong with the database server. Has anyone come across this before? Could it be linked with the mysterious disappearance of the root cron? I've run diags and can't seem find anything causing trouble.

 

[MoshiachNow]

HI,

Try the following to fix any possible security mismatch on your DB server:

usrck –y ALL -Checks/fixes user problems
pwdck –y ALL -Checks/fixes password problems
grpck –y ALL -Checks/fixes groups problems
mkpasswd -f -rebuild the /etc/passwd indexes in case of suspected corruption


Long live king Moshiach !

http://www.7for70.com/

 

[Moose467]

New commands to me thanks,
unfortunately still have the same problem after running each command on all machines involved!

 

[MoshiachNow]

Try removing the user you use for login to the DB server and redefine it.

Long live king Moshiach !

http://www.7for70.com/

 

[Moose467]

good thought, but not sorry that hasn't worked either.
I really appriciate the help you are giving, thanks

 

[screwloose]

Are you using a $HOME/.netrc file for ftp or rexec? If so, the file permissions MUST be set to 600.

If you are using rsh, try adding the hostname and fully qualified domain name to the server you are connecting from in the .rhosts file. Also check the /etc/hosts and .rhosts entries have the proper entries; and check the permissions for .rhosts (600).

 

[Moose467]

nope i'm sorry there is no .netrc, and all .rhosts have been chmod'd to 600. As far as I can see all host and .rhost files have the proper entries. Are there any other commands to check for corrupt system files like moshiach recommended, as i'm sure the problem lies deeper than .rhosts, I can't understand why it would just stop working after so long.

 

[screwloose]

First, it is not that complicated to use, and does not just stop working without a change. Secondly, are you using Rsh or rsh? You print rsh but RSH in the title. What method of authentication are you using? How about providing the command you are using along with the output (e.g., a screenshot).

 

[rim001]

Easy way around this is to delete and recreate tour .rhosts file on both machines.

 

[MoshiachNow]

Could you try accessing your Server over a cross cable,to eliminate any networking issues?

Long live king Moshiach !

http://www.7for70.com/

 

[spamly]

I have a scripted process that sync's files across systems using rcp. When it fails, the following message appears.

FROM=originating system
TO=remote system

Have you added ${FROM}.mydomain.org to ${TO}'s
/root/.rhosts file?  Anther reason why it is failing could be because this system has no idea who ${TO} is.  You can try the IP address of the system instead.  If it still isn't working with the IP address, it could be because ${TO} is resolving ${FROM} as something other than ${FROM}.mydomain.org.  Try logging into ${TO} from ${FROM} and typing in a 'who am i'.  This will show the name that ${TO} thinks you are.  Put in the hostname or IP address that you see there in ${TO}'s /root/.rhosts file.

 

[Moose467]

Problem solved.
I have come in over the weekend so I can have some proper downtime and fix this annoying problem, one reboot later and deletion of user accounts and files and rsh once again works. Thanks too all those who helped in resolving this.

Phil