>> > Here's how it works. The server listens on port 22. The client opens a >> > connection to the server, and tells the server which return port to use. >> > If you do "netstat -an" you will see the server talking on port 22, and >> > the client talking on some high numbered port like 32873. The high >> > number port used is random. It will change from one session to the next. >> > >> > This is true not just for ssh - it is true for most tcp applications. > >> Unfortunately I have the "privilage" of maintaining a customer TCP >> protocol which cans you if your source and destination ports aren't as >> specified by their fcked up protocol!! > >Nevertheless, that's how TCP works, for every customer in the Universe. >Sack your customer, and get another?. Hmmm. I thought it went like this: The client application requests a random high port on the client machine (a socket). Then, using this socket it makes a request to the required well-known port (e.g. 22 for ssh) on the server machine. Since no other application on the client box will ever be given the same high-numbered port as any other application on that box, the client-ipaddr/highPort + server-ipaddr/wellKnownPort combination defines a unique 'circuit' over which further communication takes place. The client doesnt have to do special things to tell the server what its connecting port-number is. Until along comes ftp, which has a command channel and a data channel. So having made a connection in the above way for the command channel, the client and server have to make further negotiations for a data channel. And firewalls have to be aware of this. Thats my two penn'orth Cheers, Terry.
