Discussion:
Dynamic Remote Port forward?
(too old to reply)
Rogan Dawes
2016-05-04 21:32:53 UTC
Permalink
Hi folks,

I'm wondering if it is possible to set up a dynamic port forward (i.e.
socks proxy), where the listening socket is actually on the server rather
than the client as is currently the case for -D ?

A possible use case is providing a deeply firewalled box with an outbound
SOCKS proxy, but only while an inbound ssh connection is active.

Or, in my particular case, I have many routers running OpenWRT, using
sshtunnel to establish a persistent connection to my central server. I want
to be able to reach systems behind the gateways.

I currently have the sshtunnel configuration set up as follows:

On the router:

ssh StreamLocalBindUnlink=yes -nN -R /sshvpn/gateway-xxxx:127.0.0.1:22
***@central

In this way, should I want to connect to a system behind the router, I can
first establish a new SSH connection back to the router itself, from the
central server:

ssh -o ProxyCommand='socat UNIX:/sshvpn/gateway-xxxx -' -D 1080
***@gateway-xxxx

and then use the socks proxy on port 1080 to reach the remote devices.

This is workable, but somewhat clumsy, in my opinion.

My ideal scenario would be something like the following, run on the router:

ssh StreamLocalBindUnlink=yes -nN -RD /sshvpn/gateway-xxxx ***@central

which would allow a process on the central server to establish a connection
through the socks server listening at /sshvpn/gateway-xxxx, with
connections outbound from the router itself.

Obviously the "-DR" option is nonsense, and should be changed to a suitable
single character option, I'm just not sure what is available right now! :-)

Thoughts?

Rogan
Markus Friedl
2016-05-08 19:04:04 UTC
Permalink
I have an ugly patch for that feature that requires protocol modification.
Post by Rogan Dawes
Hi folks,
I'm wondering if it is possible to set up a dynamic port forward (i.e.
socks proxy), where the listening socket is actually on the server rather
than the client as is currently the case for -D ?
A possible use case is providing a deeply firewalled box with an outbound
SOCKS proxy, but only while an inbound ssh connection is active.
Or, in my particular case, I have many routers running OpenWRT, using
sshtunnel to establish a persistent connection to my central server. I want
to be able to reach systems behind the gateways.
ssh StreamLocalBindUnlink=yes -nN -R /sshvpn/gateway-xxxx:127.0.0.1:22
In this way, should I want to connect to a system behind the router, I can
first establish a new SSH connection back to the router itself, from the
ssh -o ProxyCommand='socat UNIX:/sshvpn/gateway-xxxx -' -D 1080
and then use the socks proxy on port 1080 to reach the remote devices.
This is workable, but somewhat clumsy, in my opinion.
which would allow a process on the central server to establish a connection
through the socks server listening at /sshvpn/gateway-xxxx, with
connections outbound from the router itself.
Obviously the "-DR" option is nonsense, and should be changed to a suitable
single character option, I'm just not sure what is available right now! :-)
Thoughts?
Rogan
_______________________________________________
openssh-unix-dev mailing list
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Darren Tucker
2016-05-08 19:27:31 UTC
Permalink
Post by Markus Friedl
I have an ugly patch for that feature that requires protocol modification.
Why does it require a protocol modification? Couldn't the client
request regular forwarded-tcpip from the server then decode SOCKS
entirely within the client?
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Ángel González
2016-05-08 19:59:24 UTC
Permalink
I think this would be doable with:

ssh -oProxyCommand="ssh -D 1080 localhost -W %h:%p" -R
/sshvpn/gateway-xxxx:localhost:1080 ***@central

-D doesn't support local_socket, so a regular port is used.
Rogan Dawes
2016-05-08 20:04:45 UTC
Permalink
That's pretty much what I was thinking. The most significant change will be
that the client has to include the socks server code, which it doesn't
currently (I suppose!).

Or am I mistaken?

Rogan
Post by Markus Friedl
Post by Markus Friedl
I have an ugly patch for that feature that requires protocol
modification.
Why does it require a protocol modification? Couldn't the client
request regular forwarded-tcpip from the server then decode SOCKS
entirely within the client?
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Darren Tucker
2016-05-08 20:17:18 UTC
Permalink
Post by Rogan Dawes
That's pretty much what I was thinking.
Me too, but Markus is smarter than I am so I fear I've overlooked something :-)
Post by Rogan Dawes
The most significant change will be
that the client has to include the socks server code, which it doesn't
currently (I suppose!).
The client has (and uses) the socks code. On most platforms it'll
also get linked into the server (and anything else that links the
channel code).

$ nm ssh | grep socks5
00030450 t channel_decode_socks5.isra.11
$ nm sshd | grep socks5
0003a930 t channel_decode_socks5.isra.11
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Markus Friedl
2016-05-08 20:34:10 UTC
Permalink
Post by Darren Tucker
Post by Markus Friedl
I have an ugly patch for that feature that requires protocol modification.
Why does it require a protocol modification? Couldn't the client
request regular forwarded-tcpip from the server then decode SOCKS
entirely within the client?
Yes. That's better and the reason why my patch is ugly ;).
I'll look into doing this.
Post by Darren Tucker
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Bert Wesarg
2016-05-09 06:21:16 UTC
Permalink
Post by Ángel González
ssh -oProxyCommand="ssh -D 1080 localhost -W %h:%p" -R
AFAIK -W forces ClearAllForwardings=1, which makes -D a no-op.
Post by Ángel González
-D doesn't support local_socket, so a regular port is used.
_______________________________________________
openssh-unix-dev mailing list
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Rogan Dawes
2016-05-09 06:19:35 UTC
Permalink
Sorry, just wanted to add a Thank you. I appreciate you taking the time to
respond to my ramblings!

Rogan
That's what I thought! As mentioned, it would be awesome if this could be
exposed as a Unix socket as well as a TCP port. I guess if you simply reuse
the existing "port forward" code, that should come automatically?
Rogan
Post by Markus Friedl
Post by Darren Tucker
Post by Markus Friedl
I have an ugly patch for that feature that requires protocol
modification.
Post by Darren Tucker
Why does it require a protocol modification? Couldn't the client
request regular forwarded-tcpip from the server then decode SOCKS
entirely within the client?
Yes. That's better and the reason why my patch is ugly ;).
I'll look into doing this.
Post by Darren Tucker
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Loading...