Operating System - Tru64 Unix
1747984 Members
4762 Online
108756 Solutions
New Discussion юеВ

Re: Permission denied when rsh to Tru64 V5.1A host

 
Keith Moodie
Occasional Advisor

Permission denied when rsh to Tru64 V5.1A host


I keep getting Permission denied
when doing a rsh rlogin or telnet into a new Alpha
(coming from an older Alpha)

the .rhosts appears OK

The only way time I had it working was when I set nopassword on the account

cant find a solution using man

Any ideas ?
Thank you in anticipation
8 REPLIES 8
Ralf Puchner
Honored Contributor

Re: Permission denied when rsh to Tru64 V5.1A host

Please check the permission of the rshd and rlogin and login program on server side.

Next check the permission of the .rhosts file as described in the man page of .rhosts.

If this doesn't solve your problem, replace the .rhosts by a new file containing

+ +

If this works there should be a problem with DNS resolution (short/longname etc.)
Help() { FirstReadManual(urgently); Go_to_it;; }
Joris Denayer
Respected Contributor

Re: Permission denied when rsh to Tru64 V5.1A host

Keith,

If you say that it works with "nopassword", then nameresolving works OK. Anyway, Ralf has right, you can have problems with long/short names.
Therefore sometimes, I put 2 lines in .rhosts
.


Do you execute the rsh as root or as another user.
rsh for standard users will check the file /etc/hosts.equiv.
If the check of /etc/hosts.equiv fails it will look in the home-directory of that user for a .rhosts file.

Rgrds

Joris
To err is human, but to really faul things up requires a computer
Sunil Sharma_1
Honored Contributor

Re: Permission denied when rsh to Tru64 V5.1A host

Hey,
check the ownership of .rhosts file also, it's very importent it should be own by account owner like if you are setting for root, root should be owner of .rhosts file.

Sunil
*** Dream as if you'll live forever. Live as if you'll die today ***
Keith Moodie
Occasional Advisor

Re: Permission denied when rsh to Tru64 V5.1A host


Thanks everyone for your help.

1st I should fill in the picture a bit more

I have two Alpha's the old one has been running happily for 5 years, the new one I am trying to get working so it can replace the old one.

* As the new machine is to replace the older one they both "think" that they are called "slicca" but think that the other machine is called something else.

eg /etc/hosts on "old" slicca reads
123.456.63.151 slicca.dnr.qld.gov.au slicca
123.456.62.16 somoa.dnr.qld.gov.au somoa

/etc/hosts on "new" slicca reads
123.456.62.16 slicca.dnr.qld.gov.au slicca
123.456.63.151 slicca1


* From the old slicca (Digital UNIX 4.0C)
To other workstations (SGIs)
I can rsh, rlogin, ftp OK
( So presumably permissions are OK)

To the new slicca
rlogin works but requires password
rsh works if no command given
(ie rlogin but requires password)
rsh with a command fails
returns permission denied
ftp fails
access denied
this happens after i enter a username
doesn't give me the opportunity for a password
(same happens if coming from a PC or SGI)

* From other hosts (SGI's)
same as if coming from old slicca

* From the new slicca
I can
* rsh rlogin, ftp to several other machines
including old slicca
* rlogin with a password to itself

I can not
* rsh to itself if there is a command passed
(ie always needs a password)

-----------------------------
Permissions rsh, rlogin, login on both machines are -rws--x--x root bin

ls -l on .rhosts in user directory gives
-rw------- 1 root users {stuff} .rhosts

/etc/hosts.equiv is as installed
ls -l gives
-rwxr-xr-x 1 bin bin {stuff} /etc/hosts.equiv

Changing the .rhosts to
+ +
didn't work

I tried
.

but that didn't work

rsh is being executed by non-root user
and going to a non-root user

I have tried .rhosts owned by local user as well as by root.


Security level is BASIC

If the problem is that they both think they are slicca, then:
* should it go away when new slicca eventually replaces the old ?

Ralf Puchner
Honored Contributor

Re: Permission denied when rsh to Tru64 V5.1A host

the order of nameresolution is configured via /etc/svc.conf.

it is not possible to specify different IP adresses for the same hostname without trouble. I believe problem is gone if machine replaces the older one and name/IP matches the whole configuration (rc.config, kernel etc.)

why not configuring a new name/ip and using an alias for the older one after the older machine is replaced?
Help() { FirstReadManual(urgently); Go_to_it;; }
Joris Denayer
Respected Contributor

Re: Permission denied when rsh to Tru64 V5.1A host

Keith

In Tru64, telnetd and other daemons are doing name2address resolvings. Depending on the settings in /etc/svc.conf this info will come from /etc/hosts, your nameserver or your NIS server.
Anyway, the name slica will be resolved as 123.456.63.151.

So, When you connect with the new slica, then the resolve will give a mismatch.

You can switch the bad behaviour from the new slica to the old slica, if you add/change the slica entry in /etc/hosts with the address 123.456.62.16


BTW: It is time to modify all IP-related RFC's, you are the first one to have a byte higher than 255 in the IP-address :-)

Rgrds

Joris
To err is human, but to really faul things up requires a computer
Juan Manuel Naranjo A.
Frequent Advisor

Re: Permission denied when rsh to Tru64 V5.1A host

check /etc/hosts.equiv for a line containing the remote host.

check permissions of the file /etc/hosts.equiv too.
Keith Moodie
Occasional Advisor

Re: Permission denied when rsh to Tru64 V5.1A host

Thank you all for your help.

An interesting thing happened the other day.

I discovered that the DNS had a different machine using the IP of my new machine, (the alian machine was not turned on), might have been a typo, as the IP was allocated to my machine 12 months ago.

I also had a friend drop in who is experienced in managing SGI, SUN, and HP platforms.

We changed the IP of my new machine to an unused one.
Then we changed the ownership of .rhosts to the user (I had changed it to root)
And also made a few other changes and *** it works ***

That is not so say that I won't experience some problems but I have had none so far.

We also resolved the ftp problem
/etc/shells needed a line for tcsh added.


Thanks again to the four of you for your suggestions and advice.

I am allocating points to all of you: