Unable to rsh and include a command

[Jerry Jesiolowski]

I am able to rsh from Server a to Server B without appending a command. I have read that I am actually issuing a rlogin when no command is specified with a rsh command. However when I issue the rsh with any command such as a ls /usr/local/bin which I am able to read it eventually just times out. I have the properly settings for all the host files. If I didn't I would not be able to rsh to Server B from A.
I understand that rlogin uses port 513 by convention and rsh uses 514. The Firewall at Server B is not blocking this port or trafic from Server A. On the outbound from Server A does port 514 have to be opened. I was told it was but I do not believe it uses port 514 at the outbound side only the inbound Server B.
Any ideas?????????? Thanks JJ

[Al Licause]

You are correct in the port numbers used by both rlogin and rsh.

Try running tcpdump on the receiving host and see if the request are even getting there.

If not, then it may indeed be a firewall issue.

If they are then it is may be a host configuration problem.

[Al Licause]

Also make sure that the login line in /etc/inetd.conf has not been commented.

If it has, uncomment it and issue a hup to inetd. Then try again.

[Jerry Jesiolowski]

We ran a sniffer on our firewall and tested out two scenarios. Running the command rsh sun47 on Sun16smc logged on as informat (it connects and runs under user informat as a rlogin). Ran rsh sun47 ls /user/local/bin on Server Sun16smc logged on as informat. Timed out but ran as root. Issued ps-ef | grep rsh on another session of sun16smc (root 23033 12511 0 13:46:02 pts/4 0:00 rsh sun47 ls /usr/local/bin).

Entries on Sun47
shell stream tcp nowait root /usr/sbin/in.rshd in.rshd
shell stream tcp6 nowait root /usr/sbin/in.rshd in.rshd
login stream tcp6 nowait root /usr/sbin/in.rlogind in.rlogind
exec stream tcp nowait root /usr/sbin/in.rexecd in.rexecd
exec stream tcp6 nowait root /usr/sbin/in.rexecd in.rexecd

No entries above for Sun16smc. I assumed you meant the receiving host not the sending host when you mentioned file inetd.conf. If so then there isn't a problem with this file.

I do believe that somehow Sun16smc does not allow root to issue commands using tcp outside their firewall. Does this have any merit? JJ

[Steven Schweda]

None of this is very clear, and I think you
lost me again when "Server a" and "Server B"
turned into "sun47" and "Sun16smc". Actual
commands with their actual results would be
much easier to follow.

However, I do have some questions.

Why not use something really simple, like
"pwd" for your remote command? It'd save
some typing.

Which OS and version is running on these
systems? (And, assuming that it's not Tru64,
why ask here? I hear that there are user
discussions at sunsolve.sun.com?)

> Entries on Sun47
> [...]

"Entries" in what? And doesn't it bother you
a little that two of the services (if they
are services) have "tcp" and "tcp6" variants,
while one has only "tcp6"?

Have you tried anythings like:
rsh server_a
and:
rsh server_a pwd
_from_ server_a (instead of from server_b),
and similarly from server_b to itself, just
to verify the easy stuff before dragging
another system and/or firewall into the
picture?

And what are the network impediments between
these two systems?

> [...] Does this have any merit?

So, you think that the firewall (whatever it
is) is checking the _username_ in IP traffic?
I may grossly underestimate the smarts of
these things (especially when I don't know
what they are), but that sounds to me as if
it would be beyond the grasp of the typical
firewall.

[Jerry Jesiolowski]

Al - any thoughts on my last reply. In reply to Steve not being able to understand my reference of the entries on Sun47. I was referring back to file /etc/inetd.conf that you wanted me to check. I thought any one who read the entries and was acquainted with Unix would make the connection.
I will refer to Sun16smc as being what I firs stated as Server A and Sun47 as Server B. Sorry for the confusion if I threw you a curve ball as well.
I am going to have the Unix Admin, at our remote site Plano, Tx(Sun16smc) perform a sniffer as well, so as determine if the rsh with the command operand passed through their firewall Command that was issued(rsh sun47 ls /usr/local/bin. The sniffer that I previously mentioned was done at Newark, NJ for traffic going through our firewall to Sun47(a server at our location).
The traffic flow I am told goes as follows:
Plano, Texas Sun16smc(Sun Solaris 5.9) => firewall => MCI => router
Newark, NJ => router => firewall => switch => Sun47(Sun Solaris 5.8)
I will supply the exact path if necessary.
That's the best I can do right now. I am a DataWarehouse specialist and have just picked up Unix in the last week, but I learn fast.
I think the key lies in the fact that once root was assigned the ownership of running the rsh command instead of the user who actually initiated the rsh comand might be causing the problem.

[Steven Schweda]

> I thought any one who read the entries and
> was acquainted with Unix would make the
> connection.

Yeah, and I thought that anyone with a
Solaris problem wouldn't start asking about
it in a Tru64 forum, but you can see how well
my intuition works, hence the question.
Which, would you say, poses the greater risk
of a misunderstanding, stating the "obvious"
or omitting it?

Sadly, my Solaris system runs SunOS 5.10, and
they don't use /etc/inetd.conf any more, so I
can't easily see if your apparently missing
"login [...] tcp [...]" entry is significant
or not by comparing your stuff with mine.
You might learn something by comparing your
two systems with each other.

> [...] but I learn fast.

You could start by learning how to show the
actual commands you tried, and what happened
when you tried them. I still think that the
rsh-to-yourself experiment might be valuable,
but I haven't seen the results yet. Running
those tests successfully would determine that
there's nothing wrong with inetd.conf. Also,
running those tests successfully as different
users would help to ensure that there is
nothing user-specific in the problem.

Having eliminated local problems, I'd then
move on to network/firewall-related
possibilities.

> I think the key lies in the fact [...]

Read that sentence (?) again, and tell me
what it said. And when you're showing those
actual commands with their actual output, be
sure to say which user is running them.

[Al Licause]

Jerry,

Are these Tru64unix systems standalone systems or clustered ?

If they are clustered, check your /etc/clua_services file and find out if out_alias has been applied to ports 513 or 514.

If so, make sure you have included the cluster alias in your local .rhosts file on the remote system. And make certain the .rhosts file is owned by the correct target user and has permissions of 600.

What errors do you get if any when trying to send rsh host command ?

These commands usually fail with some fairly obvious errors which can most often lead to a solution.

[Steven Schweda]

AL:

What makes you think that these are Tru64
systems?

1. Who names Tru64 systems "sun*"?

2. In _your_ /etc/inetd.conf file, are _your_
deamons named "in.rshd", "in.rlogind", and
"in.rexecd"?

3. Did you miss the part (Apr 10, 2007
01:03:49 GMT) where he (eventually) described
them as running "(Sun Solaris 5.9)" and "(Sun
Solaris 5.8)"?

Who's more lost here?

[Al Licause]

Steve,

Don't jump down my throat. I'm simply trying to help the person asking questions. I do see that there is confusion in the previous posts with regard to naming and it has already been questioned but I didn't see anything that actually described the OS.

Please admonish the people posting inaccurate or misleading information....not those trying to resolve the problems.

To the original poster....please clearly identify the operating systems you are working with.