Where do I look for differences in security setup?

[Don Spare]

I have 2 HP-UX 11.0 servers. I thought they were set up identically but I have just found out that I can remote shell into one as root without specifying a password, but the other prompts for password. Where do I look for these kinds of differences and how do I make it so the password is NOT required for remote shell?

Also the environment for root seems different than for 'oracle' in that oracle seems to have vi set to context/language sensitive (auto indents and such) but in root that is not the case. Where is that defined?

[harry d brown jr]

look for a DOT rhosts file (.rhosts) and look at /etc/hosts.equiv.

live free or die
harry d brown jr

[harry d brown jr]

take a look at this product: http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=B6834AA

live free or die
harry d brown jr

[Don Spare]

In the / (root home directory) on both systems the .rhosts files are identical. Neither server has /etc/hosts.equiv files.

[Biswajit Tripathy]

Don Spare wrote:
> I have 2 HP-UX 11.0 servers. I thought they were
> set up identically but I have just found out that I
> can remote shell into one as root without specifying
> a password, but the other prompts for password.

As already explained, look at both $HOME/.rhosts
and /etc/hosts.equiv files. Are you trying to rlogin to
both servers from the same machine and from the
same login ID?

You could post both the above files here (don't post
actual IP addresses, if any, in a public forum, just
replace them by IP_ADDR1 or some thing similar).

- Biswajit

[Don Spare]

I am attempting to setup a Nagios monitoring script that will run on a Linux box and 'remote shell' (/usr/bin/rsh on the Linux box) to my HP-UX servers and execute the 'uptime' command. The output of 'uptime' is returned to Linux where it is parsed and an appropriate status message and code is generated and sent to the Nagios application which then updates its intranet web site with that status, and possibly sends a notification to appropriate parties. Communication to my development HP-UX server (dev) is perfect using this process. But attempts to connect to my production server (prod) all end up failing. It seems the rsh to prod always asks for a password when attempted from the command line. Since the script doesn't understand this (and doesn't know the password) it simply fails. No password is requested by dev. Both prod and dev are supposed to be setup the same with the only difference I know of is that prod has JavaVM installed.

So ..... where do I look for the configuration parameters that say to ask for a password?

[Biswajit Tripathy]

As already suggested, could you post the contents
of ~root/.rhosts and /etc/hosts.equiv files?

I'm assuming that you are logged in as root and
running remote command execution as root in all the
machines.

- Biswajit

[Kent Ostby]

Don -- are the two machines in question on the same subnet ?

Does one have a firewall that the other doesnt have to try to get through ?

[Kent Ostby]

Also, check to see if the source machine can be seen from the two target machines .. perhaps something in /etc/hosts or DNS is preventing the one target machine from recognizing the source machine.

[Bill Hassell]

If .rhosts exists *and* the permission for .rhosts is 600, then the remshd daemon is asking DNS to validate the client. Your DNS seerver must provide forward and reverse lookup for the incoming client or it will ask for a password. Lack of symmetrical records is a common Windows DNS server misconfig. If the DNS gods aren't responsive, change your HP-UX server to use /etc/hosts first, then DNS (/etc/nsswitch.conf) and put the client(s) into your /etc/hosts file. That will assure forward/reverse validation. Use nslookup to verify.

[harry d brown jr]

rsh to determine if and report on the uptime status of a server?

one word: BAD

use something like snmp to check uptime!

live free or die
harry d brown jr

[Don Spare]

Well, I found the problem. It seems my /etc/hosts file did not contain the location of the Nagios server. It appears that the remote server must know about the local server when attempting these types of connections.



This problem has been resolved.