"rlogin" fails first time, work second

[John McKiernan]

SOmeone else in our group went through a lockdown procedure for a WWW server, disabling non-essential services and creating firewall and policies. I've got to enable "rcmd" to do a software install, then disable it again, but I can't get the commands to work. I get the following in /var/log/messages :

Jun 3 13:30:35 rqa-web2 ipchains: Flushing all chains: succeeded
Jun 3 13:30:35 rqa-web2 ipchains: Removing user defined chains: succeeded
Jun 3 13:30:35 rqa-web2 ipchains: Resetting built-in chains to the default ACCEPT policy succeeded
Jun 3 13:30:48 rqa-web2 pam_rhosts_auth[2334]: allowed to jmckiern@rqa-app2-m as jmckiern
Jun 3 13:30:48 rqa-web2 in.rshd[2334]: rsh denied to jmckiern@rqa-app2-m as jmckiern: Permission denied.

Also, as noted, even though I have /etc/hosts.equiv and .rhosts files, "rlogin" still asks for a password, and always fails the first but works on the second try. WHAT would cause this ?

[Craig Gilmore]

This sounds like a hostname resolution issue. Since it works the second time, but not the first.

Does an nslookup return properly before you try the rlogin? -forget what RH says, I still prefer nslookup.

[Steven E. Protter]

I agree with the prior post the issue is probably a DNS related issue.

Check that the servers in /etc/resolv.conf are actually providing reliable DNS info on nslookup or dig requests.

When I was tryiing to use my web server to relay DNS information from outside my business's private network to machines on the inside I got results similar to this. Second try on websites worked.

I changed the workstation configuration to get DNS information directly from the outside server and things worked right.

I would seriously consider dropping ipchains in favor of iptables.

Its more robust, has NAT built into the firewall and does a better job. ipchains isn't going to get any more improvements so its becoming obsolete.

As far as avoiding this problem with rlogin, consider using IP addresses in the .rhosts file. I bet this clears up the problem unless the login is going through that firewall above.

More important is rlogin is not very secure to start with. Consider openssh as an alternative.

SEP

[John McKiernan]

It turns out Bastille added this to /etc/pam.d/rsh and similar files :

auth required pam_deny.so

After I commented these out, it all worked as expected.

It was very misleading to see PAM first report "OK" and then silently reject.