trusted host on HPUX 10.2/11

[vladimir gershman]

Greetings,

I want to set up a workstation A (with HPUX 11) as a trusted host to workstations B and C (both with HPUX 10.2). I had sysadmins modify /etc/hosts.equiv file on B and C to include A. After that when I am on A and do "rlogin B" I still get asked for a password. Is there anything else that has to be done besides modifying /etc/hosts.equiv

Thanks

Vlad

[Martin Johnson]

You need an .rhosts file in the home directory. See man rhosts.

HTH
Marty

[Sridhar Bhaskarla · Accepted solution]

Hi Vlad,

Allowing r-access is a serious security violation.

/etc/hosts.equiv defines system wide access while .rhosts defines individual user access. So, if you intend to use r-commands, then it is recommended to configure .rhosts.

If root on hostB has to rlogin to root on hostC, then .rhosts file in the home directory of root on hostC should have the following entry.

hostB root

The best way to setup trusted system is to use public/private key authentication mechanism through ssh. You need to do a little bit of reading but it is better to run ssh. You can get it from

http://hpux.cs.utah.edu/hppd/hpux/Networking/Admin/openssh-3.4p1/

-Sri

[Tom Danzig]

Also check to make sure the service is not restricted via an entry in /var/adm/inetd.sec

[Sajid_1]

hello,

As mentioned, allowing permissions for r commands through the *global* file - /etc/hosts.equiv is a big security hole. You can do the same setting with $HOME/.rhosts file. In your case, create this under / and add the hostname and username entries there.

HTH

[Steven E. Protter]

does host.equiv not override any .rhost files, rendering them useless, I mean harmless?

I initiated that and a inetd.sec file and clamped down effectively.

r login is a serious security concern and as I migrate to new boxes, I'm getting rid of it. The developers are already squealing, but they'll just have to get used to secure ftp

Steve

[doug hosking]

I agree with the security concerns, but can't say what's the right security policy for your environment. Assuming that you still want to make this work with .rhosts despite the security issues, you might look to see if the hostnames of a, b and c are aliased in some way in your /etc/hosts or DNS configuration. I have seem cases where the mapping between IP address and hostname returns the 'wrong' entry relative to what is in the .rhosts files. The solution in that case is to include both the real hostname and all of its aliases in your .rhosts file.