- Community Home
- >
- Servers and Operating Systems
- >
- Legacy
- >
- Operating System - Tru64 Unix
- >
- Re: Permission denied when rsh to Tru64 V5.1A host
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-16-2003 06:35 PM
тАО07-16-2003 06:35 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-16-2003 10:38 PM
тАО07-16-2003 10:38 PM
Re: Permission denied when rsh to Tru64 V5.1A host
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-17-2003 12:09 AM
тАО07-17-2003 12:09 AM
Re: Permission denied when rsh to Tru64 V5.1A host
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-17-2003 12:37 AM
тАО07-17-2003 12:37 AM
Re: Permission denied when rsh to Tru64 V5.1A host
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-17-2003 05:39 PM
тАО07-17-2003 05:39 PM
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 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-17-2003 11:50 PM
тАО07-17-2003 11:50 PM
Re: Permission denied when rsh to Tru64 V5.1A host
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-18-2003 12:04 AM
тАО07-18-2003 12:04 AM
Re: Permission denied when rsh to Tru64 V5.1A host
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-18-2003 06:43 AM
тАО07-18-2003 06:43 AM
Re: Permission denied when rsh to Tru64 V5.1A host
check permissions of the file /etc/hosts.equiv too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-24-2003 03:43 PM
тАО07-24-2003 03:43 PM
Re: Permission denied when rsh to Tru64 V5.1A host
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: