2 users on the same server (rexec)

UNIX for Advanced & Expert Users
1

Hi, all.

Could some one help me please with one problem?

In one process (on aix) I should run some remote scripts on other server via rexec.

Some scripts should be run on server1 under useridA, and some scripts should be run on the same server under useridB.
I specified in .netrc server-name/useridA in one line and server-address/useridB in second line.
When I call
rexec server-name some-command
everything is okay.
But when I try to run
rexec server-address some-command
it looks like rexec selects useridA instead of useridB.
In /etc/hosts I can see:
server-address server-name

Is it possible to avoid it?
I mean to say if it's possible to perform some job via rexec on the same server but under different userids?

Thank you in advance.

Anta

2

Do not use rexec and DO NOT USE .netrc-files at all, they are a severe security hole.

Install ssh on all machine (download at www.bullfreeware.com for instance), exchange keys and then issue:

#!/bin/ksh

ssh remoteserver -l userA "who am i"

ssh remoteserver -l userB "who am i"

exit 0

Hope this helps.

bakunin

3

Thank you.
Yes, I don't like all this .netrc using too.
I realize it would be simpler to deal with ssh, but the problem is this moment I need use rexec.
It's possible to trick rexec with all this stuff like klog, HOME vars, but sure - it's just a fallacious way.

Anta

4

In this case: use rsh:

rsh <host> -l <user> <command>

watch out: there is a kerberized an a non-kerberized version of it, depending on if you have kerberos installed or not.

HTH

bakunin

5

Thank you.
You'll laugh, but in our environment rsh using has been outlawed last and all the time.
Maybe the best way is to create own wrapper for rexec system function.
Anta

6

I think you're supposed to put both lines in .netrc. And then do:
rexec -l usera
rexec -l userb
The rexec program is a bit non-standard. I have only seen it on HP-UX. I don't see any indication that you tried a -l option. Does the AIX rexec program not have a -l option?

I have a c wrapper somewhere that reads the password from stdin. I use in scripts where I prompt for the password and then echo it into my wrapper. If you have a c compiler, I could dig it up.

7

Thank you.

To my regret there is not "l" option in aix/rexec.
Yes, it's not a large problem to create own wrapper for rexec system function in order to have the possibility to specify the need userid, but I hoped my problem could be solved with a minimal effort. Alas...

Anta

8

Well, I hate to suggest this, because I don't like the solution... But you could have a .netrc.user1 and a .netrc.user2. The scripts would copy the right one to .netrc just before doing the rexec. Security-wise this is not much worse than a single .netrc file. But it creates a race condition. Two scripts running at the same time could step on one another.

9

Thank you.

Yes, I thought about "parallel" .netrc files, but it's more than possible that at the same time other application should be run on the same server and it will require the "source" netrc.

Can you tell me please if some sense exists to have an alias for the remote server in /etc/hosts?
Something about:
IP-addr server-name
IP-addr server-alias
And to specify in .netrc server-name with one UserID and server-alias with other UserID?
Or rexec can not be tricked in such way and it will be sure that this IP-addr is connected to only server-name?

Anta

10

I would be very surprised if you could fool the networking routines that easily. The targeted hostname will be converted to an IP address. Each line read from .netrc will also be converted to an IP address and the IP addresses are compared. If it is coded any other way, I would consider it broken. However if the box has 2 IP addresses that can reach it, you can have one line for each IP address.

A final thought: establish a second user id on the source server for the second application. Now each user has a .netrc file.

11

Thank you, Perderabo.

You confirmed my suspicions on name resolution.
Yes, there are some "roundabout" ways to solve the problem.
I just hoped the "direct" way exists too.

Anta