remsh port numbers

[Jeffrey Strang]

Is there anyway to specify the default return port for remsh traffic to utilize?

I am executing remsh commands through a firewall and having difficulty connecting. The machine issuing the remsh command sends it properly on port 514, but when the receiving machine attempts to send back, it randomly grabs a port between 1024 and 65535. I would like to tell remshd to use port 1024 all of the time. Is this possible?

I would appreciate any help and assign points.

Thank you,

Jeffrey Strang

[Sridhar Bhaskarla]

Jeff,

Inetd spawns remshd upon connection to it's shell port which is by default 514. We can tell remsh command to send requests to shell/cmd that is listening at 1024. Following would be the way.

On the client, change /etc/services and change the port of 'shell' (cmd) to 1024.

On the server also, change /etc/services and change the port of 'shell' (cmd) to 1024.

This will enable the remsh client to send the requests with 1024 while the inetd on the server looks for shell at the port 1024.

See if this helps,
-Sri

[Jim Turner · Accepted solution]

Hi Jeffry,

With all due respect, I'm not sure Sri understood your question. Or maybe it's me.

Your originating side of the remsh socket uses a non-priviledged (>1023) port. Most likely, it uses an ephemeral (>4999) port. Let's use 5001 as an example. Your remsh connection goes to port 514 on the remote host. The remote host (the "receiving machine" in your example) is only sending data back the way it came.

In other words, your socket connection looks like this:
sending_host:5001 receiving_host:514

AFAIK, there is no way to choose the outbound port (5001 in this example). I think it's picked pretty much at random. Your firewall admin should be able to check the syn/ack flag on TCP traffic to allow return traffic from established connections which would solve your problem.

All the best,
Jim

[Sridhar Bhaskarla]

I agree. I misinterpreted that he would want the shell(cmd) to listen at 1024 on the server machine.

remsh chooses to pick up any port starting 1020. I defined inetd to look for shell at 1024 on my remsh server. Following is the netstat output on the client.

remsh:?? ---> inetd(shell):1024

$netstat -an |grep .51
tcp 0 0 xx.xx.xx.52.1023 xx.xx.xx.51.1024 ESTABLISHED
tcp 0 0 xx.xx.xx.52.1022 xx.xx.xx.51.1023 ESTABLISHED
tcp 0 0 xx.xx.xx.52.1021 xx.xx.xx.51.1024 ESTABLISHED
tcp 0 0 xx.xx.xx.52.1020
xx.xx.xx.51.1022 ESTABLISHED


-Sri

[Tim D Fulford]

Jeff

Even further to the above. There is a very good reason why this is not possible. If you force your outbound traffic to use a specific port then then there is no session (7 layer network model type of thing)! The outbound port number is used by the two participants to identify the session e.g

computera:5001 computerb:514
computera:5003 computerb:514

If both the above ports were the same then these two sessions would merge into 1!!! Or to put it another way: the (IP address).(port number) = socket & the socket pair (sender soc + reciever soc) is therefore unique.

You do not readily see this e.g. using "who" "ps" etc, but it is in there!

Cheers

Tim

[rick jones]

iirc resh/rcmd et all require the "client" port numbers to be in the "priviledged" range of < 1024. so, the daeamon will listen at its well-known port number and the client sides will all be below 1024.

you can indeed if you really wanted to, try to force it all through a single client port number, however, you would only be able to have one remsh between any two machines at a time, and you would have to wait for tcp_time_wait_interval between remsh commands. you do not really want to shrink tcp_time_wait_interval is it is part of TCP's correctness algorithms.

you do not have to worry about two connections between the same two machines using the same port numbers - the stack will prevent that from happening.

if there are port numbers "coming back" that are above 1024, it implies that your remsh is running some command that opens another connection - if that is correct, there is nothing you can do in remsh to cause those connections to use specific port numbers, you have to work on those commands themselves