Hi,

I have a problem when using rsh.

If I just use the rsh command without specifying a different user to use on the remote server, it works fine. When I specify another user to use, it takes about a minute longer.

SERVER1 is running RHEL3
SERVER2 is running RHEL3
SERVER3 is running FC4

All of the below examples are done logged in as root, but it is the same when logged in as any user except "joebloggs".

Example running rsh without specifying a different user:

SERVER1:446-> date ; rsh server2 date ; date
Thu Jan 18 15:37:12 GMT 2007
Thu Jan 18 15:37:12 GMT 2007
Thu Jan 18 15:37:12 GMT 2007
SERVER1:447->

Example running rsh and specifying joebloggs as the user:

SERVER1:449-> date ; rsh -l joebloggs server2 date ; date
Thu Jan 18 15:39:17 GMT 2007
Thu Jan 18 15:40:19 GMT 2007
Thu Jan 18 15:40:19 GMT 2007
SERVER1:450->

Example running rsh and specifying joebloggs as the user, but when the rsh is to a different server:

SERVER1:450-> date ; rsh -l joebloggs server3 date ; date
Thu Jan 18 15:41:45 GMT 2007
Thu Jan 18 15:41:47 GMT 2007
Thu Jan 18 15:41:47 GMT 2007
SERVER1:451->

So, this shows that things are ok on SERVER1, and that the problem must be on SERVER2. I have tried the same processes from another server rsh'ing to server2, and the results are the same as above.

I have done a lot of searching and reading about this, but cannot find any solution or anything that helps.

FYI: "rlogin server2" from server1 is instant, but "rlogin -l joebloggs server2" from server1 also has the same time delay as the rsh -l joebloggs

It used to work just fine, and I have not changed anything that would affect this, as far as I am aware.

I know people will say "You should be using ssh instead" but for various reasons, this is not currently a viable option.

Please can someone offer any advice on this?

Many thanks in advance for any help and suggestions.


Paul.

are you using .rhosts authentication in all cases? ie.. having to scan through an extremely large /etc/passwd may cause delay. I remember in Solaris the login process could take longer depending on how high or low your user was in the passwd file.

cheers

Hi Nilleso, thanks for taking the time to reply.

I am using .rhosts in joebloggs home directory, but the passwd list is not very big, around 150. I put joebloggs right at the top just in case, but it didn't solve the problem.

I have done some more testing this morning, an using rexec is very quick, even when specifying the login to use:

SERVER1:1076-> date ; rexec -l joeblogs -p "password" server2 date ; date
Fri Jan 19 11:19:51 GMT 2007
Fri Jan 19 11:19:51 GMT 2007
Fri Jan 19 11:19:51 GMT 2007
SERVER2:1077->

It appears to me either something to do with authentication, or something in the system login scripts, before the /etc/bashrc and others even get run. I have tested using the rlogin -l joebloggs, and the delay is before any of the normal login scripts, even before the "Last login:...." message is shown

Does anyone have a link to a document that details the entire login process on RHEL please? Either just for when rsh/rlogin or even just a normal login...even though when I telnet to server2 and login as joebloggs there is no delay at all.

Thanks again.

I have made some progress on this, and have worked out what is causing the delay. The problem is being caused by the following line in the /etc/pam.d/rsh file:

auth required pam_rhosts_auth.so promiscuous

...just need to find out why now.

Cheers.

I have now solved this problem, and am putting up what was causing it, in case other people have the same happen to them.

It was being caused by some entries in the /etc/hosts.equiv file on SERVER2.

There were some entries in there that were pointing to IP Addresses that were not ping'able at the moment, and also quite a few entries that were not resolvable either in the /etc/hosts file or by DNS.

I removed these entries, and the rsh works instantly now.

Cheers,


Paul.

I'm glad you solved your problem. Next, I would recommend you investigate converting to ssh. Anyone who is remotely involved with security will run away screaming when they read terms like "rsh", ".rhosts", "hosts.equiv", etc. You really don't want to be using these if you desire any semblance of security on your system(s).

Yeah, thanks for sharing your fix BBPS. I know there are circumstances where you cannot use SSH ...and I also agree with haertig point of view.. when applicable.

I really haven't found any circumstances where ssh cannot be successfully used over the r* commands, and telnet, and ftp, etc.

Free-running applications converted to ssh commands may stumble when they are prompted for a password, but that can be overcome using pubkey authentication with no passphrase on the keys. Having no passphrase is not as secure as having one (of course!), but it's certainly more secure than reverting back to the r* commands.

Humans can get around passwords by using pubkeys, an ssh agent, and agent forwarding if that's their desire. You can still have a passphrase when using an agent. Agent forwarding takes away a small bit of security (some man in the middle attacks may be easier, if the middleman server gives root access to bad guys).

It boils down to security vs. convenience. The two are opposites of each other. The more convenient things are for you, the less secure they are. And vica versa. If it's inconvenient for you to interactively authenticate, then you have to accept the security hit that goes with adding that non-interactive convenience. The r* commands fall into the category "highly convenient, horribly unsecure". This tradeoff may be perfectly acceptable in the OP's environment.

I work in an industry which still must rely on a few massively distributed processing systems. .A many billion dollar network... however these machines cannot and never will run SSH. It is neither secure nor convenient but it is just one example for ya.

cheers