mjhjmtu

1. 
   

   When creating connection(s) between application client and application server via SSH dynamic port forwarding by ssh -D, how is SOCKS protocol used?
   Is SOCKS used as a protocol for communication

   
   
   
   • between application client and SSH client,
   
   
   • or between SSH client and SSH server,
   
   
   • or between SSH server and application server?
   
   



2. Once an application client is connected to an application server by SSH dynamic port forwarding, the SSH client and server are often said to “get out of the way”. Does it mean that SSH protocol is not in use now? What protocols are still in use, for example, is SOCKS and/or SSH still? is the communication between the application client and application server still encapsulated inside (so secured by) the SSH protocol?

Thanks.

I would say that the SSH client and server "getting out of the way" is a very bad way to describe dynamic port forwarding, and might be the result of several writers repeating a badly written or over-simplified description they've probably been taught at some point.

As others have described, SOCKS is used as a standardized way to tell any compatible TCP proxy where the proxied connection should go. Essentially, the SOCKS protocol is like using an old manually-switched telephone: "Operator, connect me to Town X phone number Y, please!" After doing exactly that, the operator is not (supposed to be) listening in on the connection and you can talk to the person on the other end using any language you want.

In SSH dynamic forwarding, the application client opens a TCP connection to the dynamic forwarding port (the SOCKS server port), makes a standard SOCKS request to be connected to a particular IP address and port, and can then resume using whatever protocol it would use natively over that TCP connection. It needs to be able to make the initial SOCKS request, but it doesn't need to know anything further. (There may be some minor SOCKS-specific thing at the end of the connection, but otherwise the forwarded connection will be entirely transparent and protocol-neutral as far as the endpoints are concerned.)

The application server at the other end sees just a plain old TCP connection from the SSH server: it doesn't need to know that the connection is being forwarded, nor that a SOCKS protocol is involved at the client end.

(When your phone rings and you answer it, you would not need to do anything special even if the call would happen to come from a museum of technology with a functional manual telephone exchange with an outgoing line to the landline phone network.)

So, in strict client/server terms, when the dynamic forwarding functionality is activated, a SSH client will also act as a SOCKS server with the specific additional property that all the connections using the SOCKS server will be passed within the encrypted SSH tunnel to the remote SSH server and resume as regular TCP connections from there on.

Or, put in another way, the combination of the SSH client with dynamic forwarding enabled + SSH connection + SSH server will act as a SOCKS proxy that's been stretched over the distance covered by the SSH connection, so that the inbound side of the SOCKS proxy is co-located with the SSH client, the outbound side is at the SSH server, and what happens in between looks like non-descript encrypted SSH traffic to outside observers.

Note that only the hop between the SSH client and the SSH server will be secured by SSH. But the hop between the application client and the SSH client/SOCKS server is normally within a single host. The only remaining part that may be unencrypted (unless the application protocol includes its own encryption) is the hop between the SSH server and the application server.

The SSH protocol permits multiplexing multiple independent data streams through one TCP connection. Each data stream is called a channel. All data sent through the TCP connection is encrypted. The sender will aggregate data from different channels into a single data stream which is then encrypted. The receiver will decrypt the data and separate the aggregated data streams back into their individual channels.

In the case of port forwarding, the SSH client is connected to a remote SSH server through a TCP connection using the SSH protocol. In the usual case of client->server forwarding, the SSH client is also listening for TCP connections on some port. Connections to this port will be forwarded through the server to some target.

When an "originator" (aka your "application client") connects to the SSH client's listen port, the SSH client will send a channel open request to the server, requesting a "direct-tcpip" channel. The parameters for this request include the hostname/IP address and port which the channel should be connected to. The SSH server will make another TCP connection to the specified host and port, which I'll call the "target". There are now three TCP connections:

1. Between the originator and the SSH client


2. Between the SSH client and the SSH server


3. Between the SSH server and the forwarding target

The SSH client and server relay data in both directions between the originator and the target through the SSH connection.

So, at the time a connection from an originator is being forwarded, the SSH client has to tell the SSH server where the connection should be forwarded to. If you ran ssh with the command-line option to forward a port, e.g.:

ssh -L 1234:example.com:2345 ...

then the information on where to forward the connection came from the command-line parameter; ssh remembers that connections to port 1234 are forwarded to example.com port 2345.

If ssh was invoked with the option to run a SOCKS server, e.g.:

ssh -D 1234

then each originator which connects to the SOCKS port should begin by sending a SOCKS protocol message, specifying the host and port that it wants to be connected to. ssh will use the information in the SOCKS message to construct the direct-tcpip channel open request.

SOCKS protocol used?

A client (web browser) communicates with the ssh server (via the ssh client)

is the communication between the application client and application server still encapsulated inside (so secured by) the SSH protocol?

Yes.

Refrence