Looks like Windows does ship with a native OpenSSH feature that you can enable through "Settings, --> System --> Optional Features --> OpenSSH Client" as described in . You only need the client package, not the server package. That gives you the ssh command, but not autossh since that is not part of OpenSSH (and therefore not part of the Windows feature). There are independent Windows binary ports available on GitHub, but you can easily make reliable ssh tunnels work with just the Windows OpenSSH ssh command, too.
I made a couple quick tests after the Windows OpenSSH client was installed:
C:\> where ssh
C:\Windows\System32\OpenSSH\ssh.exe
C:\> ssh -L 7497:127.0.0.1:7497 user@SystemWithTWS
That starts an SSH command line session with the remote system AND a tunnel that forwards any and all connections to local (Windows) port 7497 to port 7497 on the remote system. Creating the tunnel will work whether or not a process on the remote site actually listens on port 7497. Local windows clients will simply get a network connection error until a process on the remote system actually listens (such as TWS with an authenticated paper account). And the tunnel will survive TWS restarts or extended periods of time with no process listening on the remote port.
If you are not interested in the command prompt (for example if you want to run the tunnel in the background), simply add -N.
If you want to use a different local Windows port (say 12345) use "-L 12345:127.0.0.1:7497" instead.
There are many options and variations possible when defining the tunnel with -L. I am using the "-L lport:host:hostport" option here:
- lport is the port number on the local (here Windows) system
- host:hostport is the point where all operations on lport are forwarded to AFTER ssh connects to the remote system. "127.0.0.1:7497" in my case actually refers to the remote system that I called "SystemWithTWS" on the command line. This is important in case TWS/IBGW are configured to only accept connections from localhost (IMHO the only really safe option). But it could also be any host that you can reach from within the remote "SystemWithTWS".
A single SSH session can handle several simultaneous port forwards (say TWS ports 7496 and 7497 or IBGW ports 4001 and 4002 or all four of them) and ports may have similar or different traffic types. You can, for example, specify TWS API ports and VNC remote desktop ports through the same tunnel. For example, adding "-L 5933:localhost:5933" would allow a local (Windows) VNC client to connect to the remote VNC desktop ":33" while your local TWS API clients connect to TWS or IBGW.
And finally, these kinds of tunnels allow data packets to flow in both directions between the local and remote system, but connection requests are only honored on the local system. Meaning that processes on the remote system cannot reach ito your local system through these tunnels.
I am sure there is more, but this should suffice for most users.
´³¨¹°ù²µ±ð²Ô
?
?
?
?
On Wed, Aug 7, 2024 at 03:26 PM, Richard L King wrote:
Thanks for that, ´³¨¹°ù²µ±ð²Ô.
Do you happen to know if there¡¯s a way of achieving the same thing on Windows (short of installing something like Putty)?
