aws.greengrass.SecureTunnelling component should support custom localproxy `-d` ports

[TSNoble]

Is your feature request related to a problem? Please describe.
The localproxy supports multiple services, however, the aws.greengrass.SecureTunneling component only appears to be compatible with simple (SSH) connections.

Describe the solution you'd like
I'd like to be able to specify more complex localproxy configurations via the aws.greengrass.SecureTunneling component, preferrably through the component configuration.

Describe alternatives you've considered
We're currently trying to set up a combination of SSH & VNC connections over Secure Tunneling. Since the aws.greengrass.SecureTunneling component only appears to support SSH, we are having to manually pull and build the localproxy code, subscribe to the tunnel token MQTT topic, and start the localproxy with the token and desired destination ports, all deployed via a custom greengrass component, which presumably does most of what the AWS component already does, just to pass in a single parameter that is already supported by the localproxy code. This is a lot of overhead.

Additional context
https://docs.aws.amazon.com/greengrass/v2/developerguide/secure-tunneling-component.html#secure-tunneling-component-configuration

Admittedly, I'm not sure if this is the right repository to raise the issue. The localproxy code already supports this feature, but it appears the greengrass component does not (and simply launches the localproxy with SSH only in mind). I can't find any reference to the component's source code.

Impact
This would allow anyone wishing to establish non-SSH connections via Secure Tunneling to do so with minimal custom code and using the reccomended. Backwards compatibility would be preserved, so existing users of the component would not be affected

Implementation ideas (optional)

• Modify the aws.greengrass.SecureTunelling component to accept destination port mappings in configuration
  • This could be through an additional parameter e.g. {"ports": "SSH=22,VNC=5900"}
  • This should default to {"ports": "SSH=22"} for backwards compatibility
• Modify the component source code to simply pass this port mapping via the -d parameter to the localproxy when launching it

Are you willing to work on this feature?

• Yes, I'm willing to submit a PR for this feature
• No, I'm just suggesting an idea

Checklist

• I have searched the existing issues to make sure this is not a duplicate
• I have provided all the necessary information for this feature request
• I understand that this is just a request and may not be implemented since Local Proxy is just a reference implementation for AWS IOT Secure Tunneling

[rawalexe]

Hello @TSNoble ,
The AWS IOT Secure Tunneling code isn't Open Sourced yet. We are working towards open sourcing it soon. I can take into consideration while releasing the code.

[rawalexe]

The java one should also be capable of at least supporting VNC by adding it as a service in the console. Have you tried that? It's just you cannot enable both for a given tunnel. Since you are willing to contribute back I can keep you notified when the new component is released.

[TSNoble]

Hi @rawalexe

Thanks for the response.

I believe we have tried adding VNC as a service and it was not working, although we were having issues with our VNC server at the same time, so I will double check now that the VNC server is working.

Could you let me know how the localproxy destination ports are configured within that component currently? I was assuming it was using either -d localhost:22 (V1) or -d SSH=22 (V2), and would therefore have no knowledge of any other service types. It sounds like this is not the case?

Edit: Ah I just saw you mentioned it doesn't allow enabling both. Does this mean that it's using the V1 style destination ports and, if so, would that mean the VNC server would need to run on port 22?

(This setup sounds like it could work, although we do need the ability to support SSH and VNC connections simultaneously, so I don't think it would work for our use case)

Given the code is closed source, would it be possible to request a new version of the component that accepts an arbitrary destinationPorts setup in the ComponentConfiguration? I suppose for backwards compatibility it would need to default to localhost:22 to remain consistent with V1 ports. It seems like a fairly small change, since the parameter can just be passed directly to the localproxy?

[rawalexe]

So couple of things, the closed source one is not using local proxy under the hood, it is using iot-device-client. Also, you can use vnc in it's default port as I believe it handel's that case based on the service name.

The new Greengrass ssh will be kind of a wrapper around local proxy and will be more modular written in C. So it can be enabled for both, I am just not targeting that for the first release.

Do you need to support ssh and vnc on the same tunnel?