SOCKS is mightily fine and flexible, but it requires the application to be aware that it should "talk SOCKS" with the local SOCKS server. The SSH client and the SSH server then forward data in both direction, between the application and the server, the data being encrypted in the SSH tunnel between A and B.The SSH server on B opens a connection to on port 80 (note: this implies that the resolution of the name will uses B's DNS).PuTTY then talks to B, through the tunnel, to tell it: "this is the SOCKS module we want a new connection to on port 80".localhost:5000), it says to that server, as per the SOCKS protocol: "hello, I want to talk to on port 80". When an application connects to the SOCKS server on A (i.e.PuTTY is connected with SSH to machine B (the SSH server).On machine A (the SSH client), PuTTY maintains a server on a given port (say, 5000) and expects clients to "talk SOCKS" (a specific protocol).You get SOCKS by selecting the "dynamic" option in PuTTY. SOCKS is a protocol which tries to fix these issues. The target server may not like it, if its name is not. For instance, if the application wants to talk to a HTTP URL like, then, regardless of how well intercepted and tunnelled the connection is, the application will send through it a HTTP request header which says "this is for ". The name that the application sees may resurface in the protocol.I have done that a lot on Linux, but I don't know if this will work well with Windows. In case of port conflict, you might want to play with several local addresses, e.g. If you want to setup several tunnels, you will need to allocate several local ports.If an application wants to connect to port P, then you will have to initialize your tunnel with the local port P and none other. The "hosts" file is just for names, not for ports.The "hosts" file acts at the name resolution level, it cannot do anything for connections which use application-specified IP addresses.The ultimate destination is fixed, through configuration.You will run into the following problems: This kind of tunnelling is clunky and not very flexible. Then when an application tries to connect to, say, URL, the port tunnel applies and the data, ultimately, will reach on port 80. With the example above, if one adds the following line to the "hosts" file: 127.0.0.1 Some applications can be configured easily for others, you can play with the "hosts" file (on Windows, look for it in C:\Windows\system32\drivers\etc\hosts). The tricky point is to convince an application to connect to "localhost" instead of a normal, named server.
#Putty ssh tunnel localhost software
In the guide example, the local port is 8080, and the remote host-and-port is This means that when PuTTY is launched on machine A and connects (with SSH) to a machine B, any software S running on A and connecting to localhost:8080 on A will trigger a new connection from B to what S writes onto its connection to localhost:8080 will be tunnelled through SSH, and then, on B, written onto the connection which points to Traffic in the other direction is also forwarded.
#Putty ssh tunnel localhost how to
This guide shows how to setup such a tunnel. When an incoming connection to that server occurs, the client talks to the SSH server and makes it create a new connection, from the server machine to a configured remote host and then the SSH client and server forward data bytes between the two connections and through the SSH tunnel.
Port tunnelling: the SSH client (PuTTY) runs a local server, listening on some port on the client (by default, it will accept only connections from localhost, not from remote systems, so that's "safe"). The SSH protocols allows for two main ways to do some "proxying": port tunnelling, and SOCKS.
0 kommentar(er)
