Customized SSH port forwarding - for TCP/IP tunnelling?

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

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.

1 Like

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 .

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

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.


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:

1 Like

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

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


I’m glad that our project is inspiring someone.

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