Customized SSH port forwarding - for TCP/IP tunnelling?

Questions / Help
1

Recently I’ve been looking into OTP ssh package, and I’ve noticed there is a support for port-forwarding built-in into the ssh:daemon/3. I know there is a way to implement a custom ssh shell. I’m wondering if there is a similar customization option for TCP/IP tunnelling? Has anyone maybe tried to do it and could point me to the correct place?

Thanks in advance.

1 Like
2

as far as I remember, my friend made required support for data channels to ssh: TCP/IP tunneling over SSH connections (aka port forwarding) by HansN · Pull Request #2376 · erlang/otp · GitHub

We haven’t adopted it to our corporate ssh proxy, so I do not remember if it works, check it please. It should help you.

2 Likes
3

I know that one can setup a functioning port forwarding over ssh - that’s built-in and works just fine.
What I’m looking for is a way to provide a customized behaviour, for example:

User want to open a tunnel from server like ssh -R foobar:80:localhost:4444 and I’d like to capture that request and for example modify host/port part from foobar:80 to foobar.my.local.net:1234 .

I guess I’m looking for a way to customize this piece - otp/ssh_connection.erl at OTP-25.0.3 · erlang/otp · GitHub - other than forking otp itself.

1 Like
4

Maybe a PR with a new ssh option that modifies the {ListenAddrStr, ListenPort} pair?

The option could take a fun which takes that pair as input and returns a new pair.

2 Likes
5

I’m facing a similar challenge. If customization is not available, is there a way to notice, when a client opens a tunnel and the port it’s using?

Connect callback isn’t called for a connection that only opens a tunnel, same for dbg msg callback.

Thanks in advance :slight_smile:

2 Likes
6

I am not aware of a civilized way for being notified about tunnel being opened.

Can you explain the use case more? Are you after some auditing functionality on SSH server side?

1 Like
7

Thanks for your response. Auditing functionality is one aspect. The idea is to build a ssh reverse tunneling reverse proxy. My servers are not accessible from the outside, so they should open a tunnel on to erlang server forwarding their port 22 locally, which can be securely accessed from the admins via a ssh reverse proxy - to not been required to share private keys or have many public keys per server. For this reason the ssh reverse proxy needs to know, which tunnel/local port belongs to whom.

This project inspired me: GitHub - flussonic/ssh-proxy: SSH proxy that allows support agents go to customers servers with using intermediate corporate SSH key

3 Likes
8

I’m glad that our project is inspiring someone.

It is used in production (with some minor changes in private branch)

2 Likes
9

To implement the desired behaviour, I’m redefining the module ssh_tcpip_forward_acceptor to accept opening tunnel only under valid conditions. Is redefining of modules a good approach?